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.

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..*)

Edited Mar 22, 2022 by IS Coordination