Eine Betriebsstelle kann in railML mit verschiedenen Kürzeln ("Registern") versehen werden. Dies erfolgt (seit railML 2.2) in den Attributen register und entry des Elements <designator> einer railML-Betriebsstelle (<ocp>):

      <ocp id='ocp_DN'>
        <designator register='RL100' entry='DN'/>
        <designator register='IBNR' entry='8010089'/>
      </ocp>

Typische Register sind RL100 (für innerdeutsche Betriebsstellen), IBNR (Internationale Bahnhofsnummern), PLC (Primary Location Code für TAF/TAP TSI) oder CRD (Common Reference Database, ERA)¹.

Dabei hat jedes dieser Register eine andere Definition von "Betriebsstelle" im Detail - in einem Register sind Betriebsstellen "filigraner" zugeschnitten, im anderen "grober". Hieraus folgt, dass keine 1:1-Zuordnung möglich ist. Ebenso ist die FBS-interne Vorstellung von "Betriebsstelle" nicht immer 1:1 einem der Register zuordenbar - auch wenn hier FBS-seitig eine gewisse Flexibilität besteht -, so dass sogar dann Registereinträge doppelt vorkommen können, wenn nur ein Register verwendet wird.

Beispielsweise ist Berlin Hauptbahnhof - Lehrter Bahnhof die IBNR 8098160 zugewiesen, während die DB Netz AG diesen in die drei Betriebsstellen BL, BLS und BHBF unterteilt, da es sich tatsächlich um drei betrieblich unabhängige Gleisgruppen handelt. Wenn in einer railML-Datei also die drei Betriebsstellen BL, BLS und BHBF unterschieden werden, müssen alle drei die gleiche IBNR referenzieren. Würde umgekehrt nur eine Betriebsstelle mit der IBNR 8098160 angegeben, müsste diese die drei RL100-Kürzel aufführen.

Hier handelt es sich also um die recht häufige Unterteilung nach "betrieblicher vs. verkehrlicher Sichtweise". Das muss nicht zwangsläufig so sein; auch innerhalb der betrieblichen oder verkehrlichen Sicht können verschiedene Register im Detail zu unterschiedlichen Ergebnissen kommen. So hat etwa die einem Bahnhof verkehrlich zugewiesene Bushaltestelle nicht immer die gleiche IBNR wie der Bahnhof.

Auch der quasi umgekehrte Fall kann vorkommen: So gibt es im z. B. Bereich der DB Netz AG oft "parallele Haltepunkte", also Haltepunkte an unterschidlichen Strecken, die die gleiche verkehrliche Funktion (Erschließung) erfüllen. Diese müssten genau genommen unterschiedliche Betriebsstellen sein - als Haltepunkte haben sie ja zwangsläufig keine innere betriebliche Verbindung. Dennoch sind sie unter einem betrieblichen Kürzel zusammengefasst. Beispiele sind etwa Kürbitz (zwei Haltepunkte mit gleichem Namen und dem gleichen RL100-Kürzel DKUR an zwei unterschiedlichen Strecken) oder Hervest-Dorsten (RL100-Kürzel EHDT). Dass das nicht immer so ist, zeigt das Beispiel Regensburg-Prüfening: Auch hier geht es "gefühlt" (verkehrlich) um ein und dieselbe Zugangsstelle an zwei unterschiedlichen Strecken, jedoch gibt es hier je nach Strecke die RL100-Kürzel NRPF und NRPH².

Unter dieses Thema fallen natürlich auch Betriebsstellen, die in einem Register gar nicht enthalten sind. So gibt es etwa IBNR i. d. R. nur für Zugangsstellen des Reiseverkehrs, während Betriebsbahnhöfe oder reine Güterverkehrs-Zugangsstellen ohne auskommen müssen und demzufolge auch in railML keine solch Angabe haben können. Auch das wiederholte Vorkommen von "kein Kürzel" stellt datentechnisch eine Primärschlüssel-Verletzung dar, die beim Einlesen von railML-Dateien beachtet und ggf. abgefangen werden muss.

Fazit: Externe Schlüsselangaben in railML wie die Register von Betriebsstellen können zwangsläufig nicht datentechnische Primärschlüssel-Anforderungen erfüllen. Die einlesende Software muss ggf. Duplikate oder fehlende Angaben geeignet verarbeiten können.

Beim Export aus FBS bestehen zudem eine Reihe von optionalen Prüfmöglichkeiten, die etwa das Fehlen von Kürzeln feststellen und warnen können. Dies erlaubt zumindest eine "Fehler-Früherkennung" und Ärger beim späteren Import, etwa wenn einmal eine IBNR vergessen wurde einzugeben.

¹ railML-Schemen Version 2.30r611, www.railml.org, abgerufen am 01.05.2014
² Schienennetz-Nutzungsbedingungen der DB Netz AG, abgerufen am 25.05.2017