61050: In my railML file the same train number occurs several times? How are trains clearly identified in railML?

There is, of course, no uniform identification for trains in railML. Rather, it is dependent on application, local practices and the programs involved, how trains are identified. RaiLML, on the other hand, is a general exchange format that allows several possibilities.

The most common attribute for identifying a (operating) train (railML: < train > with @ type = operational) is the train number (railML: @trainNumber). Usually, however, this is not sufficient to clearly identify a train - for example, the same train number can describe different train paths or trains on different transport days.

In the case of several routes with the same train number on disjoint traffic days, the attribute additionalTrainNumber is available in railML for the purpose of differentiation. In this case, there are several < trains > with @ type = operational, with the same @trainNumber and @ scope = primary, which differ only by @additionalTrainNumber (see example 1).

In some countries there is the phenomenon of "secondary runways": On different (disjunctive)operation days, the same operational train takes different itineraries or times. This results in other values of the @scope attribute:

  • secondaryInner = between-beside run = "double timetable"
  • secondaryStart = before-beside run = "start train part"
  • secondaryEnd = after-beside run = "end train part"

(siehe Beispiel 2).

However, this is always avoidable by "reformulating" to several main runs (scope = primary as mentioned above).

Despite all this, it may happen that FBS is exporting data that violates the "target policy" and contains the same train number on the same day. This can be quite intentional, for example, when a train leaves the imaging area of the user, continues to "foreign" infrastructure, and then returns to the imaging area of the user. An example would be an Austrian train that runs between Salzburg and Kufstein via Rosenheim. It could actually be included in (Austrian) railML data twice on the same traffic day, namely once to Salzburg and once from Kufstein. It would be the same if a train was interrupted once on a partial route by rail replacement (see example 3).

In any case, the FBS-RailML interface can recognize and prevent duplicate train numbers - per traffic day or in general - by means of optional checking options during export. It is useful to adjust the specific possibilities and restrictions before the data exchange between the participating software manufacturer, the user and the iRFP, which is of course readily available.

More information about this topic can be find here on page 21- 24 (German PDF).

Last update on 21.01.2020 by iRFP Support.

Go back