- 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.
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>.