IS:designator ocp

From railML 2 Wiki
Jump to navigation Jump to search


key
 


Scheme description / Schemenbeschreibung

Position of key in the XML-Tree / Position von key 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 <key> 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 key / Attribute von key

  • 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.
  • value: Contains the external primary key of the OCP belonging to the referred register.

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

Best practice & Examples / Empfohlene Anwendung & Beispiele

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

<ocp ... name='Fieberbrunn' ...>
    <designator register='ENEE' entry='81-01155-1'/>
    <designator register='IBNR' entry='8100053'/>
    <designator register='DB640_2011' entry='Fie'/>
    <designator register='DB640_2012' entry='Hch H2'/>
    <designator register='DS100' entry='XAFB'/>
</ocp>

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

Notes / Anmerkungen

(introduced with version 2.2)
THIS IS A PRE-ANNOUNCEMENT FOR A NEW ELEMENT AND NOT YET RELEASED. CONTENTS MAY CHANGE UNTIL FINAL RELEASE OF RAILML 2.2.
Please check the discussion in the railML-Forum and the ticket.

Currently predefined 'register' enumeration entries:

  • ENEE Station code of ENEE database managed by UIC.
  • 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.
  • DS100 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.

Since the values change over the years, each one of the 'register' enumeration entries can be used with _xxxx (underline and a four-digit year number) to specify the year of the key values if necessary.

Open issues / Offene Punkte/Pendenzen

Not yet described. / Noch nicht beschrieben.