UC:IS:CaptureSchematicVisualisationInformationOfTrackAssets

From railML 2 Wiki
Jump to navigation Jump to search
🗒️ This page is mirrored from page UC:IS:CaptureSchematicVisualisationInformationOfTrackAssets in The railML® 3 wiki.
Capture schematic visualisation information of track assets
Subschema: Infrastructure
 
Related subschemas: IL 
Stift.png (version(s) not yet specified)
For general information on use cases see UC:Use cases


Use case / Anwendungsfall

Capture schematic visualisation information of track assets; Erstellung schematischer Visualisierungsinformationen von Schienenanlagen

Description / Beschreibung

railML data will be used for engineering signalling and interlocking systems. Engineers are used to working with paper plans that schematically represent the railway network. The layout of these plans is schematic, i.e. not to scale. GIS-like scaled map-views showing geographical coordinates aren’t suitable because yards will be displayed overly compressed which leads to confusion.

Parties who exchange railML data for engineering purpose will want to make prints or displays where infrastructural data always appear in the same relative position.

Furthermore, infrastructure managers require that traffic control systems schematically display track assets at defined positions. railML should therefore be capable of conveying information where to display track assets.

Data Flows and Interfaces / Datenflüsse und Schnittstellen

Drawings or screen displays, henceforth called viewports have a height and width. Track assets that can be printed or displayed within this viewport. Therefore, track assets have X,Y coordinates that can be plotted within the viewport. A track asset appear in several viewports.

Thus, the requested data are viewports, their identity, height and width. Coordinates of track assets within their viewport.

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

  • interlocking

Characterizing Data / Charakterisierung der Daten

Explaining diagramm


  • A viewport is an element that has attributes Xmin, Xmax, Ymin and Ymax define the extent of the viewport.
  • The viewport has an identifier.
  • The viewport has a list of track assets plus their X,Y coordinates in this viewport.
  • Linear or otherwise spatially extended elements cannot be captured as such. E.g. switches must be reduced to their 1-dimensional mathematical point.
  • The viewport doesn´t capture lines between elements because the infrastructure model already captures the links between elements.
  • Visualisation artefacts are kinks and intersects between track and edge of a viewport.
  • Visualisation artefacts must be nodes in the railML graph (like points and bufferstops) such that a client program can correctly draw the railway network, i.e. draw the lines between consecutive elements.
  • Visualisation elements will not capture graphical attributes of edges or nodes, i.e. no colours or line-styles.

How often do the data change (update)?

Changes occur on a irregular and unpredictable basis, usually associated with track works.

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

Subset of network associated with a yard where modifications took place. This ranges from a few track assets up to a complete line (for greenfield projects).

Which views are represented by the data (focus)?

  • Signaling

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

All physical track assets can be associated with a position in a viewport.