Introduction
An <operationalPoint> also is a time measurement point, i.e. a reference point from the <timetable> to the <infrastructure>. <operationalPoint> may also be an access point for customers using railway system.
Documentation
Syntax
|
|
| Description
|
The OperationalPoint defines a point in the railway network that is essential for railway operation. Typical examples for railway operational points are stations, block signals or stopping points. Operational points allow an interaction between the railway operator and the train driver.
|
| Subschema
|
infrastructure
|
| Parents*
|
operationalPoints
|
| Children
|
areaLocation (0..*), connectedToLine (0..*), designator (0..*), elementState (0..*), gmlLocation (0..*), infrastructureManagerRef (0..*), isValid (0..*), limitedByBorder (0..*), linearLocation (0..*), name (0..*), networkLocation (0..*), opEquipment (0..1), opOperations (0..1), spotLocation (0..*), typeDesignator (0..*)
|
Attributes:
- basedOnTemplate: references a generic operational point (optional;
xs:IDREF),
- belongsToParent: references the one and only parent operational point of this operational point
- if some information exists in parent and child, then information in child overwrites it in child
- if some information exists only in parent, then child inherits this information from parent (optional; xs:IDREF),
- timezone: the time zone of the operational point as defined in the time zone database, e.g. "Europe/Berlin"; Please refer to tz database (
 ). Bitte, informieren Sie sich unter Zeitzonen-Datenbank ( 🇩🇪) (optional; xs:string),
