iRFP Support

Technische Hinweise für Entwickler

  • Hintergrundinformationen zur Implementierung

Bitte beachten Sie, dass eine Nutzung des railML-Standards nicht automatisch bedeutet, dass zwei Programme mit Sicherheit fehlerfrei Daten austauschen können. Das liegt einerseits daran, dass der railML-Standard zwar die allgemeine Struktur von Infrastruktur- und Fahrzeugdaten definiert - jedoch sind zum Einen der Umfang der Daten (die Vollständigkeit) und zum Anderen die Details einiger spezieller Daten allein durch railML nicht zweifelsfrei definiert. Aus diesem Grund gibt es eine spezielle Schnittstellenbeschreibung für die FBS-Implementierung des railML-Formats. Hierin werden die konkret von FBS verwendeten Datenfelder und deren Inhalt beschrieben.

  • An Entwickler von RailML-Import-Schnittstellen, die (auch) RailML-Dateien aus FBS einlesen können sollen: Voreinstellung von Export-Optionen

Üblicherweise bestehen je nach Anwendungsfall individuelle Anforderungen an Inhalte von RailML-Dateien. Diese können i.d.R. beim Export vom Anwender eingestellt werden. Wegen der vielfältigen Optionen besteht die Möglichkeit, für bestimmte Anwendungsfälle (Programm-Paarungen wie z.B. "Export aus FBS zur Fahrgastinformation mit ...") konkrete Voreinstellungen fest zu hinterlegen, sodass inhaltliche Abhängigkeiten festgesetzt sind bzw. durch FBS bereits beim Export geprüft werden. Wenn Sie eine Import-Schnittstelle entwickeln, bitten wir Sie, mit uns Kontakt aufzunehmen zur Abstimmung der notwendigen Inhalte und eventuellen Voreinstellung der Optionen in FBS. Wir bitten Sie ebenfalls das nachfolgende Formular in Bezug auf die Voreinstellungen sinngemäß auszufüllen und an uns zu senden.

Formular Voreinstellungen für FBS-railML-Export (PDF)

  • Profil-Versionen der FBS-railML-Schnittstelle

Seit Mai 2012 kann außer dem Format railML 2.0 testweise auch das Format railML 2.1 aus FBS ausgegeben werden. Die Kompatibilität des FBS-Profils der Schemendateien zu den allgemeinen RailML-Schemen ist bei Version 2.1 etwas höher, dies ist jedoch mit inhaltlichen Einschränkungen gegenüber Version 2.0 verbunden (betrifft insbesondere Betriebsstellen-Nummern und eindeutige Bezeichnung von Strecken). Insgesamt empfehlen wir daher nicht die Verwendung von Version 2.1. Insbesondere ist die FBS-railML-2.1-Schnittstelle nicht für den Produktiveinsatz vorgesehen und kommerziell lizenziert.

Mit railML 2.2 wurden die noch bestehenden Beschränkungen aufgehoben, sodass wir hierin einen vollwertigen und vollständig kompatiblen Nachfolger von railML 2.0 sehen. Seit April 2012 befand sich die railML-Version 2.2 in einer Vorab-Implementierungsphase bei iRFP. Erste Test-Exporte von FBS-railML-2.2-Daten waren seit Mai 2012 möglich. Die Implementierung ist abgeschlossen, seit Anfang 2015 auch die Verifizierung durch das railML-Konsortium. Damit ist railML 2.2 nunmehr seitens iRFP veröffentlicht.        

Höhere railML-Versionen 2.3-2.5 sind in der Regel möglich, da weitgehend zu railML 2.2 kompatibel. Zur Einschätzung wenden Sie sich bei Bedarf bitte mit Verweis auf die konkret benötigte Quell- oder Zielsoftware des Datenaustauschs an uns.

Die Version 2.0 der FBS-railML Schnittstelle gibt es in zwei Ausprägungen (Profil-Versionen): Profil 2.0.0 mit allgemeinen railML-2.0-Schemen ist nur sehr eingeschränkt verwendbar. Die Profil-Version 2.0.5 basiert auf einer speziellen Adaption der allgemeinen railML-2.0-Schemendateien und ist weniger eingeschränkt, damit aber auch weniger kompatibel. Im Folgenden finden Sie eine Übersicht über die wesentlichen Unterschiede, weiter unten Hinweise zu Verwendbarkeit und Einschränkungen der RailML-Versionen.

  • Übersicht über die unterstützten Versionen

