Zum Inhalt springen

Fahrpläne GTFS

Wie setzt sich die Trip ID zusammen?

Die Trip ID setzt sich aus unterschiedlichen DIVA-Nummern/Feldern zusammen und hat nichts mit den HRDF-Daten zu tun.

Die Zuordnung ist nicht ganz 1:1, da die Fahrt ID (= Fahrtnummer) nicht unique sein muss innerhalb eines HRDF-Datensatzes, aber unter Zuhilfenahme von Haltestellen und Haltezeiten, wie der Datennutzer das gemacht hat, lässt sich die passende Fahrt wie folgt finden:

In der trips.txt steht der trip_short_name:

route_id,service_id,trip_id,trip_headsign,trip_short_name,direction_id

„26-94-j18-1″,“TA+b20xg“,“310.TA.26-94-j18-1.3.R“,“Zürich Oerlikon, Bahnhof“,“13628„,“1“

 

Dieser entspricht der Fahrtnummer (externe Zugnummer) in der *Z-Zeile der FPLAN-Datei:

unbenannt

Da die Fahrtnummer wie erwähnt nicht unique sein muss innerhalb eines HRDF-Feeds, sollte man zusätzlich die Haltezeiten und stop_ids der Fahrt aus der stop_times.txt zur Zuordnung mit heranziehen:

 

trip_id,arrival_time,departure_time,stop_id,stop_sequence,pickup_type,drop_off_type

„310.TA.26-94-j18-1.3.R“,“13:37:00″,“13:37:00″,“8587651″,“1″,“0″,“0″

„310.TA.26-94-j18-1.3.R“,“13:38:00″,“13:38:00″,“8587652″,“2″,“0″,“0″

„310.TA.26-94-j18-1.3.R“,“13:39:00″,“13:39:00″,“8591263″,“3″,“0″,“0″

„310.TA.26-94-j18-1.3.R“,“13:41:00″,“13:41:00″,“8591347″,“4″,“0″,“0″

„310.TA.26-94-j18-1.3.R“,“13:42:00″,“13:42:00″,“8591047″,“5″,“0″,“0″

„310.TA.26-94-j18-1.3.R“,“13:43:00″,“13:43:00″,“8591113″,“6″,“0″,“0″

„310.TA.26-94-j18-1.3.R“,“13:44:00″,“13:44:00″,“8591330″,“7″,“0″,“0″

„310.TA.26-94-j18-1.3.R“,“13:45:00″,“13:45:00″,“8591319″,“8″,“0″,“0″

„310.TA.26-94-j18-1.3.R“,“13:46:00″,“13:46:00″,“8591175″,“9″,“0″,“0″

„310.TA.26-94-j18-1.3.R“,“13:46:00″,“13:46:00″,“8591273″,“10″,“0″,“0″

„310.TA.26-94-j18-1.3.R“,“13:48:00″,“13:48:00″,“8591382″,“11″,“0″,“0″

„310.TA.26-94-j18-1.3.R“,“13:49:00″,„13:49:00″,“8580449“,“12″,“0″,“0″

 Es passt immer der zwei Tage jüngere HRDF-Feed (z. B. 05.02.2018) zum GTFS-Feed (z. B. 07.02.2018):

unbenannt

Welche Infos liefert GTFS?

Die drei Arten der Zusatzinformation sind:

  • Trip Updates
  • Service Alerts
  • Vehicle Positions

Trip Updates

Bsp: „Bus 18 hat aktuell 10 Minuten Verspätung“

Hier werden Verspätungen, geänderte Routen, Ersatzfahrzeuge oder Ausfälle für einzelne Linien laufend publiziert, um den Fahrgästen eine möglichst exakte Planung zu ermöglichen.

Service Alerts

Bsp: „Station Bern Weissenbühl ist aufgrund eines Unfalls aktuell geschlossen“

Im Falle von Verschiebung der Haltekante oder allgemein unvorhergesehene Ereignissen, die eine Haltestelle, eine Route oder das gesamte Netzwerk beeinflussen, können kurze Meldungen publiziert werden um die Fahrgäste auf dem Laufenden zu halten und zu erklären, was der Grund für die Änderung ist.

Service Alerts stehen auf der Plattform nicht zur Verfügung.

Vehicle Positions

Bsp: „Dieser Bus befindet sich um 18h23 an der Haltestelle Bern Bahnhof“

Hier können Informationen zum Standort von einzelnen Transit-Fahrzeugen publiziert werden. Zusätzlich können auch die aktuelle Auslastung des Fahrzeugs, der Fahrzeugtyp oder andere, ähnliche Informationen bereitgestellt werden.

