IS:ocp

ocp
 

Scheme description / Schemenbeschreibung

Position of ocp in the XML-Tree / Position von ocp im XML-Baum

• 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), <controllerRef> (introduced with version 2.4), <propPassengerInfo> (introduced with version 2.5)

Multiplicity / Anzahl

[1..∞]

Semantics / Bedeutung

ocps are needed to organise railway operations. An ocp is a grouping of infrastructure elements sharing traffic or operational (interlocking) functions. They typically but not necessarily fit to what is commonly known as a 'station'. An ocp typically owns one or more signal boxes and/or platforms. An <ocp> also is a time measurement point, i.e. a reference point from the <timetable> to the infrastructure.

ocps werden benötigt, um den Eisenbahnbetrieb zu organisieren. Ein ocp ist eine Gruppierung von Infrastrukturelementen, die sich verkehrliche oder betriebliche (Stellwerks-)Funktionen teilen. Sie entsprechen in der Regel, aber nicht notwendigerweise, dem, was man gemeinhin als 'Bahnhof' bezeichnet. Zu einem ocp gehören in der Regel ein oder mehrere Stellwerke und/oder Bahnsteige. Ein <ocp> ist auch ein Zeitmesspunkt, d.h. ein Referenzpunkt vom Fahrplan (<timetable>) zur Infrastruktur.
 
Please, be aware of the semantic constraint(s)!

Attributes of ocp / Attribute von 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.
• 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: (introduced with version 2.2) 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. Please, apply Dev:usingAny accordingly.

• parentOcpRef: (introduced with version 2.1) With this attribute a parent <ocp> may be referenced. Doing so will allow grouping multiple <ocp> below a single parent <ocp>. This is used if, for example, a station is separated into two or more parts, such as a passenger station and a freight station, that nonetheless are considered the same station.

Syntactic Constraints / Syntaktische Beschränkungen

• 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 (_)
• code: xs:string, optional
• name: xs:string, optional
• description: xs:string, optional
• xml:lang: xs:language, language identification, 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

Semantic Constraints / Semantische Beschränkungen

Semantic Constraint "IS:005":   An <ocp> that refers to a parent <ocp> via an @parentOcpRef overwrites the attributes and elements of the parent <ocp> if explicitely defined. If an element is specified on an <ocp> that uses a @parentOcpRef any information provided with that element on a higher layer of the <ocp>-tree is overwritten. There is no merging of element-information from different levels. The same applies for attributes of <ocp>. For further information see example below.   Proposed on June 19th 2019 Approved on July 14th 2022 FIXME: add Link to discussion! Please, recognize our guidelines on semantic constraints

Semantic Constraint "IS:015":   When specifying @parentOcpRef for an <ocp> circles are not allowed. That means that when following the chain of @parentOcpRef no <ocp> shall be visited twice.   Proposed on July 14th 2022 Approved on August 11th 2022 FIXME: add Link to discussion! Please, recognize our guidelines on semantic constraints

Best practice & Examples / Empfohlene Anwendung & Beispiele

General

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'/>
        <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 code () 01896
• <geoCoord>: the spacial position of the ocp. coordinates and height, plus the EPSG references for height and coordinates respectively

Types of OCPs

The type of an <ocp> and its abilities can be described with its child elements. A detailed list of examples how to specify the different types of OCPs can be found here: Dev:Types_of_ocps

Identity

As described above <ocp>s group infrastructure elements. Which "real" infrastructure elements are aggregated to an <ocp> depends on the context (use case) and the accuracy requirement of the timetable. Timetables that aim more at passenger information will define as <ocp> what a traveller perceives as an access point - for example, consider Berlin Hbf as an <ocp>. 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 <ocp>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 @parentOcpRef. 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 @parentOcpRef references: From <timetable>, <ocpTT> makes a mandatory reference to an <ocp> element. However, this "initial <ocp> element" can have any number of @parentOcpRef levels, just as there can be other <ocp> elements that in turn refer to the initial element by @parentOcpRef. A reading program may have to expect to find the desired identity information not directly at the initial <ocp> element, but at levels above or below it.