- id: the identifier of the object; this can be either of type xs:ID or UUID (obligatory;
xs:ID); compare: Dev:Identities
|
*Notice:
Elements may have different parent elements. As a consequence they may be used in different contexts.
Please, consider this as well as a user of this Wiki as when developing this documentation further.
Aspects that are only relevant with respect to one of several parents should be explained exclusively in the documentation of the respective parent element.
|
|
|
| Description
|
The OperationalPoint defines a point in the railway network that is essential for railway operation. Typical examples for railway operational points are stations, block signals or stopping points. Operational points allow an interaction between the railway operator and the train driver.
|
| Subschema
|
infrastructure
|
| Parents*
|
operationalPoints
|
| Children
|
areaLocation (0..*), connectedToLine (0..*), designator (0..*), external (0..*), gmlLocations (0..*), infrastructureManagerRef (0..*), isValid (0..*), limitedByBorder (0..*), linearLocation (0..*), name (0..*), networkLocation (0..*), opEquipment (0..1), opOperations (0..1), spotLocation (0..*), typeDesignator (0..*)
|
Attributes:
- basedOnTemplate: references a generic operational point (optional;
xs:string; patterns: (urn:uuid:)?[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}|{[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}}),
- belongsToParent: references the one and only parent operational point of this operational point
- if some information exists in parent and child, then information in child overwrites it in child
- if some information exists only in parent, then child inherits this information from parent (optional; xs:string; patterns: (urn:uuid:)?[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}|{[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}}),
- timezone: the timezone of the operational point as defined in the tz database, e.g. "Europe/Berlin"; Please refer to tz database (). Bitte, informieren Sie sich unter Zeitzonen-Datenbank ( 🇩🇪) (optional;
xs:string),
- id: the identifier of the object; this can be either of type xs:ID or UUID (obligatory;
xs:string; patterns: (urn:uuid:)?[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}|{[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}}); compare: Dev:Identities
|
*Notice:
Elements may have different parent elements. As a consequence they may be used in different contexts.
Please, consider this as well as a user of this Wiki as when developing this documentation further.
Aspects that are only relevant with respect to one of several parents should be explained exclusively in the documentation of the respective parent element.
|
|
|
| Description
|
The OperationalPoint defines a point in the railway network that is essential for railway operation. Typical examples for railway operational points are stations, block signals or stopping points. Operational points allow an interaction between the railway operator and the train driver.
|
| Subschema
|
infrastructure
|
| Parents*
|
operationalPoints
|
| Children
|
any (0..*), areaLocation (0..*), connectedToLine (0..*), designator (0..*), external (0..*), gmlLocations (0..*), infrastructureManagerRef (0..*), isValid (0..*), limitedByBorder (0..*), linearLocation (0..*), name (0..*), networkLocation (0..*), opEquipment (0..1), opOperations (0..1), spotLocation (0..*)
|
Attributes:
- belongsToParent: references the one and only parent operational point of this operational point (optional;
xs:IDREF; patterns: (urn:uuid:)?[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}|{[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}}),
- basedOnTemplate: references a generic operational point (optional;
xs:IDREF; patterns: (urn:uuid:)?[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}|{[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}}),
- timezone: the timezone of the operational point as defined in the tz database, e.g. "Europe/Berlin"; Please refer to tz database (). Bitte, informieren Sie sich unter Zeitzonen-Datenbank ( 🇩🇪) (optional;
xs:string),
- id: the identifier of the object; this can be either of type xs:ID or UUID (obligatory;
xs:ID; patterns: (urn:uuid:)?[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}|{[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}}); compare: Dev:Identities
|
*Notice:
Elements may have different parent elements. As a consequence they may be used in different contexts.
Please, consider this as well as a user of this Wiki as when developing this documentation further.
Aspects that are only relevant with respect to one of several parents should be explained exclusively in the documentation of the respective parent element.
|
Changes 3.1→3.2
There exists an overview of all changes between railML® 3.1 and railML® 3.2 on page Dev:Changes/3.2.
The children have been changed.
The attributes have been changed.
Changes 3.2→3.3
There exists an overview of all changes between railML® 3.2 and railML® 3.3 on page Dev:Changes/3.3.
The children have been changed.
The attributes have been changed.
Semantics
Best Practice / Examples
Best practice
If using <border>/@type=”station” and <operationalPoint>, then <operationalPoint>/<limitedByBorder> should be used for a clear explicit reference.
Example
General
This example closely follows https://wiki2.railml.org/wiki/IS:ocp .
Example of OP Pulsnitz (external link) .
<?xml version="1.0" encoding="UTF-8"?>
<railML xmlns="https://www.railml.org/schemas/3.3" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="https://www.railml.org/schemas/3.3 https://schemas.railml.org/3.3/railml3.xsd" version="3.3">
<common id="b619d717-58e6-4462-bbf0-29fa15dba1f9">
<positioning>
<geometricPositioningSystems>
<geometricPositioningSystem id="gps_4326" crsDefinition="urn:ogc:def:crs:EPSG::4326">
<isValid/>
</geometricPositioningSystem>
<geometricPositioningSystem id="gps_5783" crsDefinition="urn:ogc:def:crs:EPSG::5783">
<isValid/>
</geometricPositioningSystem>
</geometricPositioningSystems>
</positioning>
</common>
<infrastructure id="inf01">
<topology>
<netElements>
<netElement id="ne1">
<associatedPositioningSystem id="ne1_aps01" positioningSystemRef="gps_4326">
<intrinsicCoordinate id="ne1_aps01_ic01" intrinsicCoord="0">
<geometricCoordinate x="51.188164" y="14.013795"/>
</intrinsicCoordinate>
</associatedPositioningSystem>
</netElement>
</netElements>
<networks>
<network id="_32c8f46d-5e89-4d1d-a19e-8fb876903d43">
<level id="lv1" descriptionLevel="Meso">
<networkResource ref="ne1"/>
</level>
</network>
</networks>
</topology>
<functionalInfrastructure>
<operationalPoints>
<operationalPoint id="op01">
<name name="Pulsnitz" language="de"/>
<spotLocation id="cf332d07-aa04-4ac0-b867-0e6dd35060f7" netElementRef="ne1">
<geometricCoordinate positioningSystemRef="gps_4326" x="51.188164" y="14.013795"/>
</spotLocation>
<designator register="RL100" entry="DPUL"/>
<designator register="IBNR" entry="8012685"/>
<opOperations>
<opOperation operationalType="station"/>
</opOperations>
</operationalPoint>
</operationalPoints>
</functionalInfrastructure>
</infrastructure>
</railML>
This example defines an operational point with the ID op01, representing a network location named "Pulsnitz".
It’s located using <spotLocation> element that references the associated network element ne1, which is a non-linear netElement defined in the topology section of the infrastructure subschema.
The location is further specified by geographic coordinates (x="51.188164", y="14.013795") using the positioning system gps_4326, which is assumed to be defined in the common section of the railML file with a reference the WGS84 coordinate system via its corresponding EPSG code, as defined in the common section of the railML file.
The operational point is identified by two designators: "DPUL" from the RL100 register and "8012685" from the IBNR system.
The <opOperations> element classifies the point as a station through the operationalType="station" attribute.
Types of OPs
The type of an <operationalPoint> and its abilities can be described with its child elements. A detailed list of examples how to specify the different types of OPs can be found here: Dev:Types of Operational Points .
Identity
As described above <operationalPoint>s group infrastructure elements. Which "real" infrastructure elements are aggregated to an <operationalPoint> depends on the context (use case) and the accuracy requirement of the timetable. Timetables that aim more at passenger information will define as <operationalPoint> what a traveller perceives as an access point - for example, consider Berlin Hbf as an <operationalPoint>. Timetables that have more of an operational background will be a bit more detailed and e.g. distinguish between freight and passenger stations or even show Berlin Hbf as three <operationalPoint>s (see also example below).
Unless specified by a concrete use case, railML® generally allows the mapping of several such graduation levels in one file via @belongsToParent. So to stay with the example of Berlin Hbf, the view of the passenger and the operational view can be part of the same railML® file by aggregating the operational view into the view of the passenger. For a reading program, this means that it may have to find the required level itself by tracing the @belongsToParent references: From <timetable>, @locationRef makes a mandatory reference to an <operationalPoint> element. However, this "initial <operationalPoint> element" can have any number of @belongsToParent levels, just as there can be other <operationalPoint> elements that in turn refer to the initial element by @belongsToParent. A reading program may have to expect to find the desired identity information not directly at the initial <operationalPoint> element, but at levels above or below it.
Using designator concept the identity of an <operationalPoint> shall be defined using <designator>. This allows providing identity information in different registers. With this it allows reading implementors to use the identification information that is most convenient for them to use - always considering that the desired register my not be on the level of the "initial" <operationalPoint> referenced by the timetable. Typically different registers are used on different levels of an aggregated <operationalPoint> (see image).
The designator concept also allows to express the fact that one location may be referred to differently in different contexts, e.g. at the border point between two infrastructure managers. While @register addresses a designator element from the Registers.xml (link to the railML® website) codelist, @entry specifies the ID used in the context defined by the @register. Salzburg main station is noted as MASB in the register RL100 (OP-register of Deutsche Bahn) and as Sb in the register DB640 (OP-register of ÖBB).
When it comes to using multiple levels of OP descriptions there are three cases to consider:
- The parent <operationalPoint> and the child <operationalPoint>s have a designator each. Useful to group stations and provide mesoscopic as well as microscopic information. This can also be useful when providing timetable information on a commercial and operational level.
- Only the parent <operationalPoint> has a designator. This may be the case if a station is split into two or more sections to provide different information for each child <operationalPoint>. E.g. one part of a station is used for passengers while another is used for goods (@trafficType).
- Only the children provide identity information via designators while the parent <operationalPoint> still carries common information such as a common name or description. This is may be useful to provide common information to be used in passenger information and thus make it look like a single station, although on an operational level it is multiple stations/stopping points. This may also be useful when doing routing through a rail network. Transfer between stations that are grouped like this will need to be considered differently when calculating the transfertime between trains.
Example of a grouped station where only the parent has a designator. This separation into two may have the reason that two destination texts could be provided like this.:
<operationalPoint id="op01">
<name name="Andermatt" language="de"/>
<opOperations>
<opOperation operationalType="station"/>
</opOperations>
<designator register="DIDOK" entry="AND"/>
</operationalPoint>
<operationalPoint id="op02" belongsToParent="op01">
<name name="Andermatt" language="de"/>
</operationalPoint>
<operationalPoint id="op03" belongsToParent="op01"/>
<name name="Andermatt Autoverlad" language="de"/>
</operationalPoint>
Example of a station that is split into two stations operation-wise but considered a combined station in terms of passenger information and ticketing. When using this structure in a context of slot ordering the designators with register RIL100 (national German) and PLC (TAF/TAP TSI) need to be considered. Export to a system such as Hafas would however rather consider the top-level designator of the register IBNR:
<operationalPoint id="op01">
<name name="Lüneburg"/>
<opOperations>
<opOperation operationalType="station"/>
</opOperations>
<designator register="IBNR" entry="8000238"/>
</operationalPoint>
<operationalPoint id="op02" belongsToParent="op01">
<name name="Lüneburg" language="de"/>
<designator register="RIL100" entry="ALBG"/>
<designator register="PLC" entry="DE16598"/>
</operationalPoint>
<operationalPoint id="op03" belongsToParent="op01">
<name name="Lüneburg West" language="de"/>
<designator register="RIL100" entry="ALBGW"/>
<designator register="PLC" entry="DE16601"/>
</operationalPoint>
Example of a grouped station with RIL100 designators only provided for the child OP's (IBNR is provided on all levels though):
<operationalPoint id="op01">
<name name="Berlin Hauptbahnhof" language="de"/>
<propOperational operationalType="station"/>
<designator register="IBNR" entry="8096003"/>
</operationalPoint>
<operationalPoint id="op02" belongsToParent="op01">
<name name="Berlin Haupbahnhof (tief)" language="de"/>
<designator register="RL100" entry="BL"/>
<designator register="IBNR" entry="8098160"/>
</operationalPoint>
<operationalPoint id="op03" belongsToParent="op01">
<name name="Berlin Hauptbahnhof (S-Bahn)" language="de"/>
<designator register="RL100" entry="BHBF"/>
<designator register="IBNR" entry="8089021"/>
</operationalPoint>
<operationalPoint id="op04" belongsToParent="op01">
<name name="Berlin Hauptbahnhof (Fernverkehr)" language="de"/>
<designator register="RL100" entry="BHF"/>
<designator register="IBNR" entry="8011160"/>
</operationalPoint>
Example of a grouped station with individual designators:
<operationalPoint id="op01" type="operationalName">
<name name="Dresden" language="de"/>
<opOperations>
<opOperation operationalType="station"/>
</opOperations>
<designator register="RL100" entry="DDRE"/>
</operationalPoint>
<operationalPoint id="op02" belongsToParent="op01">
<name name="Dresden Hauptbahnhof" language="de"/>
<designator register="RL100" entry="DH"/>
<designator register="IBNR" entry="8010085"/>
</operationalPoint>
<operationalPoint id="op03" belongsToParent="op01">
<name name="Dresden Neustadt" language="de"/>
<designator register="RL100" entry="DN"/>
<designator register="IBNR" entry="8010089"/>
</operationalPoint>
<operationalPoint id="op04" belongsToParent="op01">
<nane name="Dresden Mitte" language="de"/>
<designator register="RL100" entry="DM"/>
<designator register="IBNR" entry="8013444"/>
</operationalPoint>
<operationalPoint id="op05" belongsToParent="op01">
<name name="Dresden Freiberger Strasse" language="de"/>
<designator register="RL100" entry="DFS"/>
<designator register="IBNR" entry="8011431"/>
</operationalPoint>
<operationalPoint id="op06" belongsToParent="op02">
<name name="Dresden Hbf Wiener Strasse" language="de"/>
<designator register="IBNR" entry="8089294"/>
</operationalPoint>
<operationalPoint id="op07" belongsToParent="op02">
<name name="Dresden Hbf Strehlener Strasse" language="de"/>
<designator register="IBNR" entry="8013449"/>
</operationalPoint>
Overwriting of attributes/elements in lower levels of an <operationalPoint>s hierarchy
An <operationalPoint> that refers to a parent <operationalPoint> via an @belongsToParent overwrites the attributes and elements of the parent <operationalPoint> if explicitely defined. If an element is specified on an <operationalPoint> that uses a @belongsToParent any information provided with that element on a higher layer of the <operationalPoint>-tree is overwritten. There is no merging of element-information from different levels. The same applies for attributes of <operationalPoint>.
In short, attributes and elements specified on lower levels of an OP hierarchy overwrite the same attributes and elements specified on a higher level. To make this rule easier understood the following example is provided. The first snippet shown is an extended variant of the known example of Dresden, the second snippet is a version where all implied information from higher levels of the hierarchy are explicitly shown. Please note that the example provided here is not necessarily in line with the real infrastructure available at Dresden.
<operationalPoint id="op01" timezone="Europe/Berlin">
<name name="Dresden" language="de"/>
<opOperations>
<opOperation operationalType="station"/>
</opOperations>
<designator register="RL100" entry="DDRE"/>
</operationalPoint>
<operationalPoint id="op02" belongsToParent="op01">
<name name="Dresden Hauptbahnhof" language="de"/>
<opEquipment>
<ownsTrack ref="track11"/>
<ownsTrack ref="track12"/>
</opEquipment>
<designator register="RL100" entry="DH"/>
<designator register="IBNR" entry="8010085"/>
</operationalPoint>
<operationalPoint id="op03" belongsToParent="op01">
<name name="Dresden Neustadt" language="de"/>
<designator register="RL100" entry="DN"/>
<designator register="IBNR" entry="8010089"/>
</operationalPoint>
<operationalPoint id="op04" belongsToParent="op01">
<name name="Dresden Mitte" language="de"/>
<designator register="RL100" entry="DM"/>
<designator register="IBNR" entry="8013444"/>
</operationalPoint>
<operationalPoint id="op05" belongsToParent="op01">
<name name="Dresden Freiberger Strasse" language="de"/>
<designator register="RL100" entry="DFS"/>
<designator register="IBNR" entry="8011431"/>
</operationalPoint>
<operationalPoint id="op06" belongsToParent="op02">
<name name="Dresden Hbf Wiener Strasse" language="de"/>
<opEquipment>
<ownsTrack ref="track01"/>
</opEquipment>
<designator register="IBNR" entry="8089294"/>
</operationalPoint>
<operationalPoint id="op07" belongsToParent="op02">
<name name="Dresden Hbf Strehlener Strasse" language="de"/>
<designator register="IBNR" entry="8013449"/>
</operationalPoint>
The following xml snippet is an equivalent description with all implicit information inherited from higher level specified explicitly (highlighted version is available under File:Overrides.Op.svg (link to the railML® website)):
<operationalPoint id="op01" timezone="Europe/Berlin">
<name name="Dresden" language="de"/>
<opOperations>
<opOperation operationalType="station"/>
</opOperations>
<designator register="RL100" entry="DDRE"/>
</operationalPoint>
<operationalPoint id="op02" belongsToParent="op01"
timezone="Europe/Berlin">
<name name="Dresden Hauptbahnhof" language="de"/>
<opEquipment>
<ownsTrack ref="track11"/>
<ownsTrack ref="track12"/>
</opEquipment>
<opOperations>
<opOperation operationalType="station"/>
</opOperations>
<designator register="RL100" entry="DH"/>
<designator register="IBNR" entry="8010085"/>
</operationalPoint>
<operationalPoint id="op03" belongsToParent="op01"
timezone="Europe/Berlin">
<name name="Dresden Neustadt" language="de"/>
<opOperations>
<opOperation operationalType="station"/>
<designator register="RL100" entry="DN"/>
<designator register="IBNR" entry="8010089"/>
</operationalPoint>
<operationalPoint id="op04" belongsToParent="op01"
timezone="Europe/Berlin">
<name name="Dresden Mitte" language="de"/>
<opOperations>
<opOperation operationalType="station"/>
</opOperations>
<designator register="RL100" entry="DM"/>
<designator register="IBNR" entry="8013444"/>
</operationalPoint>
<operationalPoint id="op05" belongsToParent="op01"
timezone="Europe/Berlin">
<name name="Dresden Freiberger Strasse" language="de"/>
<opOperations>
<opOperation operationalType="station"/>
</opOperations>
<propService passenger="true"/>
<designator register="RL100" entry="DFS"/>
<designator register="IBNR" entry="8011431"/>
</operationalPoint>
<operationalPoint id="op06" belongsToParent="op02"
timezone="Europe/Berlin">
<name name="Dresden Hbf Wiener Strasse" language="de"/>
<opEquipment>
<ownsTrack ref="track01"/>
</opEquipment>
<opOperations>
<opOperation operationalType="station"/>
</opOperations>
<designator register="IBNR" entry="8089294"/>
</operationalPoint>
<operationalPoint id="op07" belongsToParent="op02"
timezone="Europe/Berlin">
<name name="Dresden Hbf Strehlener Strasse" language="de"/>
<opEquipment>
<ownsTrack ref="track11"/>
<ownsTrack ref="track12"/>
</opEquipment>
<opOperations>
<opOperation operationalType="station"/>
</opOperations>
<designator register="IBNR" entry="8013449"/>
</operationalPoint>
As can be seen in the example direct child elements of <operationalPoint> are completely overwritten if specified on a lower level of the <operationalPoint> tree. No merging is performed. If an element can be specified more than once for an <operationalPoint> specifiying it even once on a lower level replaces all higher level instances of that element for the lower level <operationalPoint>. Since aggregation however is an integral part of the general concept when defining <operationalPoint>s in a hierarchy, it may happen that the higher level designators may still be semantically related to one another.
Notes
Best practice was suggested 2025-03-07 by railML.org e.V. partner Jernbanedirektoratet (link to the railML® website) on the workshop devoted to the development of railML Advanced example (link to the railML® website). Approved by the coordinator (link to the railML® website) of the Infrastructure subschema on 2025-03-21.
Example was reviewed by the coordinator (link to the railML® website) of the Infrastructure subschema on 2026-01-02.
Open Issues
References
