Home » railML newsgroups » railML.infrastructure » [railML 3.2] Modelling of Routing Rules
[railML 3.2] Modelling of Routing Rules [message #3391] Fri, 15 November 2024 15:48 Go to next message
David Lichti is currently offline  David Lichti
Messages: 47
Registered: December 2020
Member
Dear Community,

In the context of a new railML 3.2 infrastructure export, we need to add information about pre-defined routes into and out of operational points. These are linear track sections, usually some point on a station track to some point on a line track. However, they are not interlocking routes. (Although there usually should be a sequence of one or more interlocking routes that allow train movements along these defined track sections.)

Each of these track sections has additional informations like route codes and priority to help the automatic train routing to choose the correct path.

How could we represent this information? Does railML (3.2) already provide a suitable element?

Best regards

David

[Updated on: Tue, 19 November 2024 07:23]

Report message to a moderator

Re: [railML 3.2] Modelling of Routing Rules [message #3419 is a reply to message #3391] Mon, 06 January 2025 14:48 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 496
Registered: January 2016
Senior Member
Dear David,

from what I understand, I think, the topology element //netTravelPath [1] is the right element you are looking for.
It is meant to be used for defining a navigable route on a macroscopic level of detail. Usually, a //netTravelPath runs from a //netElement via several other //netElement to a destination //netElement.
However, what this element currently does not provide, is some kind of "priority".

Does this element help you with your requirements?

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

Best regards
Christian

Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org

Report message to a moderator

Re: [railML 3.2] Modelling of Routing Rules [message #3422 is a reply to message #3419] Wed, 08 January 2025 09:56 Go to previous messageGo to next message
David Lichti is currently offline  David Lichti
Messages: 47
Registered: December 2020
Member
Good morning Christian,
Thank you for the suggestion. I had already considered the netTravelPath structure. However, it does not seem suitable for our requirements.

For one, we are working on a microscopic level of detail. But the net travel path is made for a mesoscopic or macroscopic model.

It also feels weird to put actual business objects into the railML topology data. Until now, all business objects have been in the functional infrastructure, while the topology was used to represent the relations between these objects.

In fact, the net travel path seems to lack almost all information that we actually need to represent:


  1. Business Reference: The trackway routes that we need to export are business objects. They are entities that are identifiable by an externally defined business key. Yet, the net travel path has neither document id, nor any other identifiers or designators.
  2. Operational Point: The trackway routes are associated to one specific operational point. Deducing this information from their topology would be unreliable at best. When stations overlap, f.ex. in the case of child stations, the associated tracks and their net elements may belong to more than one operational point. It would not be clear, which one is relevant for the trackway route. A trackway route could also be completely ouside of its related station, or between two neighbouring stations. So, there really needs to be a reference to the relevant operational point, or from the operational point.
  3. Route Code: At any given point, there may be more than one trackway route to choose from. The applicable trackway route may be different for each train movement. To define the correct route, trains may have route codes associated to certain parts of their schedule. So, the receiving system needs to know the route codes associated to each trackway route.
  4. Priority: If the applicable trackway route is not given by a local route code in the train schedule, it may be chosen automatically based on the train's global routing category and the available trackway routes. To guide this choice, each trackway route may have associated priorities, which may also reference train routing categories.
  5. Type: We currently support entry and exit trackway route types. This distinction may obvious from the topology in most cases. But in the case of complicated or neighbouring stations, it may be necessary to specify whether a trackway route is an entry route into one station, or an exit route from the other station.
  6. Location: We need to describe the exact, microscopic location of the trackway routes. Just a reference to a net element is not enough, since it does not allow to specify the exact location on that net element. Also, the restriction to exactly one via element is not suitable to describe the exact route over multiple switches, as this would involve multiple intermadiate net elements. The opposite extreme would be stopping points, where the operational point as well as the entry and exit track section may all be contained in the same net element. A trackway route at this operational point would have the same net element as from, via and to.
At the same time, none of the current attributes of the net travel path are relevant to our use case. As I see it, we would have to completely rewrite that structure to rerpesent two almost disjoint use cases.

In the meantime, we have designed a proposal for an extension schema to add routing rules to the functional infrastructure of railML. It uses standard designators for the business identifiers, and standard linear locations for the microscopic location description. If this would be helpful, it could be provided for furtherdiscussions.

Best regards

David

[Updated on: Wed, 08 January 2025 09:56]

Report message to a moderator

Re: [railML 3.2] Modelling of Routing Rules [message #3436 is a reply to message #3422] Wed, 15 January 2025 12:02 Go to previous messageGo to next message
David Lichti is currently offline  David Lichti
Messages: 47
Registered: December 2020
Member
Please also note the requirement to somehow reference these routing paths from a train itinerary in the timetable sub-schema. In particular, this would require an object with a document id.

Additionally, the current philosophy of timetable exports was to only rely on the functional infrastructure without topology data. This is how such a routing path could look like:
<functionalInfrastructure xsi:type="tps:FunctionalInfrastructure">
  <tps:routingRules>
    <tps:trainRoutingCategory id="rc-1">
      <designator register="_tpsTrackwaySectionPriorityGroup" entry="PG1"/>
    </tps:trainRoutingCategory>
    <tps:routingPath id="rs-1" opRef="op-1" routingType="entry" routingCode="FU">
      <designator register="_tpsTrackwaySection" entry="TWS1"/>
      <tps:name name="Example Trackway Section" language="en"/>
      <tps:linearLocation id="rs-1-ll">
        <associatedNetElement netElementRef="ne-1" keepsOrientation="true" intrinsicCoordBegin="0.2" intrinsicCoordEnd="0.7"/>
      </tps:linearLocation>
      <tps:routingPriority priority="0" trainRoutingCategoryRef="rc-1"/>
      <tps:routingPriority priority="20"/>
    </tps:routingPath>
  </tps:routingRules>
</functionalInfrastructure>

Best regards

David

Report message to a moderator

Re: [railML 3.2] Modelling of Routing Rules [message #3446 is a reply to message #3436] Thu, 23 January 2025 18:52 Go to previous messageGo to next message
Torben Brand is currently offline  Torben Brand
Messages: 177
Registered: March 2016
Senior Member
Dear David,

Jernbanedirektoratet would also need to model the same requirement of a default path between operational points. This path would be a sequence of consecutive routes. But we suggest to use the netTravelPath [1] to be aggregation level independent.

The idea is to add the following attributes to <netTravelPath>:
1. @operation [enumeration list]: "through", "turnaround", "start", "end" or "other:"
2. @rank
3. @trainCategoryRef (Alternative use a sub-element for multiple applicable train categories)

As David pointed out, this would be a macroscopic modelling. But the tool in question could map the microscopic path via the relevant and set <from>,<via> and <to> objects and find the relevant route path either through searching for relevant routes and using routeIL@rank if multiple options.
If You want to explicit define the route path, we could add an optional sub-element under <netTravelPath> to reference explicit route sequences in <routeIL>.

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

Report message to a moderator

Re: [railML 3.2] Modelling of Routing Rules [message #3471 is a reply to message #3446] Fri, 14 February 2025 15:36 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 496
Registered: January 2016
Senior Member
Dear David, dear Torben,

thank you for the input. The whole topic seems to be more complex than I thought at the beginning. I think, it is a good idea to discuss the requirements and possible solutions in the use case development groups. But to which use case does it belong? RTCI?

One main point where I agree with David: Topology should remain clean and not be enriched with business objects or references to them. On the other side, we should avoid modelling concepts redundantly.

Best regards
Christian

Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org

Report message to a moderator

Re: [railML 3.2] Modelling of Routing Rules [message #3511 is a reply to message #3471] Thu, 13 March 2025 12:40 Go to previous message
Thomas Langkamm is currently offline  Thomas Langkamm
Messages: 26
Registered: April 2019
Junior Member
We have a similar use case. For train routing we need to break down the timetable topology to a microscopic, track route based topology. For that we use something very similar, let's call them "paths" here, which is on the model side basically a sequence of tracks that will be occupied (broken down into tvdSections) and a list of track routes that need to be set for this path. They have a priority and a flag if they may be chosen automatically by our software.

For example, when travelling from A to B, we might have a default path with highest priority
/forum/index.php?t=getfile&id=165&private=0

and an alternative path with a lower priority
/forum/index.php?t=getfile&id=164&private=0

and we have more possible paths (for example Sw01-Sw02-Sw03-Sw04) that would be flagged as not to be used by our software, even though an operator might choose this path manually.

Tricky to pinpoint it to a schema. Our "paths" do reference track routes so it couldn't be part of infrastructure.

Report message to a moderator

Previous Topic: [railML3] New semantic constraint to ensure unambiguous infrastructure states
Goto Forum:
  

[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Thu Mar 13 21:31:31 CET 2025