With the introduction of designator concept the identity of an <ocp> 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" <ocp> referenced by the timetable. Typically different registers are used on different levels of an aggregated <ocp> (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 adresses a <register> element from the Registers.xml codelist, entry specifies the ID used in the context defined by the register. Salzburg main station is noted as MASB in the register RL100 (OCP-register of Deutsche Bahn) and as Sb in the register DB640 (OCP-register of ÖBB).

When it comes to using multiple levels of ocp descriptions there are three cases to consider:

• The parent <ocp> and the child <ocp>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 <ocp> 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 <ocp>. 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 <ocp> 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.:

      <ocp id='ocp01' name='Andermatt' type='operationalName'>
        <propOperational operationalType='station'/>
        <propService passenger='true'/>
        <designator register='DIDOK' entry='AND'/>
      </ocp>
      <ocp id='ocp02' name='Andermatt' type='operationalName' parentOcpRef='ocp01'/>
      <ocp id='ocp03' name='Andermatt Autoverlad' type='operationalName' parentOcpRef='ocp01'/>

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:

      <ocp id='ocp01' name='Lüneburg' type='operationalName'>
        <propOperational operationalType='station'/>
        <propService passenger='true'/>
        <designator register='IBNR' entry='8000238'/>
      </ocp>
      <ocp id='ocp02' name='Lüneburg' type='operationalName' parentOcpRef='ocp01'>
        <designator register='RIL100' entry='ALBG'/>
        <designator register='PLC' entry='DE16598'/>
      </ocp>
      <ocp id='ocp03' name='Lüneburg West' type='operationalName' parentOcpRef='ocp01'>
        <designator register='RIL100' entry='ALBGW'/>
        <designator register='PLC' entry='DE16601'/>
      </ocp>

Example of a grouped station with RIL100 designators only provided for the child <ocp>'s (IBNR is provided on all levels though):

      <ocp id='ocp01' name='Berlin Hauptbahnhof' type='trafficName'>
        <propOperational operationalType='station'/>
        <propService passenger='true'/>
        <designator register='IBNR' entry='8096003'/>
      </ocp>
      <ocp id='ocp02' name='Berlin Haupbahnhof (tief)' type='operationalName' parentOcpRef='ocp01'>
        <designator register='RL100' entry='BL'/>
        <designator register='IBNR' entry='8098160'/>
      </ocp>
      <ocp id='ocp03' name='Berlin Hauptbahnhof (S-Bahn)' type='operationalName' parentOcpRef='ocp01'>
        <designator register='RL100' entry='BHBF'/>
        <designator register='IBNR' entry='8089021'/>
      </ocp>
      <ocp id='ocp04' name='Berlin Hauptbahnhof (Fernverkehr)' type='operationalName' parentOcpRef='ocp01'>
        <designator register='RL100' entry='BHF'/>
        <designator register='IBNR' entry='8011160'/>
      </ocp>

