Home » railML newsgroups » railML.infrastructure » Station borders
Station borders [message #2318] Fri, 24 January 2020 17:31 Go to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 486
Registered: January 2016
Senior Member
Dear all,

in the SCTP use case working group we recently discussed about borders of stations and their representation in railML 3.x.

There are several candidates for implementation:
* a dedicated <border> element
* evaluate (linear or area) location of <operationalPoint>
* topology-based aggregation of <netElement>

But before we think about the specific implementation, let me first ask you, dear community, whether you need to distinguish between "in-station" and "outside-of-station" and - if needed - which attributes do you expect the border to have?

As usual, any feedback is highly appreciated...

Best regards
Christian


Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: Station borders [message #2338 is a reply to message #2318] Fri, 21 February 2020 16:16 Go to previous messageGo to next message
Thomas Nygreen is currently offline  Thomas Nygreen
Messages: 79
Registered: March 2008
Member
Dear Christian,
Dear all,

An <operationalPoint> can already be placed using either <spotLocation> (on a macroscopic level), <linearLocation> (if only one track) or <areaLocation> (on one or more tracks). So I'm not sure that I see the need for more ways to do it.

Best,
Thomas


Thomas Nygreen – Common Schema Coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: Station borders [message #2340 is a reply to message #2318] Mon, 24 February 2020 10:39 Go to previous messageGo to next message
Thomas Langkamm is currently offline  Thomas Langkamm
Messages: 25
Registered: April 2019
Junior Member
christian.rahmig wrote on Fri, 24 January 2020 17:31

There are several candidates for implementation:
* a dedicated <border> element
* evaluate (linear or area) location of <operationalPoint>
* topology-based aggregation of <netElement>
I would suggest to implement option (3), topology-based aggregation. A "station" is at its core a topological element, and I would assume that it is a typical netElement in a macroscopic topology. As elements from more detailled topologies must be consistent with the top-level topology, that is, a microscopic netElement (representing a track, or part of it) must be either part of the station or not, but it's not allowed that only a part of that netElement is in the station and the remaining part is not. So we'll have to make sure that the netElement ends at the station boundary anyway.

For (1), I don't like borders. It has the potential of contradicting definitions, if you add a single track and forget to define the border then suddenly the whole track plan is the station (or at least a lot more than intended). Even worse things can happen if we mix up inside or outside. My favored solution (3) leaves no possiblity for a snafu, either a netElement is assigned to the station netElement or not.

(2) is just (1) in disguise, I think. In the end we define a border based on a positioning system.

An editor could of course still use a border element to visualize the boundaries of the station. But I'd prefer it to be a derived object, not a persistant one.

[Updated on: Mon, 24 February 2020 10:41]

Report message to a moderator

Re: Station borders [message #2347 is a reply to message #2338] Wed, 26 February 2020 11:39 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 486
Registered: January 2016
Senior Member
Thomas Nygreen wrote on Fri, 21 February 2020 16:16
Dear Christian,
Dear all,

An <operationalPoint> can already be placed using either <spotLocation> (on a macroscopic level), <linearLocation> (if only one track) or <areaLocation> (on one or more tracks). So I'm not sure that I see the need for more ways to do it.

Best,
Thomas
Dear Thomas,

you are right, but in fact, all three options for modelling station borders are already possible. Therefore, it is important to find the best practice, in order to limit flexibility of the model and thus increase compatibility of railML interfaces. So, option 2 is your preferred solution?

Best regards
Christian


Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: Station borders [message #2366 is a reply to message #2347] Wed, 04 March 2020 16:37 Go to previous messageGo to next message
Thomas Nygreen is currently offline  Thomas Nygreen
Messages: 79
Registered: March 2008
Member
Dear Thomas,
Dear Christian,

Christian is correct that all three are already possible, although I
interpreted (3) as something else than the currently available topology
aggregation, and more like <propEquipment> in railML2. I fully agree
that we need to limit the number of ways to model the same infrastructure.

To me, topology and functional infrastructure are separate. An
<operationalPoint> of type "stoppingPoint" does not change the topology,
and therefore it is not natural to me that it should have its own
<netElement>. We could require it, but it would have to be through a
semantic constraint, and that constraint would have to be worded to cope
with differing station border definitions, including networks that do
not have them.

Trouble with 2 and 3: As Dirk has pointed out a couple of times, station
borders may be direction-dependent.[1][2]

What is the purpose of defining station borders in the railML
infrastructure? How will the information be used? Maybe the candidates
serve different, (mainly) disjunct purposes?

One possibility is to narrow down the use of each of the existing
possibilities, to try to make them fully disjunct, e.g.:

(1) Borders mark a point in the infrastructure that is relevant for
operations, and should be used where needed by operational rules but not
to model the station area.

Pros: Allows direction-dependent borders. Avoids graph traversal to
determine station area. A missing border does not affect station area.

(2) AreaLocation should be used to define the station area.

Pros: Builds upon topology but does not need to be 1:1. Defined directly
as a child of <operationalPoint> (as opposed to multiple borders).
<operationalPoint>s inside another <operationalPoint> clearly defined.

Question: Should SpotLocation also be accepted, when there is no need to
define an area? Should we rule out LinearLocation for <operationalPoint>?

(3) NetElements model the underlying topology and should not be used to
model station areas (or other areas).

Pros: Purpose separated from AreaLocation. Does not require multiple
meso aggregation levels for <operationalPoint>s inside another
<operationalPoint> or splitting <netElement>s at stopping points.


[1] https://www.railml.org/forum/index.php?t=msg&th=482& goto=1476#msg_1476
[2] https://www.railml.org/forum/index.php?t=msg&goto=1990#m sg_1990


Best regards,
Thomas Nygreen - Common schema coordinator, railML.org


Thomas Nygreen – Common Schema Coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: Station borders [message #2385 is a reply to message #2366] Mon, 09 March 2020 22:01 Go to previous messageGo to next message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 313
Registered: August 2008
Senior Member
Dear Thomases and Christian,

> As Dirk has pointed out a couple of times, station borders may be direction-dependent.[1][2]

Thank you, that's exactly what I wanted to mention right now... ;-)

Not only this: There are also several different definitions of station borders at the same time. (In Germany: interlocking, operational and traffic definitions are often different. Several operational stations can form one traffic station, as Berlin Hbf oben + unten + S-Bahn. One operational stations can also consist of several traffic stations, as Dresden Hbf / Mitte / Neustadt. The interlocking borders are wider that the operational borders typically when stations are remote-controlled. But also the other way round, one large operational station can be split into several interlocking areas, as it always was the case for Leipzig Hbf (Prussian / Saxon signal boxes strictly separated) and even nowadays still is (several ESTWs).

All together: When defining station borders, always allow a definition which kind of border type is meant and allow definitions depending on direction.

Dirk.
Re: [railML3] Station borders [message #2396 is a reply to message #2385] Fri, 13 March 2020 12:23 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 486
Registered: January 2016
Senior Member
Dear Dirk,

Dirk Bräuer wrote on Mon, 09 March 2020 22:01
All together: When defining station borders, always allow a definition which kind of border type is meant and allow definitions depending on direction.

Thank you for your feedback. Following your requirement for modelling station borders option 1 (a dedicated <border> element) seems to be the only solution. Are there any other opinions from the community?

I also appreciate the idea of Thomas to distinguish between different purposes. In particular,
* <border> elements can be used to locate a (direction dependent and type specific) station border
* <operationalPoint><areaLocation> may be used to define the (static) station area.

What does the community think about this modelling approach for railML 3.x? Any comments are very much welcome...

Best regards
Christian


Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: [railML3] Station borders [message #2405 is a reply to message #2396] Fri, 20 March 2020 18:00 Go to previous messageGo to next message
Fabrizio Cosso is currently offline  Fabrizio Cosso
Messages: 12
Registered: September 2017
Junior Member
Dear all,
I would like to add my point of view to the discussion:
- "whether you need to distinguish between "in-station" and "outside-of-station": yes, we did. Several applications, one of them traffic monitoring system, need to know what is in and what is out.
- regarding how to model borders, I'm not sure we need to add a specific functional infrastructure element: is a border a physical element - e.g. a signal? There are several kind of signals already available.
What about using belongsToParent in order to determine what is within an operational point and what is out?

Thanks

BR

Fabrizio
Re: [railML3] Station borders [message #3439 is a reply to message #2405] Thu, 16 January 2025 17:42 Go to previous messageGo to next message
Torben Brand is currently offline  Torben Brand
Messages: 175
Registered: March 2016
Senior Member
While exchanging infrastructure between the Norwegian network managed by Bane NOR and the Swedish network by Trafikverket we came across the following questions as how we should model borders:

Should a border be direction agnostic with border/spotLocation@applicationdirection="both" or should you set applicationdirection="normal"/"reverse"?

Both options are possible, but do have implications.

Using "both" would for type="country" model for instance the "Norwegian/Swedish" border with no information as in which direction either Norway or Sweden is. Also, the border would have two spotLocations as it would be natural to have separate netElements on each side of the border. Importing tools would have to interpret these two spotLocations as one object/position? Currently importing a border with two spotLocations we get two borders in NorRailView, on the same node but on different edges.

Using applicationdirection="normal" or "reverse" would make it possible to model the Norwegian and Swedish border respectively. They could then also reference its relevant organisationalUnit.

The same applies for border@type="station" where I would strongly recommend to use applicationdirection="normal" or "reverse" in direction of the station center. Thus providing information of the direction the station is in and the open section being in the opposite direction. See posts above here that describe the same requirement. See also example bellow.

I suggest allowing both modelling as today, but to provide a recommendation of how to model (as suggested above?) in the best practice chapter of the <border> wiki page [1].

[1] https://wiki3.railml.org/wiki/IS:border

Current example:
<border id="b1" isOpenEnd="false" type="station">
<name name="gr-01" description="station border" language="en" />
<spotLocation id="52f9" netElementRef="ne673" intrinsicCoord="1" applicationDirection="both" pos="301" />
<spotLocation id="258c" netElementRef="ne674" intrinsicCoord="0" applicationDirection="both" pos="0" />
</border>

Suggestion:
<border id="b1" isOpenEnd="false" type="station">
<name name="gr-01" description="station border" language="en" />
<spotLocation id="52f9" netElementRef="ne673" intrinsicCoord="1" applicationDirection="reverse" pos="301" />

Re: [railML3] Station borders [message #3450 is a reply to message #3439] Wed, 29 January 2025 12:10 Go to previous message
Jim Kjellberg is currently offline  Jim Kjellberg
Messages: 2
Registered: January 2025
Junior Member
Trafikverket's view on this is as follows.
Due to the way the Swedish data is modelled a border will always have 2 spot-locations as the border is modelled as a node with 2 connected links.
<border id="Border1" isOpenEnd="false" type="station">
    <name name="gr-01" description="gränsnod Driftplats" language="sv" />
    <spotLocation id="SL1" netElementRef="ne13.1.13.6.0" intrinsicCoord="0.999964" applicationDirection="both" pos="280" />
    <spotLocation id="SL2" netElementRef="ne13.6.4.5.0" intrinsicCoord="0" applicationDirection="both" pos="0" />
</border>

This is the border between netElements ne13.1.13.6.0 and ne13.6.4.5.0"
The first netElement is between nodes 13.1 and 13.6 and is the last netElement on Operational Point 13.
The second netElement, between nodes 13.6 and 4.5, is the "open line" or line segment between Operational Points 13 and 4.

Regarding directions for a border it will always be "both" as the train can pass the border in both directions. All borders are modelled like this in our data and because of that they will always have two spot locations.

We agree with Torben that some best practice examples on the wiki page would be very useful.

With Kind Regards
Jim Kjellberg
Trafikverket
Previous Topic: railML 2.3 infrastructure extension proposal line sections
Goto Forum:
  


Current Time: Tue Feb 11 10:10:15 CET 2025