Driving directions in macroscopic nodes
Description
Macroscopic topology allows to model driveable train paths on a basic level: either there is a connection or there isn't. Without a microscopic topology (track level) it is not possible to identify possible direction changes of the railway vehicle when following this train path. It would be beneficial to have this information included in macroscopic topology.
Background
For TMS/operational purposes it is interesting to know whether a train has to change its direction in an operational point as this will require some more time than just an ordinary stop.
railML 3.1 topology is based on RTM providing elements to connect different topology <netElement>s
. These <netRelation>
elements can be specified w.r.t. usability with the attribute @navigability. The possible values of this attribute ("AB", "BA", "both", "none") allow only a basic interpretation of the driveability. A required change of driving direction cannot be derived.
Links
- Forum discussion:
- Thomas Langkamm, 06.12.2021: [https://www.railml.org/forum/index.php?t=msg&th=838&start=0&]
- Trac tickets / Git issues:
- #413 [version2#413] relates to railML 2 solution
- #452 (closed)
- Wiki documentation:
- Use case "Schematic Track Plan" (SCTP): https://wiki3.railml.org/wiki/UC:IS:Schematic_Track_Plan
Proposed solution railML 3.2
There are basically two options for implementation: a RTM internal approach and a RTM external approach.
RTM external solution
see forum: this is the preferred solution for railML 3.2
A new element <travelPaths>
shall be added in <topology>
acting as a container for an arbitrary number of <travelPath>
elements. A <travelPath>
element refers to (at least) three <netElement>
objects. Further, a <travelPath>
element has several attributes:
-
@directed
(boolean) -
@distance
(tLengthM) -
@lengthRestriction
(tLengthM) -
@changesDirection
(boolean) -
@numberOfDirectionChanges
(positive integer) -
@requiresShunting
(boolean) -
@crossesContraflowTraffic
(boolean)
RTM internal solution
see forum: an RTM internal solution is not feasible for railML 3.2
The element <netRelation>
shall be changed in the following way:
- rename child elements
<elementA>
and<elementB>
into<fromElement>
and<toElement>
- add new optional, but repeatable child element
<viaElement>
(0..*)