Example of a grouped station with individual designators:

      <ocp id='ocp01' name='Dresden' type='operationalName'>
        <propOperational operationalType='station'/>
        <propService passenger='true'/>
        <designator register='RL100' entry='DDRE'/>
      </ocp>
      <ocp id='ocp02' name='Dresden Hauptbahnhof' type='operationalName' parentOcpRef='ocp01'>
        <designator register='RL100' entry='DH'/>
        <designator register='IBNR' entry='8010085'/>
      </ocp>
      <ocp id='ocp03' name='Dresden Neustadt' type='operationalName' parentOcpRef='ocp01'>
        <designator register='RL100' entry='DN'/>
        <designator register='IBNR' entry='8010089'/>
      </ocp>
      <ocp id='ocp04' name='Dresden Mitte' type='operationalName' parentOcpRef='ocp01'>
        <designator register='RL100' entry='DM'/>
        <designator register='IBNR' entry='8013444'/>
      </ocp>
      <ocp id='ocp05' name='Dresden Freiberger Strasse' type='operationalName' parentOcpRef='ocp01'>
        <designator register='RL100' entry='DFS'/>
        <designator register='IBNR' entry='8011431'/>
      </ocp>
      <ocp id='ocp06' name='Dresden Hbf Wiener Strasse' type='operationalName' parentOcpRef='ocp02'>
        <designator register='IBNR' entry='8089294'/>
      </ocp>
      <ocp id='ocp07' name='Dresden Hbf Strehlener Strasse' type='operationalName' parentOcpRef='ocp02'>
        <designator register='IBNR' entry='8013449'/>
      </ocp>

The attribute code was dedicated to be a functional identification for an <ocp>. However an importing timetable program should first use the sub element <designator> instead to identify the <ocp>. The recommended practice for a reading program would be to let the user choose, what kind of register is used to identify an <ocp> if more than one would apply. Nevertheless, also if @code is used the same 3 cases need to be distinguished as outlined above.

Overwriting of attributes/elements in lower levels of an <ocp>s hierarchy

As specified with SemCon IS:005 attributes and elements specified on lower levels of an ocp 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.

      <ocp id='ocp01' name='Dresden' type='operationalName' timezone='Europe/Berlin'>
        <propOperational operationalType='station'/>
        <propService passenger='true'/>
        <designator register='RL100' entry='DDRE'/>
      </ocp>
      <ocp id='ocp02' name='Dresden Hauptbahnhof' parentOcpRef='ocp01'>
        <area name="Dresden-Altstadt" zip="01069"/>
        <propEquipment>
          <summary hasSwitches='true' signalBox='electro-mechanical'/>
          <trackRef ref='track11'/>
          <trackRef ref='track12'/>
        </propEquipment>
        <designator register='RL100' entry='DH'/>
        <designator register='IBNR' entry='8010085'/>
      </ocp>
      <ocp id='ocp03' name='Dresden Neustadt' parentOcpRef='ocp01'>
        <designator register='RL100' entry='DN'/>
        <designator register='IBNR' entry='8010089'/>
      </ocp>
      <ocp id='ocp04' name='Dresden Mitte' parentOcpRef='ocp01'>
        <designator register='RL100' entry='DM'/>
        <designator register='IBNR' entry='8013444'/>
      </ocp>
      <ocp id='ocp05' name='Dresden Freiberger Strasse' parentOcpRef='ocp01'>
        <designator register='RL100' entry='DFS'/>
        <designator register='IBNR' entry='8011431'/>
      </ocp>
      <ocp id='ocp06' name='Dresden Hbf Wiener Strasse' parentOcpRef='ocp02'>
        <propEquipment>
          <summary hasSwitches='false' signalBox='none'/>
          <trackRef ref='track01'/>
        </propEquipment>
        <designator register='IBNR' entry='8089294'/>
      </ocp>
      <ocp id='ocp07' name='Dresden Hbf Strehlener Strasse' parentOcpRef='ocp02'>
        <designator register='IBNR' entry='8013449'/>
      </ocp>

The following xml snippet is an equivalent description with all implicit information inherited from higher level specified explicitly:

As can be seen in the example direct child elements of <ocp> are completely overwritten if specified on a lower level of the <ocp> tree. No merging is performed. If an element can be specified more than once for an <ocp> specifiying it even once on a lower level replaces all higher level instances of that element for the lower level <ocp>. Since aggregation however is an integral part of the general concept when defining <ocp>s in a hierarchy, it may happen that the higher level designators may still be semantically related to one another.

Notes / Anmerkungen

Not yet described. / Noch nicht beschrieben.

Open issues / Offene Punkte/Pendenzen

Not yet described. / Noch nicht beschrieben.