- 1 Scheme description / Schemenbeschreibung / Description du schéma
- 2 Best practice & Examples / Empfohlene Anwendung & Beispiele / Bonnes pratiques & exemples
- 3 Notes / Anmerkungen / Notes
- 4 Open issues / Offene Punkte/Pedenzen / Questions ouvertes
Scheme description / Schemenbeschreibung / Description du schéma
Position of ocp in the XML-Tree / Position von ocp im XML-Baum / position de ocp dans l’aborescence XML
- Parent: <operationControlPoints>
- Children: <additionalName> (introduced with version 2.1), <any>, <area>, <geoCoord>, <propEquipment>, <propOperational>, <propOther>, <propService>, <tsi> (introduced with version 2.1) (deprecated with version 2.3), <designator> (introduced with version 2.2)
Semantics / Bedeutung / Sémantique
An <ocp> is a container for Operation or Control Points (places). Each ocp illustrates one operation or control place in the infrastructure.
Attributes of ocp / Attribute von ocp / Attributs de ocp
- id: This is the unique identifier which is used to refer to the current element. It is used for XML file internal unambiguous references. How to handle it?
- code (introduced with version 2.1): This is a short string for typical, specific abbreviations, used in different systems with the same understanding.
For more general reasons, use this generic attribute instead
- name: This is a short name for the current item.
- description: This is a more detailed description as addition to the short name. It shall allow a short overview or hints to the contents of this data set.
- xml:lang (introduced with version 2.1): This is a unique identifier of language. It uses basically the language standard IETF BCP 47 (external link) which may be different to ISO 639-1 (external link) or ISO 639-2 (external link). For mapping hints see relation to other standards (external link).
This is used for defining name and description.
- number (deprecated with version 2.1): This is an arbitrary number e. g. as prefix in signal names or similar. Please, use <designator> (introduced with version 2.2) instead.
- abbrevation (deprecated with version 2.1): This is the abbreviation of an ocp as it used e. g. in time tables. Please, use <designator> (introduced with version 2.2) instead.
- timezone: (introduced with version 2.1) This is the timezone as defined in the tz database, e.g. "Europe/Berlin".
siehe auch Wikipedia Zeitzonen-Datenbank
This timezone marks the railway time at a station regardless of the local time (outside the station), e.g. station of Kaliningrad at UTC+04 (Europe/Moscow), but the city itself at UTC+03 (Europe/Kaliningrad).
- type: This is the meaning of the name. Possible values are:
- operationalName the ocps name under operational aspects
- trafficName the ocps name under traffic aspects
- localName an name in the local language
- other:anything Any value that does not fit any value from the previous enumeration list, fulfilling the constraint: at minimum two characters, whitespace is not allowed.
(introduced with version 2.2)
- parentOcpRef: references the one and only parent ocp of this ocp
Constraints / Beschränkungen / Contraintes
- id: xs:ID, mandatory
a string, starting with a letter (a..zA..Z) or an underscore (_),
followed by a non-colonized and non-spaced string consisting of letters, digits, points (.), dashes (-) or underscores (_)
- code: xs:string, optional
- name: xs:string, optional
- description: xs:string, optional
- type: union of (restriction of xs:string, tOtherEnumerationValue); tOtherEnumerationValue is an arbitrary string starting with 'other:' followed by at minimum two characters, white space not allowed for extending railML enumeration lists; optional
- number xs:string, optional
- abbrevation xs:string, optional
- timezone: xs:string; timezone as defined in the tz database, e.g. "America/New_York"
- parentOcpRef: xs:IDREF
Best practice & Examples / Empfohlene Anwendung & Beispiele / Bonnes pratiques & exemples
<ocp id='ocp01' name='Pulsnitz' type='operationalName'> <propOperational operationalType='station' orderChangeable='true' ensuresTrainSequence='true'/> <propService passenger='true' service='true'/> <propEquipment> <summary hasHomeSignals='true' hasStarterSignals='true' hasSwitches='true'/> </propEquipment> <area name='Pulsnitz, Stadt' number='14292430' zip='01896'/> <geoCoord coord='51.188164 14.013795' epsgCode='4326' extraHeight='266.43' heightEpsgCode='5783'/> <designator register='RL100' entry='DPUL'/> <designator register='IBNR' entry='8012685'/> </ocp>
- <ocp>: the ocp. In the example it is named Pulsnitz, which is an operational name, and handled internally (in the scope of the railML® File) with id ocp01.
- <propOperational>: The element declares operational aspects. Here the ocp becomes a station. ensuresTrainSequence='true' means, that the ocp is protected with a signal. orderChangeable='true' means that the train sequence can be changed, eg via a passing loop
- <propService>: The element declares service aspects. This is a passanger station (rather than eg a freight yard) and it offers services (eg an information desk).
- <propEquipment>: a container for either a single <summary> or an open number of <trackRef> elements. In Pulsnitz, there are homesignals, startersignals and switches.
- <area>: defines the spatial scope of the station. Pulsnitz station serves for the town of Pulsnitz with the Community Identification Number 14292430 and the zip area 01896
- <geoCoord>: the spacial position of the ocp. coordinates and height, plus the EPSG references for height and coordinates respectively
- <designator>: How is the ocp adressed in different registers? register adresses a <register> element of codelist Registers.xml. Pulsnitz station is noted as DPUL in RL100 (OCP-register of Deutsche Bahn) and as 8012685 in IBNR (Internationale Bahnhofsnummer)
Notes / Anmerkungen / Notes
ocps are needed to organise railway operations. An ocp is a grouping of infrastructure elements sharing traffic or operational (interlocking) functions. So, they typically but not necessarily fit to what is commonly known as a 'station'. An ocp typically owns one ore more signal boxes and/or platforms.
Grouping of ocps is done using the attribute parentOcpRef. If both, the referencing ocp and the parent ocp have the same attribute, the one from the referencing ocp overwrites the one from the parent ocp. Example: The parent OCP 'Dresden' has passenger traffic. The child OCP 'Bft. Dresden-Altstadt' does not have.
Open issues / Offene Punkte/Pedenzen / Questions ouvertes
Discussed within timetable meeting in Vienna 16.03.2015:
code: This attribute was dedicated to be a functional identification for an <ocp>. But an importing timetable program should use the sub element <designator> instead to identify the <ocp>. The recommended practice would be to let the user choose, what kind of register is used to identify an <ocp>.