From railML 3 Wiki
Jump to navigation Jump to search
Positioning and Map-Matching
Subschema: Infrastructure
Stift.png (version(s) not yet specified)
For general information on use cases see UC:Use cases

Use case / Anwendungsfall

Positioning and Map-Matching; Positionierung und Kartenabgleich

Description / Beschreibung

With a train-borne positioning system, which is a multi-sensor on-board positioning device, the train can determine its position itself. The digital map is a key component of such a train-borne positioning system as it enables the usage of map-matching algorithms in order to determine the position of the vehicle in the railway track network. The map-matched position is given by a track identifier, a relative position on the identified edge and a direction of travel related to the orientation of the track (see figure below).

Figure 1: Map-references position data after map-matching

Considering the position of the train in the track network, the map shall contain the following elements:

  • Drivable topology: tracks, which are connected with each other.
  • WGS84 coordinates: all elements need coordinate positions, which are required for referencing GNSS positions
  • Coordinates and logical positions of positioning-relevant infrastructure objects: balises, signals, platform edges, switches, crossings, etc.
  • Coordinates and logical positions of operation-relevant infrastructure objects: stations, stop-posts, etc.
  • Track geometry: 3-dimensional alignment of the railway.

There are several main sources for the data of the map:

  • Public available geo data, e.g. from an OpenStreetMap export
  • Commercial geo data, e.g. from Navtech (not so relevant for railway maps)
  • Precise measurement data from static surveys, e.g. available at land survey offices
  • Dynamically measured data, e.g. from a measurement train

Data Flows and Interfaces / Datenflüsse und Schnittstellen

The pure positioning and map-matching application only uses map data, but does not provide geo data to any further applications. Therefore, data flows include the import of map data from the above mentioned various sources into the digital track map used for the application.

Figure 2: Data flows for import of a map for on-board positioning / map-matching

Interference with other railML® schemas / Interferenz mit anderen railML®-Schemen

  • none

Characterizing Data / Charakterisierung der Daten

This section serves to specify the required data regarding certain aspects.

How often do the data change (update)?

  • Static: map is considered to remain unchanged while being used for map-matching

How big are the data fragments to be exchanged (complexity)?

  • Network: the map will contain the whole track network to be relevant for the map-matching

Which views are represented by the data (focus)?

  • Geometry
  • Topology
  • Railway operation

Which specific IS data do you expect to receive/send (elements)?

  • Topology
    • Nodes, Edges
    • Inner topology: connections
    • Macroscopic topology: grouping of topology elements
  • Geometry
    • Radius / curvature
    • Gradient profile
    • Superelevation profile
  • Operational infrastructure elements
    • Platform edges: position, height, length
    • Signals: position, direction, type
    • Stop posts: position
    • Bridges, tunnels: position, length, height, cross section profile
    • Level crossings: position, width