Folgende Versionen können derzeit aus FBS exportiert werden:

Version

Profil

Kompa­tibi­litäts­nummer

Bemerkungen

Revision

<railml>.

version

<metadata>.

format

<metadata>.

identifier

 

 

2.0

2.0.0

4

nur sehr eingeschränkt verwendbar (s.u.)

270

2.0

2.0.5

1

iRFP-eigene Anpassungen

(270)

2.1

2.1.0

4

unveränderte Original-Schemen

409

2.2

2.2.1

4

unveränderte Original-Schemen

602

  • Versionsverlauf der Kompatibilitätsnummer (<metadata>.identifier):

<metadata>. identifier

seit

fortgeschrieben wegen

2

23.05.2012

Wechsel der Einheit von <ocpTT>.<sectionTT>.distance von km auf m

3

06.05.2015

Orientierungswechsel auf dir='down' bei km-abwärtigen <speedChange>s

4

15.09.2015

Reihenfolgetausch von Längen- und Breitengrad in Koordinaten

Sollten Sie als Anwender Kompatibilitätsprobleme durch den Reihenfolgentausch der Koordinaten haben, bitten wir um Kontaktaufnahme mit dem iRFP-Büro Dresden.

  • Übersicht über die verwendeten Schemen und Namensräume:

Version
/ Profil

URI des Namensraums (xmlns)
URL des Schemas (xsi:schemaLocation)

Bemerkungen

alle

http://www.w3.org/2001/XMLSchema-instance (xmlns:xsi)
http://purl.org/dc/elements/1.1/ (xmlns:dc)

 

http://schema.fbsbahn.de/2.x/fbs_railml_extension (xmlns:fbs)
http://schema.fbsbahn.de/2.x/fbs_railml_extension.xsd

iRFP-eigene
Erweiterungen

2.0.0

http://www.railml.org/schemas/2009
http://www.railml.org/schemas/2009/railML-2.0/railML.xsd

 

2.0.5

http://schema.fbsbahn.de/2.0.5
http://schema.fbsbahn.de/2.0.5/fbs-railML.xsd

iRFP-eigene
Anpassungen

2.1.0

http://www.railml.org/schemas/2011
http://www.railml.org/schemas/2011/railML-2.1/railML.xsd

 

2.2.1

http://www.railml.org/schemas/2013
http://www.railml.org/schemas/2013/railML-2.2/railML.xsd

 

Darüber hinaus kann der Anwender beim Export eigene Schemen-Erweiterungen für benutzerdefinierte Felder aus FBS hinzufügen.

  • Hinweise zu Verwendbarkeit und Einschränkungen der RailML-Versionen

Version

Hinweise

2.0.0

     -   keine Geschwindigkeitsprofile-   Fahrwege der Züge nicht eindeutig nachvollziehbar, daher:
-   kein Re-Import der Daten aus Version 2.0.0 nach FBS möglich
-   Die Last von Zügen (mit Wagen) wird nicht explizit exportiert (Attribut <formationTT>.load fehlt). Sie wird jedoch indirekt über <formationTT>.weight exportiert, wo die Gesamtmasse eines Zugteils steht.
-   Bedarfszüge können nicht als solche gekennzeichnet werden, da das Attribut <operatingDay>.onRequest fehlt.
-   In RailML 2.0 wurde noch nicht zwischen Schnell- und Betriebsbremshundertsteln unterschieden. Es werden daher nur die Betriebsbremshundertstel exportiert. Da beide aber i. d. R. unterschiedlich sind, gehen hier wichtige Informationen verloren.
-   Es können Zugteile, die trotz vorhandener Sitzplätze nicht zur Fahrgastbeförderung freigeben sind (leerüberführte Wagen einschl. Triebwagen - DLt am Vollzug) nicht als solche gekennzeichnet werden, weil das Attribut <passenger­Usage>.places zwingend >0 sein muss. (<passengerUsage> wird daher bei abgesperrten Wagen weggelassen.)
-   Die verkehrliche Linienbezeichnung von Zugteilen wird nicht ausgegeben.
-   keine Wagenreihungsnummern
-   keine Umlaufpläne

2.0.5

-   von iRFP angepasste Schemendateien, um die Nachteile der Version 2.0.0 zu vermeiden

[2.0.5]

alle Versionen außer V2.0.5:
Es fehlt das erste <mileageChange>-Element am Anfang eines Streckengleises in der <mileageChanges>-Struktur. Es ist damit nicht möglich, die Kilometrierung einer Strecke im Zusammenhang zu erfassen. Die initiale absolute Position eines Gleises ist jedoch aus dem Element <trackBegin> ersichtlich.

2.1.0

-   <ocp>.number wird für IBNR verwendet entgegen der Deklaration als "deprecated", da ansonsten keine Betriebsstellennummern exportierbar wären
-   keine Fahrzeugindizes und Gruppennummern in Umlaufplänen

2.2.0

-   keine der o. g. Einschränkungen außer initialer <mileageChange>

2.2.1

-   wie 2.2.0, zusätzlich Unterstützung der hierarchischer Betriebsstellen über das Attribut <ocp>.parentOcpRef, um betrieblich unterschiedliche Betriebsstellen verkehrlich zusammenfassen zu können

alle, optional

mit iRFP-eigenen Erweiterungen: Die Erweiterungen ermöglichen
-   den Export benutzerdefinierter Felder aus FBS (z. B. mit Verwaltungsinformationen wie Besteller, Aufgabenträger, Vertragsnummer, durchführendes EVU) in flexiblerer Art als mit Standard-RailML-Feldern und auch an Stellen, an denen entsprechende Standard-RailML-Felder fehlen,
-   ein Wiedergeben "gefalteter" Umlaufplan-Darstellungen, d. h. mehrere "innere" Wochentage auf einem Blatt zusammengefasst.
  • Änderungsübersicht

Rot kennzeichnet entfallene Elemente oder Attribute,  blau kennzeichnet neu hinzugekommene, wobei betreffende Elemente/Attribute i.d.R. optional sind. Es handelt sich nur um eine Grobübersicht, Details entnehmen Sie bitte der Schnittstellenbeschreibung. Alle Änderungsangaben beziehen sich auf die jeweils vorgehende Version.

ab Profil-
Version

Änderung

2.0.0

nachträglich für RailML 2.0 gemäß unveränderten Original-Schemen

2.0.1

erste veröffentlichte Basis-Version

2.0.2

keine Änderungen in der Ausgabe ggü. V2.0.1

2.0.3

<trainPart>.remarks hinzugekommen
Bei Wechsel der Bemerkungen (Attribut remarks) innerhalb des Laufwegs eines Zugteils wird dieser in zwei Zugteile aufgeteilt.

2.0.5

<train>.additionalTrainNumber hinzugekommen

2.1.0

<trackGroup>.<line>.uicNumber --> code (zusammengefasst)
<trackGroup>.<line>.lineNumber --> code (zusammengefasst)
<ocp>.abbreviation --> code (umbenannt)
<ocp>.number wird für IBNR verwendet entgegen der Deklaration als "deprecated", da ansonsten keine Betriebsstellennummern exportierbar wären
<category>.abbreviation --> code (umbenannt)
<ocpTT>.<sectionTT>.trackRef zu <ocpTT>.<sectionTT>.<trackRef>.ref verschoben
<ocpTT>.<sectionTT>.<trackRef>.dir hinzugekommen
<ocpTT>.<sectionTT>.distance Einheit von km auf m geändert (verbunden mit der Erhöhung von <metadata>.identifier von 1 auf 2)
<train>.<trainPartSequence>.categoryRef (neu) - zur Unterscheidung Produkt (verkehrlich = <trainPart>.categoryRef) und Gattung (betrieblich = <trainPartSequence>.categoryRef)
<circulation>.vehicleIdx entfallen (ersatzlos, s. jedoch 2.2.0)
<circulation>.groupIdx entfallen (ersatzlos, s. jedoch 2.2.0)

2.2.0

<metadata>.<dc:language> umgestellt von Codepage auf BCP47-script
<metadata>.<organizationalUnits> (neu)
<line>.code (Inhalt geändert)
<line>.infrastructureManagerRef (neu)
<mileageChange>.dir --> absDir (umbenannt)
<speedChange>.profileRef (neu)
<speedChange>.status (entfallen)
<speedChange>.trainRelation, mandatoryStop, signalised (neu)
<ownerChanges>.ownerName (entfallen)
<ownerChanges>. infrastructureManagerRef (neu)
<ocp>.code (entfallen) --> <ocp>.<designator> (neu)
<ocp>.number (entfallen) --> <ocp>.<designator>.register=’IBNR’... (neu)
<ocp>.<propOther>.<additionalName> --> <ocp>.<additionalName>... (verschoben)
<ocp>.<propOther>.zip (neu optional)
<ocp>.<geoCoord>.coord --> Höhenangabe umgezogen zu extraHeight
<ocp>.<geoCoord> <gradientChange>.<geoCoord>: Koordinaten und Höhen werden nur noch mit Angabe eines EPSG-Codes exportiert (EPSG-Code ist Pflichtfeld geworden)
<train>.trainNumber (neu bei type='commercial')
<trainPart>.<formationTT>.orientationReversed (neu)
<trainPart>.<formationTT>.load --> timetableLoad (umbenannt)
<trainPart>.<ocpsTT>.<ocpTT>.sequence (neu)
<trainPart>.<ocpsTT>.<ocpTT>.ocpType: Entfall der Werte begin und end
<trainPart>.<ocpsTT>.<ocpTT>.<stopDescription>.operationalStopOrdered (neu)
<trainPart>.<organizationalUnitBinding> <-> benutzerdefinierte Felder aus FBS
<circulation>.vehicleCounter (wiedereingeführt als Nachfolge von vehicleIdx)
<circulation>.vehicleGroupCounter (wiedereingeführt als Nachfolge von groupIdx)

2.2.1

<ocp>.parentOcpRef (neu, optional)
<ocp>.code (wiedereingeführt, neu optional und mit abweichendem Inhalt)

allgemein 12/2014

alle Versionen außer 2.0.5:
kein initiales <mileageChange>-Element am Anfang eines Gleises

allgemein 05/2015

alle Versionen:
<metadata>.<dc:source> erweitert auf Quelldateinamen aus FBS; auch unter <infrastructure> und <rollingstock> (nicht nur unter <railML>)
<geoCoord>.coord: Höhenangabe vom dritten Wert in coord umgezogen zu extraHeight
<geoCoord>.epsgCode/heightEpsgCode hinzugefügt (optional bis V2.1, obligatorisch ab V2.2)
<speedChange>s werden fahrtrichtungsbezogen exportiert (dir='down', <metadata>.identifier=3)
<speedProfile>.influence bei Grundprofilen immer ='decreasing'
<train>.scope='secondary' als möglicher Wert entfallen (bei type='operational')
<train>.type='commercial': in zwei Modi möglich - optional mit 1:1-Zugteil-Zuordnung
<trainPart>.remarks, debitcode, operator <-> benutzerdefinierte Felder aus FBS
<trainPart>.<ocpsTT>.<ocpTT>.<times>: Genauigkeit der Zeitangaben wählbar
<trainPart>.<ocpsTT>.<ocpTT>.<times>.scope='published' (neuer Wert möglich)
<circulation>.fbs:blatt, fbs:zeile (neu)

allgemein 09/2015

alle Versionen außer 2.0.5:
Reihenfolgetausch von Längen- und Breitengrad bei Koordinaten nach Festlegung der Reihenfolge durch das railML-Konsortium. Um dies für externe Programme erkennbar zu machen, wurde <metadata>.identifier auf =4 erhöht.
Bitte kontaktieren Sie iRFP, wenn Sie als Anwender Kompatibilitätsprobleme durch diese nachträgliche Änderung haben (Koordinaten werden falsch herum eingelesen).

 

Downloads und Beispieldateien