First of all, the new version comes up with its new user interface, which thematically groups the now quite extensive settings. It allows saving the export settings for different applications as namable templates either on the local computer or even in an exported RailML file. This allows the next export to take place with reference to the previously successfully exchanged file with the same settings.

The new interface also offers a multitude of new setting options "retroactive" for previous RailML versions. Thus, e.g. the rounding rule can be selected, with the arrival / departure times written into the RailML file. This makes it possible to avoid rounding errors, for example, against FBS printing outputs.

For the "1: 1 data exchange" to and from FBS (export of lane data from FBS in order to be able to import it again in another FBS network as unchanged), it is important that times can be transmitted unrounded (full internal accuracy) and that all train part runs are transferred via RailML to obtain the FBS train part numbers. (In the normal case, only direct connections are transmitted as train runs via RailML, as this is customary and sufficient for most applications such as passenger information.) For the "1: 1 data exchange", there is now a special presetting; it is only a case e.g. for the transfer of data between the authority and railway operating company or vice versa.

Since RailML files can often become very large due to their internal structure, the new interface now supports "packed" (compressed) RailML files. They are packed directly during the export ("on the fly"), so that the total storage requirement for a large export decreases significantly and possible error notifications à la "not enough memory" belong to the past. Packed RailML files have the file extension * .railmlx.

With railML®2.2, the interface also offers the latest state of the RailML schemes. Version 2.2 is the further development of the previous verions 2.0 and 2.1: it fills some gaps in the content of infrastructure data (for example speed profiles, referencing of operating stations) and timetable data (turnings, operating stops). Above all, it provides more and more flexible ways to export customer-defined fields from FBS: Customer-defined fields are used, in particular, for administration information, such as contract numbers, regional authorities or orderers which are gaining in importance during data exchange.

Please note that the final implementation of railML®2.2 differs from the pre-release versions published in the meantime. For details and further information, please refer to the following updated documents:

• Updated manual: Hints for usage (export out of FBS) for users of the FBS-railML-2-interface (German PDF, 861 kByte)
• Updated interface documentation: interface documentation of the FBS-RailML-2-interface, export (German PDF, 529 kByte)

• A railML®2.0 version, which is compliant with the original schemes (without iRFP adaptations) and a railML®2.1 version as well. Both are limited by the scheme and are therefore only for completeness, but are not expressly recommended for use.
• The previous version 2.0 with iRFP adjustments (referred to as 2.0.5), that means not completely railML-compliant. This version avoids the disadvantages of the original 2.0 and 2.1.
• With railML®2.2 a compliant and unrestricted version

From today's point of view, we strongly recommend using railML®2.2, unless an earlier version is temporarily necessary for downward compatibility.

• New user interface, progress display during export
• Optionally compressed RailML files (* .railmlx)
• File extensions: * .xml for versions 2.0 and 2.1; * .railmlx for compressed files (independent of their version, but only standardized from 2.2)
• Save the settings as a namable template in RailML file or locally on the computer (file < AppData > \ < Roaming > \ NtzIntf_RailML2.xmlini).
• For easier orientation, the filenames and partial paths of the FBS files of the exported FBS network are written to the RAILML file. The associated paths are exported only if they are a relative path (relative to the net file or starting with placeholders); Absolute paths (starting with drive letters or network resource) are not output.
• Priority of circulation train parts before filter settings: If circulation train parts were excluded by filters, the exported circulation was not integer. Now, a train part, which occurs in a circulation plan to be exported, is exported in any case - independent of all filters.
• Presetting the validity of the circulation plans to be exported changed: The display of the date of the weekday is used as an index to distinguish between the regular and the special circulation: Circulation plans for a specific week with which the display of the date is switched off are exported as a regular circulation by default.
• Rounding rule adjustable / time accuracy
• Traffic trains are optional and either from direct connections or all trains
• Circulation plans available with or without internal weekday group
• Optional waiver of export of brake settings, train influencing and / or travel time differences and surcharges to simplify the files
• Coordinates only with EPSG from railML 2.2
• Only effectively effective kilometer changes are output (everything else is not allowed in RailML).
• Optionally export customer-defined fields from FBS either into standard RailML fields (remarks, operator, debitcode or < organizationalUnits >) or into individual fields (strongly dependent on the version)