From railML 2 Wiki
Jump to: navigation, search


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

Multiplicity / Anzahl / Multiplicité


Semantics / Bedeutung / Sémantique

The element <ocp> defines operational or time measurement points of a railway network in the general sense (such as stations, stops, line changes, signals, etc.) required by the timetable of a train.

Das Element <ocp> definiert betriebliche Punkte oder Fahrzeit-Messpunkte eines Eisenbahn-Netzes im allgemeinen Sinne (wie Bahnhöfe, Haltestellen, Linienwechsel, Signale usw.), die für den Fahrplan eines Zuges erforderlich sind.
Please, be aware of the semantic constraint(s)!

Attributes of ocp / Attribute von ocp / Attributs de ocp

  • id: XML-file-wide unique, machine-interpretable identity, required for later referencing that element internally. For a detailed explanation see Dev:identities.
    XML-Datei-weit eindeutige, maschineninterpretierbare Identität, die für die spätere interne Referenzierung dieses Elements erforderlich ist. Für eine detaillierte Erklärung siehe Dev:identities.
  • code (introduced with version 2.1): Machine-interpretable string (e.g. an abbreviation) used for identification of the object across exchange partners, usecase specific uniqueness constraints may apply. Please see our description of the differences between id, code and human-readable identifiers.
    Maschineninterpretierbare Zeichenkette (z.B. Abkürzung), die zur Identifizierung des Objekts auch bei Austauschpartnern verwendet wird, wobei spezifische Eindeutigkeitsbeschränkungen gelten können. Bitte beachten Sie unsere Erläuterung zu den Unterschieden zwischen id, code and menschenlesbaren Kennzeichnungen.
    For more general reasons, use this generic attribute instead
  • name: Established, human-readable short string, giving the object a name. Not intended for machine interpretation, please see our notice on human interpretable data fields.
    Etablierte, menschenlesbare kurze Zeichenkette, die das Objekt benennt. Nicht zur maschinellen Interpretation bestimmt, siehe Hinweise zu menschenlesbaren Datenfeldern.
  • description: Human-readable, more detailed description as addition to the name. It should give additional explanations or hints to the contents of this element. Not intended for machine interpretation, please see our notice on human interpretable data fields.
    Menschenlesbare, detailliertere Beschreibung als Ergänzung zu name. Sie soll zusätzliche Erläuterungen oder Hinweise auf den Inhalt dieses Elements geben. Nicht zur maschinellen Interpretation bestimmt, siehe Hinweise zu menschenlesbaren Datenfeldern.
  • 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 defines the language used for name and description. Use <additionalName> to provide a name and/or description in other languages.
  • 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 (external link), e.g. "Europe/Berlin".
    siehe auch Zeitzonen-Datenbank (external link)
    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

Syntactic Constraints / Syntaktische Beschränkungen / Contraintes syntactiques

  • id: xs:ID, required
    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 (_)

  • 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

Semantic Constraints / Semantische Beschränkungen / Contraintes semantiques

Private-cloud-icon.png Proposed Semantic Constraint "IS:005":
An <ocp> that refers to a parent <ocp> via an @parentOcpRef overwrites the attributes of the parent <ocp> if explicitely defined.
Proposed on June 19th 2019
FIXME: add Link to discussion!
Please, recognize our guidelines on semantic constraints

Best practice & Examples / Empfohlene Anwendung & Beispiele / Bonnes pratiques & exemples

Example of OCP Pulsnitz from demo file East Saxony railway network by FBS (link to the railML® website, railML®; by railML® partner iRFP)

      <ocp id='ocp01' name='Pulsnitz' type='operationalName'>
        <propOperational operationalType='station' orderChangeable='true' ensuresTrainSequence='true'/>
        <propService passenger='true' service='true'/>
          <summary hasHomeSignals='true' hasStarterSignals='true' hasSwitches='true'/>
        <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>: 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>.