iRFP Support English

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.

Higher railML versions 2.3 – 2.5 are usually possible, since largely compatible to railML 2.2. For assessment, please contact us when necessary while please providing information about the specific source and target software used for the data exchange.

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

  • 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
/ Profile

URL of the name space (xmlns)
URL des Schemas (xsi:schemaLocation)

Notes

all

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-own

extensions

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-own

adaptions

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

 

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 <passenger­Usage>.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

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
Version

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
when the attribute remarks changes within the route of a train part it is split into two train parts.

2.0.5

<train>.additionalTrainNumber added

2.1.0

<trackGroup>.<line>.uicNumber → code (summarized)
<trackGroup>.<line>.lineNumber → code (summarized)
<ocp>.abbreviation → code (renamed)
<ocp>.number is used for IBNR despite it being declarared as "deprecated", as otherwise no station numbers would be exportable.
<category>.abbreviation → code (renamed)
<ocpTT>.<sectionTT>.trackRef moved to <ocpTT>.<sectionTT>.<trackRef>.ref
<ocpTT>.<sectionTT>.<trackRef>.dir added
<ocpTT>.<sectionTT>.distance unit changed from km to m (combined with the increase of <metadata>.identifier from 1 to 2)
<train>.<trainPartSequence>.categoryRef (new) - for distinction between product (traffic oriented = <trainPart>.categoryRef) and train category (operational = <trainPartSequence>.categoryRef)
<circulation>.vehicleIdx dropped (without replacement, but see 2.2.0)
<circulation>.groupIdx dropped (without replacement, but see 2.2.0)

2.2.0

<metadata>.<dc:language> converted from codepage on BCP47-script
<metadata>.<organizationalUnits> (new)
<line>.code (content changed)
<line>.infrastructureManagerRef (new)
<mileageChange>.dir → absDir (renamed)
<speedChange>.profileRef (new)
<speedChange>.status (dropped)
<speedChange>.trainRelation, mandatoryStop, signalised (new)
<ownerChanges>.ownerName (dropped)
<ownerChanges>. infrastructureManagerRef (new)
<ocp>.code (dropped) → <ocp>.<designator> (new)
<ocp>.number (dropped) → <ocp>.<designator>.register=’IBNR’... (new)
<ocp>.<propOther>.<additionalName> --> <ocp>.<additionalName>... (shifted)
<ocp>.<propOther>.zip (new optional)
<ocp>.<geoCoord>.coord → altitude information moved to extraHeight
<ocp>.<geoCoord> <gradientChange>.<geoCoord>: coordinates and heights are only exported with indication of an EPSG-Code (EPSG-Code is now a mandatory field)
<train>.trainNumber (new at type='commercial')
<trainPart>.<formationTT>.orientationReversed (new)
<trainPart>.<formationTT>.load → timetableLoad (renamed)
<trainPart>.<ocpsTT>.<ocpTT>.sequence (new)
<trainPart>.<ocpsTT>.<ocpTT>.ocpType: the values begin and end are dropped
<trainPart>.<ocpsTT>.<ocpTT>.<stopDescription>.operationalStopOrdered (new)
<trainPart>.<organizationalUnitBinding> <-> user-defined fields out of FBS
<circulation>.vehicleCounter (reintroduced as succession of vehicleIdx)
<circulation>.vehicleGroupCounter (reintroduced as succession of groupIdx)

general 12/2014

all versions except 2.0.5:
no initial <mileageChange> element at the start of a track

general05/2015

all versions:
<metadata>.<dc:source> extended to source file names of FBS; also under <infrastructure> and <rollingstock> (not just under <railML>)
<geoCoord>.coord: altitude information moved from the third value in coord to extraHeight
<geoCoord>.epsgCode/heightEpsgCode added (optional until V2.1, obligatory from V2.2)
<speedChange>s are exported related to direction (dir='down', <metadata>.identifier=3)
<speedProfile>.influence at base (line speed) profiles always ='decreasing'
<train>.scope='secondary' dropped as possible value (at type='operational')
<train>.type='commercial': possible in two modes - optional with 1 on 1 train part allocation
<trainPart>.remarks, debitcode, operator <-> user-defined fields from FBS
<trainPart>.<ocpsTT>.<ocpTT>.<times>: selectable accurancy of the time specifications
<trainPart>.<ocpsTT>.<ocpTT>.<times>.scope='published' (new value possible)
<circulation>.fbs:blatt, fbs:zeile (new)

general 09/2015

all versions except 2.0.5:
order of the values altitude and longitude at coordinates swapped, after determination of the order by the railML consortia. To make this appearent for extern programmes, <metadata>.identifier was increased to =4.
Please contact iRFP, if you as user have compatibility problems caused by this retroactive change. (coordinates are read in the wrong way round).