Die Vehicle Positions stehen auf der Plattform nicht zur Verfügung.

Wie ist der grenzüberschreitende Verkehr abgedeckt?

Die TFS Daten basieren auf den HRDF Daten. Die HRDF-Datei beinhaltet nur den öV-Schweiz. Internationale Züge werden (meist) am ersten kommerziellen Halt im Ausland terminiert. In Wirklichkeit fahren sie natürlich weiter. In einigen Fällen endet die internationale Fahrt bei der letzten Haltestelle in der Schweiz (z.B. Genf) oder enthält noch 1-2 Haltestellen /Betriebspunkte im Ausland.

Die öV-Schweiz-Datei beinhaltet zusätzlich das Streckennetz der SBB GmbH in Deutschland. Dies hat letztendlich historische Gründe.

 

Ist ein Mapping zwischen Route-IDs in GTFS und HRDF möglich?

Im HRDF bilden die folgenden Felder einer Fahrt einen eindeutigen Schlüssel:

•„Fahrtnummer“

•„Verwaltung“

•„Variante“

 Diese findet sich in der „*Z-Zeile“ der Datei „FPLAN“.

Im GTFS (und GTFS-RT) ist dies die „Trip_ID“ in der Datei „trips.txt“. Die Routen (in „routes.txt“) und trips werden automatisch nummeriert. D.h. sie sind auch zwischen GTFS-Versionen nicht stabil.

Wenn der eigentliche Fahrplan aus HRDF stammen soll und ihre Algorithmen darauf ausgelegt sind, so müssen sie dennoch das GTFS Static in ihre Datenbank importieren und ein Matching erzeugen.

Wie du dazu am besten vorgehst entnimmst du dieser Cookbook Seite:

https://opentransportdata.swiss/de/cookbook/verwendung-von-hrdf-fahrplaenen-zusammen-mit-gtfs-rt/

 

 

Könnte es sein, dass auf den Linien, bei welchen die Datenqualität schlecht ist, immer ein gtfsrt entity mit delay=0 geliefert wird, anstatt dass erst gar kein gtfsrt entity geliefert wird?

Nein, das ist nicht der Fall. Entweder eine Fahrt Echtzeit und es werden auch alle Verspätungen ausgegeben oder Sie hat keine Echtzeit. Delay 0 bedeutet Echtzeit und pünktlich. Entweder haben wir keine Verspätung in VDV 454 AUS erhalten, oder wir konnten die Meldung mit der Prognose nicht verarbeiten.

 

Was bedeuten die ersten und letzten beiden Abschnitte der trip_id? Z. B. {405}.TA.26-752-j17-1.{3}.{R}

Die trip_id besteht aus den folgenden Teilen: „<fortlaufende Nummer in der trips.txt>.<service_id>.<route_id>.<DIVA Fahrwegsnummer>.<DIVA Fahrtrichtung>“

route_id = <DIVA Betriebszweig>-<DIVA Liniennummer>-<DIVA Projektkurzbezeichnung>-<DIVA Linienversionsnummer>

Was bedeutet eine Echtzeitmeldung ohne „stop_time_updates“?

Echtzeitmeldungen ohne „stop_time_updates“ sind Auslösungen ohne Echtzeit. Diesbezüglich wurden Änderungen vorgenommen sodass Fahrten ohne Echtzeit nicht mehr übertragen werden.

Für welche Leistungen gibt es Echtzeit – und wie viele Fahrten sind das?

Wie viele: Aktuell immer so viele wie Sie in der GTFSR-Antwort erhalten.
Folgende Transportunternehmen liefern Echtzeitdaten: https://opentransportdata.swiss/de/dataset/go-realtime

Das Trip-Update für trip_id = „94.TA.42-2-Y-j17-1.55.H“ liefert ein Stop-Update für stop_id =“8507483:0:3″ mit der Sequenz „4“, aber dieser Trip in GTFS auf Sequenz „4“ hat die stop_id =“8507483:0:4″.

Das ist richtig. Dies ist die Art und Weise, wie Trackänderungen in GTFSR angezeigt werden. Wir haben dies mit dem letzten Release implementiert. GTFS 8507483: 0: 4 und GTFSR 8507483: 0: 3 „bedeutet, dass der geplante Track 4 ist, aber der aktuelle Track aufgrund von Änderungen nun 3 ist. Wir empfehle Ihnen, nur auf der Ebene der Haltestellen zu kartographieren.