Technical Details for Developers
-
Background information about the implementation
Please note that the railML standard does not automatically mean that two programmes can always exchange data without errors. This is due to the fact that the railML standard does define the general structure of infrastructure and vehicle data - however, on the one hand, the scope of the data (the completeness) and on the other hand, the details of some special data are not defined beyond doubt by railML. For this reason, there is a special interface description for the FBS implementation of the railML format. The data fields used by FBS and their contents are described there.
-
To developers of railML import interfaces that are (also) supposed to read railML files from FBS: template settings of export options
Usually there are individual requirements for the content of railML files depending on the use case. These can usually be set by the user when exporting. Due to the diverse options, there is the possibility to save certain templates for particular user cases (programme parings like “Export from FBS to the passenger information system with …”), so that dependencies in terms of content are fixed or rather checked by FBS during the export. Should you develop an import interface, we kindly ask you to contact us in order to harmonise the needed content und potential template options in FBS. We also ask you to fill out the following form (unfortunately in German) concerning template settings and send it to us.
Form templates for FBS railML export (PDF)
-
Profile versions of the FBS railML interface
Since May 2012, it has been possible for testing purposes to export the railML 2.1 format from FBS in addition to the railML 2.0 format. The compatibility of FBS’ scheme file profile to the general railML schemes is ab bit higher in version 2.1 however, this comes with restrictions in terms of content in comparison to version 2.0 (especially in terms of station numbers and distinct naming of lines). For those reasons we generally do not recommend the usage of version 2.1. The FBS railML 2.1 interface in particular is not designed for a productive use and thus not licensed commercially.
With railML 2.2 the still existing restrictions have been lifted, so that we acknowledge it as a fully fledged and completely compatible follow up of railML 2.0. The railML version 2.2 has been in a pre-implementation phase at iRFP since April 2012. First test exports of FBS-railML 2.2 data have been possible since May 2012. The implementation has been concluded, and since the beginning of 2015 so has the verification by the railML association. So, from now on railML2.2 is published by iRFP.
In September 2024, the necessary adaptations to support railML 2.5 were completed so that data can now also be output from FBS in this format.
The version 2.0 of the FBS railML exists in two variants (profile versions): profile 2.0.0 with general railML 2.0 schemes is only usable with severe restrictions. Profile version 2.0.5 is based on a special adaption of the common railML 2.0 scheme files and is less restricted at the cost of being less compatible. The following list is a summary of the essential differences between the railML versions further down are details about usability and restrictions of them.
-
Overview of supported versions
The following versions can be exported from FBS as of right now:
|
Version <railml>. version |
Profile <metadata>. format |
Compatibility number <metadata>. identifier |
Notes
|
Revision
|
|
2.0 |
2.0.0 |
4 |
usability very limited (see below) |
270 |
|
2.0 |
2.0.5 |
1 |
iRFP-own adaptions |
(270) |
|
2.1 |
2.1.0 |
4 |
unchanged original schemes |
409 |
|
2.2 |
2.2.1 |
4 |
unchanged original schemes |
602 |
|
2.5 |
2.5.2 |
4 |
unchanged original schemes |
1372 |
-
Version history of the compatibility number (<metadata>.identifier):
|
<metadata>. identifier |
since |
perpetuated because of |
|
2 |
23.05.2012 |
Change of the unit of <ocpTT>.<sectionTT>.distance from km to m |
|
3 |
06.05.2015 |
Change of orientation of dir='down' at km-down <speedChange> |
|
4 |
15.09.2015 |
Order of latitude and longitude have been swapped in coordinates |
Should you as a user have compatibility problems due to the swapped order of the coordinates, please contact us.
-
Overview of the used schemes and name spaces:
|
Version |
URL of the name space (xmlns) |
Notes |
|
all |
http://www.w3.org/2001/XMLSchema-instance (xmlns:xsi) |
|
|
http://schema.fbsbahn.de/2.x/fbs_railml_extension (xmlns:fbs) |
iRFP-own extensions |
|
|
2.0.0 |
http://www.railml.org/schemas/2009 |
|
|
2.0.5 |
http://schema.fbsbahn.de/2.0.5 |
iRFP-own adaptions |
|
2.1.0 |
http://www.railml.org/schemas/2011 |
|
|
2.2.1 |
http://www.railml.org/schemas/2013 |
|
|
2.5.2 |
https://www.railml.org/schemas/2021 |
|
Additionally the user can add own scheme extensions for user defined fields from FBS when exporting.
-
Hints about usabilty and limits of the railML versions
|
Version |
Comments |
|
2.0.0 |
- no line speed profiles - routes of the trains not distinctly documented, thus: - no re-import of the data from version 2.0.0 to FBS possible - trainloads (with carriages) are not exported explicitly (attribute <formationTT>.load is missing) but they are exported indirectly to <formationTT>.weight, which saves the total mass of a train part - trains on request cannot be labelled as such, because the attribute <operatingDay>.onRequest is missing - railML 2.0 didn’t differentiate between emergency and service braking percentage, so only the operational braking percentage is exported. But since both values are usually different, important data is lost here. - train parts, which are not enabled for passenger transportation in spite of available seats (e. g., wagons including multiple units transferred empty) cannot be labelled as such, because the attribute <passengerUsage>.places must be >0. (That's why <passengerUsage> is not used for closed wagons.) - commercial line descriptions of train parts are not output - no wagon order numbers - no circulation plans |
|
2.0.5 |
- scheme files adapted by iRFP, to avoid the disadvantages of the version 2.0.0 |
|
[2.0.5] |
all versions except V2.0.5: The first <mileageChange> element at the beginning of a track is missing in the <mileageChanges> structure. Hence it is not possible, to determine the mileage of a line from context. But the initial absolute position of a track is evident from the element <trackBegin>. |
|
2.1.0 |
- <ocp>.number is used for IBNR despite its declaration as "deprecated", as otherwise station numbers wouldn’t be exportable - no vehicle indices and group numbers in circulation plans |
|
2.2.0 |
- none of the limitations mentioned above except initial <mileageChange> |
|
2.2.1 |
- like 2.2.0,additionally support of hierarchical stations using the attribute <ocp>.parentOcpRef, to merge several operational stations into one “traffic” station |
|
2.5.2 |
- no new limitations - Minor functional extensions, e.g. with regard to station track exceptions depending on traffic days and far distance routes. - Some special sub-elements of operating points (<ocp>) are only exported in exceptional cases (special predefined default settings). |
|
alle, optional |
with iRFP-own adaptions that allow: - export user-defined fields from FBS (e.g., with administration information like transportation authority, contract number, executing TOC) in a more flexible way than with standard railML fields and also at points, where appropriate standard railML fields are missing - to render the "folded" circulation plan view i.e., several "inner" weekdays summarized on one sheet |
- Changelog
Red indicates dropped elements or attributes, blue indicates newly added ones, whereby the elements/attributes in question are generally optional. This is only a rough overview, details can be seen in the interface description (German). All change information refers to the previous version.
|
Since Profile |
Change |
|
2.0.0 |
retroactively for railML 2.0 corresponding to unchanged original schemes |
|
2.0.1 |
first published base version |
|
2.0.2 |
no changes compared to V2.0.1 |
|
2.0.3 |
<trainPart>.remarks added |
|
2.0.5 |
<train>.additionalTrainNumber added |
|
2.1.0 |
<trackGroup>.<line>.uicNumber → code (summarized) |
|
2.2.0 |
<metadata>.<dc:language> converted from codepage on BCP47-script |
|
general 12/2014 |
all versions except 2.0.5: |
|
general |
all versions: |
|
general 09/2015 |
all versions except 2.0.5: |
|
2.5.2 |
Main element <infrastructure>: - The attribute <ocp>.<propOther>.status has moved to <ocp>.<propOther>.<states>.<state...>. Main element <timetable>: |