IS:designator ocp

designator
 

Scheme description / Schemenbeschreibung

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

• Parent: <ocp>
• Children: Not yet described. / Noch nicht beschrieben.

Multiplicity / Anzahl

[1..1]

Semantics / Bedeutung

There are normally several abbreviations and/or numbers for the same <ocp> (station), even in one country. So, the writing and reading software of a railML file can have different external primary keys for the same <ocp> (station).

The <designator> sequence allows to enumerate more than one external primary key for one <ocp>. Such, it defines the mapping from one to another register.

It supersets the older (now deprecated) attributes 'code' and 'abbrev[i]ation' of <ocp>.

Attributes of designator / Attribute von designator

• register: Enumeration defining the catalogue, index, or directory where the external primary key comes from or refers to. See below for a list of the currently registered catalogues.

• entry: Contains the external primary key of the OCP belonging to the referred register. To fulfill the requirements of a primary key, entry must be unique through all other entries of <ocp>s with the same 'register'.

• beginDate: Date from when (including) the entry becomes or became valid. The entry can be considered as "valid since ever" if this attribute is not used (no other entry of that register was valid during the validity period of the file). Before beginDate, either the whole <ocp> wasn't part of the register or there is another entry for that <ocp> and register with a lower endDate.

• endDate: Date (including) when the entry becomes or became invalid. The entry can be considered as valid until canceled if this attribute is not used (no other entry of that register will become valid during the validity period of the file as known so far). After endDate, either the whole <ocp> will no longer be part of the register or there is another entry for that <ocp> and register with a higher beginDate.

Syntactic Constraints / Syntaktische Beschränkungen

• register xs:enumeration, required: For short-time or internal purposes new enumeration entries can be used additional to that of railML's XSD. But for official data exchange between two software programs it is _strongly_ recommended that each new 'register' entry has to be 'registered' at the Scheme Coordinator.

• entry xs:string, required: May be a string or a number depending on the 'register'. This means, some 'register' entries require a pure numeric number and do not allow characters or other signs. This is not forced by railML so far. entry must be unique through all other entries of <ocp>s with the same 'register'.

• beginDate xs:date, optional: Must be lower or equal endDate if both are used. Must not overlap with other validity periods of the same register for the same <ocp>.

• endDate xs:date, optional: Must be higher or equal beginDate if both are used. Must not overlap with other validity periods of the same register for the same <ocp>.

Best practice & Examples / Empfohlene Anwendung & Beispiele

<ocp ... name='Passau Hbf.' ...>
    <designator register='ENEE' entry='80-26506-6'/>
    <designator register='PLC' entry='DE18274'/>
    <designator register='IBNR' entry='8000298'/>
    <designator register='RL100' entry='NPA'/>
    <designator register='DB640' entry='Pa'/>
</ocp>

<ocp ... name='Fieberbrunn' ...>
    <designator register='ENEE' entry='81-01155-1'/>
    <designator register='PLC' entry='AT1155'/>
    <designator register='IBNR' entry='8100053'/>
    <designator register='DB640' entry='Fie' endDate='2011-12-31'/>
    <designator register='DB640' entry='Hch H2' beginDate='2012-01-01'/>
    <designator register='RL100' entry='XAFB'/>
</ocp>

<ocp ... name='Buchs (SG)' ...>
    <designator register='ENEE' entry='85-09404-X'/>
    <designator register='PLC' entry='CH9404'/>
    <designator register='IBNR' entry='8509404'/>
    <designator register='DB640' entry='Bc'/>
    <designator register='RL100' entry='XSBU'/>
    <designator register='DIDOK' entry='BU'/>
</ocp>

Examples concerning beginDate and endDate:

   <designator register='DB640' entry='Bc1'/>
   <designator register='DB640' entry='Bc2' beginDate='2001-01-01'/>

'Bc1' was valid until 31.12.2000.

   <designator register='DB640' entry='Bc1' endDate='2013-01-01'/>
   <designator register='DB640' entry='Bc2'/>

'Bc1' is valid until 01.01.2013, 'Bc2' will be valid from 02.01.2013.

   <designator register='DB640' entry='Bc1' beginDate='2001-01-01' endDate='2013-01-01'/>
   <designator register='DB640' entry='Bc2'/>

'Bc2' was valid until 31.12.2000 and will be valid from 02.01.2013. (A case not very common in practice.)

   <designator register='DB640' entry='Bc1' endDate='2012-12-31'/>
   <designator register='DB640' entry='Bc2' beginDate='2012-01-01'/>

Not allowed.

   <designator register='DB640' entry='Bc1'/>
   <designator register='DB640' entry='Bc2'/>

Not allowed.

Notes / Anmerkungen

(introduced with version 2.2)

Currently predefined 'register' enumeration entries:

• ENEE Station code of ENEE database managed (based on UIC/OSJD Leaflet/IRS 920-2) by UIC. See UIC's download page for more details.
• PLC Primary location code of the Telematics applications for freight (see "TAF TSI - Annex D.2 : Appendix C - Reference Files" [1]).
• IBNR Numbers used in some public timetable databases and some customer information systems (EFZ - Europäisches Fahrplanzentrum der DB; Frankfurt/Main). This enumeration entry requires the value to be an integer number.
• RL100 German "Betriebsstellenkürzel", Dienstvorschrift/Richtlinie No. 100 of Deutsche Bahn.
• DB640 Austrian "Dienstbehelf No. 640" of Österreichische Bundesbahnen.
• DIDOK Swiss "Dienststellendokumentation" of Schweizerische Bundesbahnen on behalf of Bundesamt für Verkehr.

Open issues / Offene Punkte/Pendenzen

Not yet described. / Noch nicht beschrieben.