Homogenität der “id” innerhalb der GTFS-Dienste

GTFS geht davon aus, dass die “id” innerhalb der verschiedenen Dienste GTFS Static, GTFS-RT und GTFS-SA konsistent sind. Bei der Erstellung von GTFS-SA sind wir etwas vorgeprellt:

  • stopId ist die SLOID der Haltestelle bzw. des Gleises
  • tripId ist die SJYID (also die neue offizielle ID der Fahrt)

Leider entspricht das nicht dem, was in GTFS Static drin ist:

  • Die stop_id ist eine künstlich generierte id, da wir so die Plattformen (z.B. 41/42) und die Sektorgruppen/Sektoren (z.B. 12A-D, 12A) abbilden können, wenn sie im Fahrplan so auftauchen.
  • Die trip_id ist ebenfalls künstlich erstellt und abhängig von Linien und Linienvarianten.

Wir können auch nicht einfach die SLOID und SJYID verwenden, da GTFS als Format Uniqueness verlangt und die im Moment nicht gegeben ist:

  • Eine SLOID kann sowohl für die Plattform, als auch das Gleis, als auch die Sektorgruppe verwendet werden (z.B. ch:1:sloid:7000:0:41 würde auch für 41/42, 41A, 41E-H gelten). Das würde zu mehreren Zeilen mit derselben SLOID führen.
  • Eine SJYID ist nur zusammen mit dem Betriebstag eindeutig. In GTFS muss sie global eindeutig sein.

Lösungsansätze

  • In trips.txt ist die SJYID bereits zusätzlich in einer neuen Spalte “original_trip_id” eingefügt. Damit können die GTFS SA zumindest indirekt gemappt werden.
  • In stops.txt sind wir dabei, die SLOID ebenso in einer zusätzlichen Spalte hinzuzufügen (“original_stop_id”). Für Steige (Haltekanten) wird die SLOID hinzugefügt, sofern diese vorhanden ist. Wenn sie nicht vorhanden ist, bleibt das Feld leer. Für Haltestellen wird die SLOID hinzugefügt, für ausländische Haltestellen manchmal UIC-Nummern.
  • In GTFS-SA sind wir dabei, die “informed_entity” zu erweitern, so dass alle betroffenen stopId übermittelt werden (Service Alerts – General Transit Feed Specification).

Links

#AutoTranslate