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ässig aktualisiert, somit können Entwickler auswählen, mit welchen Echtzeitdaten sie ihre Applikationen anreichern möchten.
Die drei Arten der Zusatzinformation sind:
- Trip Updates
- Service Alerts
- Vehicle Positions (werden auf der Open-Data-Plattform Mobilität Schweiz nicht publiziert)
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 unvorhergesehenen 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.
Datensatz GTFS-RT: Service Alerts (Ereignisinformationen)
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 ähnliche Informationen bereitgestellt werden.
Die Vehicle Positions stehen auf der Plattform nicht zur Verfügung.
Eine ausführliche Auflistung der einzelnen 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 Protocol Buffers.
Technische Aspekte
Die SBB stellt die Trip Updates über einen GET-Request zur Verfügung.
Autorisierung und Open Services
Für den Zugriff auf diese API ist ein API-Key notwendig. Er kann über das Developer Portal bezogen werden. Sie brauchen einen Schlüssel vom Typ “Default Key”. Das Token muss im HTTP Header als “Authorization” mitgeschickt werden.
Test-Key: 57c5dbbbf1fe4d000100001842c323fa9ff44fbba0b9b925f0c052d1
Maximale Anzahl Abfragen pro Minute
Sie können mit ihrem Schlüssel maximal zwei Abfragen pro Minute auf die Schnittstelle durchführen. Es handelt sich um ein Sliding Window.
Bei zu raschem Anfragen kommt folgende Meldung zurück:
|
1 2 3 |
{ "error": "Rate limit exceeded" } |
Bezug zu GFTS Static
Jeder GTFS-RT-Feed basiert auf einem GTFS Static. Dieses wird jeweils montags und donnerstags zur Verfügung gestellt (für den Störungsfall siehe nächster Abschnitt). Jeweils um 15 Uhr wird der GTFS-RT-Feed auf das neue GTFS Static umgestellt. Da viele der Identifier (“service_id”, “trip_id”) für jede Version des GTFS Static neu generiert werden, ist der Bezug auf das richtige GTFS Static zentral für eine korrekte Implementierung der Schnittstelle.
| Publikation GTFS-S | Aktivierung GTFS-RT |
| Montag zwischen 9 und 10 Uhr | Montag 15 Uhr |
| Donnerstag zwischen 9 und 10 Uhr | Donnerstag 15 Uhr |
Seit 2024-09-26 wird im Header per FeedVersion auf die jeweils passende GTFS-Static-Version verwiesen. Bei der Ansicht als JSON könnte der Header dann folgendermassen aussehen (JSON nur zu Testzwecken nutzen, siehe unten):
|
1 2 3 4 5 6 |
"Header": { "GtfsRealtimeVersion": "1.0", "Incrementality": "FullDataset", "Timestamp": 1727429583, "FeedVersion": "20240926" } |
Umgang mit Störungen
Falls bei den regulären Veröffentlichungen am Montag oder Donnerstag etwas schief läuft, wird das korrigierte GTFS-Datenpaar so schnell wie möglich nach der Störung veröffentlicht.
GTFS Realtime wird in diesen Fällen 6 Stunden nach der Veröffentlichung des entsprechenden GTFS-Static-Datensatzes auf diese neue Version umgeschaltet (was auch an der jeweiligen FeedVersion im GTFS Realtime erkennbar ist).
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 Datenformat GTFS Realtime basiert auf Protocol Buffers, welches ein Sprach- und Plattformneutraler Mechanismus ist, um Daten in eine 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 Quellcode 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
Die Verspätungen haben eine Genauigkeit von einer Zehntelminute (0.1 min = 6 s).
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
- 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.
- Wenn eine Fahrt pünktlich fährt, so wird sie mit “Delay”: 0 ausgegeben auf den StopTimeUpdate. Bsp.
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 hat 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/