Positioning approach

Description

Current railML 3 model provides many different options for locating elements. This variety can lead to interoperability conflicts. The aim is to create unambiguous positioning information even if based on different elements and attributes.

Background

These elements are relevant for describing positions of functional infrastructure elements in railML 3.2:

• intrinsic coordinates
• (relative) pos
• linear coordinates
• geometric coordinates (e.g. WGS84)
• mileage changes
• lengths (of NetElement)

Links

• Forum discussion
  • Christian Rahmig, 04.09.2023: [https://www.railml.org/forum/index.php?t=msg&th=920&goto=3125&#msg_3125]
• Git issues
  • #541 (closed)
  • #556 (closed)
• Wiki documentation
  • RTM:associatedPositioningSystem: [https://wiki3.railml.org/wiki/RTM:associatedPositioningSystem]

railML 3.3 solution proposal

The suggested approach summarized in three points:

1. Every netElement has to have an associatedPositioningSystem linking to a so-called "intrinsic positioning system" usable as measuring tape. This associatedPositioningSystem realizes the mapping between the intrinsic coordinates (0..1) and the measuring tape.
2. Every located functional infrastructure element need to have at least one spotLocation or linearLocation or areaLocation.

• For a spotLocation: define the position either with @intrinsicCoord or linearCoordinate@measure referencing the intrinsic positioning system.
• For a linearLocation: define the position either with @intrinsicCoordBegin / @intrinsicCoordEnd or linearCoordinateBegin@measure / linearCoordinateEnd@measure referencing the intrinsic positioning system.

4. deprecate @pos, @posBegin and @posEnd, netElement/@length