GTFS Realtime (GTFS RT) ist eine Erweiterung zu GTFS Static und reichert die statischen Transit-Informationen mit Echtzeitinformationen an. Die GTFS-Realtime-Daten sind auf die GTFS-static-Daten abgestimmt. Der Realtime-Feed umfasst alle bekannten Änderungen im öV Schweiz im gesamten Vorschaufenster (drei Stunden) für alle Verkehrsunternehmen, die Echtzeitdaten liefern.
Fachliche Beschreibung
GTFS RT erlaubt die Anreicherung der statischen Transit-Informationen mit drei verschiedenen Arten der Zusatzinformation. Diese drei Anreicherungen werden üblicherweise via HTTP einzeln zur Verfügung gestellt und regelmäßig aktualisiert, somit können Entwickler auswählen, mit welchen Echtzeitdaten sie ihre Applikationen anreichern möchten. Aktuell ist noch unklar, welche dieser Daten genau in Zukunft auf der Open-Data Plattform öV-Schweiz zur Verfügung gestellt werden.
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.
Eine ausführliche Auflistung der einzelnen möglichen Informationseinheiten finden Sie auf https://developers.google.com/transit/gtfs-realtime/reference/
Wichtige Konzepte
- GTFS Static: Publikation von statischen Transit-Informationen im GTFS Format.
- GTFS Realtime: Publikation von Echtzeit-Transit-Informationen als Anreicherung der statischen GTFS Daten, in der Form von Protocoll Buffers.
Technische Aspekte
Die SBB stellt die Trip Updates über einen GET-Request zur Verfügung.
Authorisierung und Open Services
Für den Zugriff auf diese API ist ein API-Key notwendig. Es kann über das Developer Portal bezogen werden. Sie brauchen einen Schlüssel vom Typ “GTFS-RT Beta”. Das Token muss im HTTP Header als “Authorization” mitgeschickt werden.
Test-Key: 57c5dbbbf1fe4d000100001842c323fa9ff44fbba0b9b925f0c052d1
Maximale Anzahl Abfragen pro Minute
Sie können maximal zwei Abfragen pro Minute auf die Schnittstelle durchführen mit ihrem Schlüssel. Es handelt sich um ein Sliding Window.
Bei zu raschem Anfragen kommt folgende Meldung zurück:
|
1 2 3 |
{ "error": "Rate limit exceeded" } |
Bezug zum GFTS Static
Jeder GTFS-RT Feed basiert auf einem GTFS Static. Dieses wird Laufe des Mittwochs zur Verfügung gestellt. Am Mittwoch um 14:00 wird der GTFS-RT Feed auf das neue GTFS Static umgestellt. Da viele der Identifier (“service_id”, “trip_id”) jeweils neu generiert werden, ist der Bezug auf das richtige GTFS zentral für eine korrekte Implementierung der Schnittstelle.
URL für den Aufruf
HTTP GET auf https://api.opentransportdata.swiss/gtfsrt2020
(Achtung: Kein Schluss “/”)
Mit dem Authorization Header und Content-Type= “text/XML” oder “application/XML”
Content-Type: Wir schlagen vor, Sie stellen “application/octet-stream” ein.
Struktur der Daten (Protocol Buffer)
Das GTFS Realtime Daten-Austausch Format basiert auf Protocol Buffers, welches ein Sprach- und Plattformneutraler Mechanismus ist, um Daten in serielle Reihenfolge zu bringen. Es ist als Binärformat konzipiert, was es kleiner, schneller und einfacher als XML macht. Die Datenstruktur ist in einem sog. gtfs-realtime.proto File definiert, welches zum Generieren von Source Code benutzt wird um die strukturierten Daten einfach in verschiedene Sprachen (Java, C++, Python, etc.) zu übersetzen.
Struktur der Daten (JSON)
Alternativ stellt die Plattform auch eine JSON-Implementierung zur Verfügung.
Die Abfrage erfolgt dann über die URL: HTTP GET https://api.opentransportdata.swiss/gtfsrt2020?format=JSON
Beachten Sie, dass die JSON-Variante nicht standardisiert ist.
Nutzung von JSON nur zu Testzwecken
JSON darf nur zu Testzwecken genutzt werden, wenn z.B. ein Entwickler einer neuen App in lesbarer Form sehen will, was für Daten in unserem GTFS-RT enthalten sind.
Am Ende sollte die GTFS-RT-Schnittstelle nicht in lesbarem JSON, sondern binär betrieben werden (ohne ?FORMAT=JSON) aus folgenden Gründen:
- binär ist viel performanter als JSON und in JSON sind viel mehr Daten zu übermitteln und einzulesen (ein JSON-Meldung wird bis zu ca. 11 MB gross),
- JSON ist nicht spezifiziert, bei der binären GTFS-RT kann sich der GTFS-Client darauf verlassen, dass sie dem GTFS-RT-Standard entspricht
Genauigkeit
Alle Verspätungen sind nur minutengenau. Eine Erweiterung ist angedacht, wird aber erst später erfolgen.
Kompression
Der JSON-Strom kann auch komprimiert bezogen werden.
Dazu muss der folgende Header mitgeliefert werden:
|
1 |
Accept-Encoding: gzip, deflate |
Die Kompression beträgt ca. 90%. D.h. die Daten werden viel schneller übermittelt.
Interpretation der Daten
Für die genaue Interpretation der Daten kann direkt die GTFS-Spezifikation konsultiert werden.
Der grösste Spezialfall sind die Steige und diese sind auf der GTFS-Seite beschrieben.
Weitere wichtige Punkte
- Für GTFS-RT gilt eine Fortschreiberegel für Verspätungen. Wenn z.B. eine ganze Fahrt 5 Minuten verspätet ist, so wird dies nur auf dem ersten Stop ausgewiesen.
Für alle weiteren Stops muss beim Import die Verspätung fortgeschrieben werden. Die Fortschreibung muss für Ankunfts- und Abfahrtszeiten vorgenommen. - GTFS-RT liefert nur neue Daten, wenn sich etwas geändert hat. Dabei wird von unserem System nur die Abfahrtsprognose beachtet. Sollte die Abfahrtsprognose
bleiben und sich nur die Ankunftsprognose ändern, so wird keine GTFS-RT-Meldung für diese Fahrt generiert.
Fragen & Anworten
| 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. |
| 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. |
Weiterführende Angaben
Weiterführende Angaben zu GTFS Realtime finden Sie auf der GTFS Entwicklerseite von Google: https://developers.google.com/transit/gtfs-realtime/
Weitere GTFS-Services: