Homogeneity of the ‘id’ within the GTFS services

GTFS assumes that the ‘id’ is consistent across the different GTFS Static, GTFS-RT and GTFS-SA services. When we created GTFS-SA, we jumped a bit:

  • stopId is the SLOID of the stop or track
  • tripId is the SJYID (i.e. the new official ID of the trip)

Unfortunately, this does not correspond to what is in GTFS Static:

  • The stop_id is an artificially generated ID because it allows us to map the platforms (e.g. 41/42) and the sector groups (e.g. 12A-D, 12A) if they appear as such in the timetable.
  • The trip_id is also created artificially and depends on lines and line variants.

We can’t just use the SLOID and SJYID either, because GTFS requires uniformity as a format, which is not available at the moment:

  • A SLOID can be used for both the platform and the track as well as the sector group (e.g. ch:1:sloid:7000:0:41 would also apply to 41/42, 41A, 41E-H). This would result in multiple lines with the same SLOID.
  • A SJYID is unique only together with the operating day. In GTFS, it must be unique globally.

Possible solutions

  • In trips.txt, the SJYID has already been added in a new column ‘original_trip_id’. This allows GTFS SA to be mapped, at least indirectly.
  • In stops.txt, we are also adding the SLOID in an additional column (‘original_stop_id’). For platforms (stopping edges), the SLOID is added if it is available. If it is not available, the field remains blank. The SLOID is added for stops, and sometimes UIC numbers for foreign stops.
  • In GTFS-SA, we are in the process of expanding the ‘informed_entity’ so that all affected stopId are transmitted (Service Alerts – General Transit Feed Specification).

Links

#AutoTranslate