Zunächst fällt die neue Version auf durch ihre neue Benutzeroberfläche, die die inzwischen recht umfangreichen Einstellmöglichkeiten thematisch gruppiert. Sie erlaubt ein Speichern der Export-Einstellungen für verschiedene Anwendungsfälle als benennbare Vorlagen entweder auf dem lokalen Rechner oder sogar auch in einer exportierten RailML-Datei. Hierdurch kann der nächste Export unter Bezug auf die vorherige erfolgreich ausgetauschte Datei mit gleichen Einstellungen erfolgen.

Die neue Schnittstelle bietet weiterhin eine Vielzahl neuer Einstellungsmöglichkeiten auch "rückwirkend" für bisherige RailML-Versionen. So kann z.B. die Rundungsregel gewählt werden, mit der Ankunfts-/Abfahrtszeiten in die RailML-Datei geschrieben werden. Dadurch können Rundungsfehler etwa gegenüber FBS-Ausdrucken vermieden werden.

Für den "1:1-Datenaustausch" von und nach FBS (Export von Fahrplandaten aus FBS, um sie in einem anderen FBS-Netz möglichst unverändert wieder importieren zu können) ist wichtig, dass Zeiten ungerundet übertragen werden können (volle interne Genauigkeit) und dass alle Zugteilläufe über RailML übertragen werden, um die FBS-Zugteilnummern zu erhalten. (Im Normalfall werden im Wesentlichen nur Direktverbindungen als Zugläufe über RailML übertragen, da dies für die meisten Anwendungsfälle wie Fahrgastinformation üblich und ausreichend ist.) Für den "1:1-Datenaustausch" gibt es damit nun eine spezielle Voreinstellung, er kommt z.B. zur Datenübergabe zwischen Aufgabenträger und Eisenbahnverkehrsunternehmen oder umgekehrt in Frage.

Da RailML-Dateien aufgrund ihrer internen Struktur oftmals sehr groß werden können, unterstützt die neue Schnittstelle nun auch "gepackte" (komprimierte) RailML-Dateien. Sie werden unmittelbar während des Exports ("on the fly") gepackt, sodass der Gesamtspeicherbedarf für einen umfangreichen Export deutlich sinkt und eventuelle Fehlermeldungen à la "nicht genug Speicher" der Vergangenheit angehören. Gepackte RailML-Dateien tragen die Dateiendung *.railmlx.

Mit railML®2.2 bietet die Schnittstelle auch den neuesten Stand der RailML-Schemen an. Version 2.2 ist die Weiterentwicklung der bisherigen Verionen 2.0 und 2.1: Sie füllt einige inhaltliche Lücken bei Infrastrukturdaten (z.B. Geschwindigkeitsprofile, Referenzierung von Betriebsstellen) und Fahrplandaten (Kopfmachen, Betriebshalte). Vor allem aber bestehen mit ihr mehr und flexiblere Möglichkeiten zum Export benutzerdefinierter Felder aus FBS: Benutzerdefinierte Felder werden insbesondere für Verwaltungsinformationen wie z.B. Vertragsnummern, Aufgabenträgern oder Bestellern verwendet, die gerade beim Datenaustausch zunehmende Bedeutung erlangen.

Bitte beachten Sie, dass sich die endgültige Implementierung von railML®2.2 an einigen Stellen von den zwischenzeitlich veröffentlichten Vorab-Versionen unterscheidet. Details und weitere Hinweise entnehmen Sie bitte folgenden aktualisierten Dokumenten:

• Bedienungsanleitung aktualisiert: Hinweise zur Benutzung (Export aus FBS) für Anwender der FBS-railML-2-Schnittstelle (PDF, 861 kByte)
• Schnittstellendokumentation aktualisiert: Schnittstellenbeschreibung der FBS-RailML-2-Schnittstelle, Export (PDF, 529 kByte)
• Änderungsübersicht (für Entwickler)

• eine railML®2.0-Version, die konform mit den Original-Schemen ist (ohne iRFP-Anpassungen) sowie eine ebenfalls railML®2.1-Version. Beide sind schemenbedingt eingeschränkt und daher nur aus Gründen der Vollständigkeit enthalten, jedoch ausdrücklich nicht zur Anwendung empfohlen.
• die bisherige Version 2.0 mit iRFP-Anpassungen (als 2.0.5 bezeichnet), d.h. nicht vollständig railML-konform. Diese Version vermeidet jedoch die Nachteile der originalen 2.0 und 2.1.
• mit railML®2.2 eine konforme und inhaltlich uneingeschränkte Version

Aus heutiger Sicht empfehlen wir Ihnen grundsätzlich die Anwendung von railML®2.2, es sei denn, eine frühere Version ist vorübergehend noch zur Abwärtskompatibilität notwendig.

Zur detaillierten Nennung der praktischen Einschränkungen s.a. Hinweise zu Verwendbarkeit und Einschränkungen der RailML-Versionen.

• neue Benutzeroberfläche, Fortschrittsanzeige während des Exports
• optional komprimierte RailML-Dateien (*.railmlx)
• Dateiendungen: *.xml für Dateien der Versionen 2.0 und 2.1; *.railmlx für komprimierte Dateien (unabhängig von deren Version, jedoch erst ab 2.2 standardisiert)
• Speichern der Einstellungen als benennbare Vorlagen in RailML-Datei oder lokal auf dem Rechner (Datei <AppData>\<Roaming>\NtzIntf_RailML2.xmlini).
• Zur leichteren Orientierung werden auch die Dateinamen und teilweise Pfade der FBS-Dateien des exportierten FBS-Netzes in die RAILML-Datei geschrieben. Die dazugehörigen Pfade werden nur exportiert, wenn es ein relativer Pfad (relativ zur Netzdatei oder mit Platzhalter beginnend) sind; absolute Pfade (beginnend mit Laufwerksbuchstaben oder Netz-Ressource) werden nicht ausgegeben.
• Vorrang von Umlauf-Zugteilen vor Filtereinstellungen: Wenn Umlauf-Zugteile durch Filter ausgeschlossen wurden, war der exportierte Umlauf nicht integer. Nunmehr wird ein Zugteil, der in einem zu exportierenden Umlaufplan vorkommt, auf jeden Fall exportiert - unabhängig von allen Filtern.
• Voreinstellung der Gülzigkeit von zu exportierenden Umlaufplänen geändert: Die Anzeige des Datums der Wochentage dient als Indiz zur Unterscheidung von Regel- und Sonderumlauf: Umlaufpläne für eine konkrete Woche, bei denen die Anzeige des Datums ausgeschaltet ist, werden als Regelumlauf per Voreinstellung ganzjährig exportiert.
• Rundungsregel einstellbar / Zeitgenauigkeit
• verkehrliche Züge optional und entwerder aus Direktverbinsungen oder allen Zugteilen
• Umlaufpläne optional mit oder ohne innere Wochentagsgruppe
• optional Verzicht auf Export von Bremseinstellungen, Zugbeeinflussungen und/oder Fahrzeitdifferenzen und Zuschläge zur Vereinfachung der Dateien
• Koordinaten nur noch mit EPSG ab railML 2.2
• Es werden nur effektiv wirksame Kilometrierungswechsel ausgegeben (alles andere ist in RailML nicht zulässig).
• optional Export benutzerdefinierter Felder aus FBS entweder in Standard-RailML-Felder (remarks, operator, debitcode oder <organizationalUnits>) oder in individuelle Felder (stark versionsabhängig)