GTFS-Modellierung (General Transit Feed Specification) sorgt dafür, dass Google Transit unterbrechungsfrei läuft und korrekte Daten liefert. Dabei werden statische und echtzeitbasierte (Realtime, RT) Feeds so konzipiert, dass durch ihren Abgleich realitätsnähe Daten des aktuellen Verkehrsbetriebs dargestellt werden können.
Grundlagen der GTFS-Modellierung
- GTFS Static-Feeds: Nachdem der Feed an Google gesendet wurde, wird er innerhalb von 24 bis 48 Stunden verarbeitet. Falls Probleme im Feed erkannt werden, kann der Vorgang länger dauern.
Mit GTFS Static werden bestehende Fahrpläne und Fahrtrouten öffentlicher Verkehrsmittel dargestellt. Sie sollten Google Ihren statischen Feed mindestens 2 Tage im Voraus zur Verfügung stellen. Eine Woche im Voraus ist ideal, falls es in Ihrem Feed Konflikte oder Auffälligkeiten geben sollte, die manuell überprüft werden müssen. - GTFS Realtime-Feeds: An Google gesendete Aktualisierungen greifen sofort.
GTFS Realtime liefert den Echtzeitstatus zu statischen Daten. Anhand von Echtzeitdaten zu Fahrzeugpositionen (Vehicle Position, VP) und Fahrtaktualisierungen (Trip Update, TU) können Verspätungen zu den im statischen Feed vordefinierten Fahrten oder Haltestellen gemeldet werden. Außerdem werden die Nutzer so über Störungen, wie etwa Verspätungen und Ausfälle, informiert. - Es gibt Behelfslösungen zum Aktivieren und Deaktivieren von Fahrten in GTFS. Die Möglichkeiten sind aber insofern eingeschränkt, als undefinierte Dienste (Form, Route sowie Haltestellenfolge und -zeiten) nicht in Echtzeit, sondern nur mit einer Vorlaufzeit von mindestens 2 Tagen hinzugefügt werden können. Wegen der manuellen Überprüfung auf miteinander in Konflikt stehende oder „verdächtige“ Änderungen nimmt das Hinzufügen von Diensten mindestens 2 bis 7 Tage in Anspruch.
- Mit der Datei feed_info.txt in Ihrem statischen Feed können Sie 2 bis 7 Tage im Voraus festlegen, wann statische Änderungen online gehen sollen und sie so mit den Echtzeitfeeds abstimmen. Verwenden Sie die Felder „feed_start_date“ und „feed_end_date“, um den Zeitraum anzugeben, in dem der statische Feed aktiv sein soll. Wenn „feed_start_date“ in der Zukunft liegt (auf Grundlage des Verarbeitungszeitpunkts), wird dieser Feed dennoch von uns verarbeitet. Hierbei werden sowohl die aktuelle als auch die „zukünftige“ Version beibehalten.
- Statische Feeds enthalten Kerndaten zu Routen, Haltestellen und zur Fahrtenplanung. Wie zuvor erwähnt müssen für jegliche Änderungen an statischen Feeds jedoch 2 bis 7 Tage einkalkuliert werden. Im Folgenden finden Sie Best Practices für Planungsänderungen.
Statische und RT-Feeds aktualisieren
Bei landgebundenen Verkehrsdienstleistungen sind verschiedene Änderungen möglich, z. B. unterschiedliche Dauer und Dringlichkeit oder unterschiedliche Entitätstypen. Im Allgemeinen sollten sämtliche Änderungen an Kerndaten im statischen Feed vorgenommen werden. Zu diesen Daten zählen Ergänzungen, Abweichungen oder Streichungen von Haltestellen, Routen oder Fahrten. Einige Änderungen, besonders vorübergehende, die schnell und reaktiv erfolgen müssen, können mithilfe bestimmter Methoden jedoch auch im Echtzeitfeed umgesetzt werden. In den nachfolgenden Tabellen finden Sie Best Practices zum Aktualisieren Ihrer Feeddaten.
Allgemein:
| Statisch (2 bis 7 Tage im Voraus) | Echtzeit (ca. 1 Minute) | |
|---|---|---|
| Daten zum Feed hinzufügen | Die meisten Änderungen sind möglich und lassen sich ganz unkompliziert vornehmen. | Nur das Hinzufügen zu einem vorhandenen Takt mit „schedule_relationship“ ist möglich. |
| Daten aus dem Feed entfernen | Das Löschen in größerem Umfang wird als verdächtig gekennzeichnet und unter Umständen einer längeren Prüfung unterzogen. | Der Echtzeitfeed eignet sich nicht dafür, statische Daten zu löschen. Störungsmeldungen werden aber zum vorübergehenden Löschen empfohlen. |
| Daten im Feed ändern | Die meisten Änderungen sind möglich und lassen sich ganz unkompliziert vornehmen. | Das Ändern wird nicht unterstützt oder empfohlen. |
| Statisch (2 bis 7 Tage im Voraus) | Echtzeit (ca. 1 Minute) | |
|---|---|---|
| Hinzufügen | Falls gewünscht kann „shape_id“ einer bestehenden Fahrt aus „trips.txt“ hinzugefügt werden. | Nicht möglich. Die „shape_id“ muss vorhanden sein. |
| Löschen | Falls gewünscht kann „shape_id“ aus bestehenden Fahrten in „trips.txt“ entfernt werden. Unter Umständen sind ungenutzte Formen vorhanden. | – |
| Ändern | Sie können die Form auf Wunsch ändern. Die Änderungen sind nach 2 Tagen live zu sehen. | – |
| Statisch (2 bis 7 Tage im Voraus) | Echtzeit (ca. 1 Minute) | |
| Hinzufügen |
Ja. Unter Umständen sind entsprechende Haltestellenzeiten (Datei „stop_times“) und Fahrtänderungen erforderlich. Hinweis: Wegen der Überprüfung kann es einige Zeit dauern (mehr als 2 Tage), bis neue Haltestellennamen auf Google Maps erscheinen. |
– |
| Löschen | Möglich. Die Haltestellenzeiten in „stop_times“ dürfen sich nicht auf undefinierte Haltestellen beziehen. |
Auswirkung von NO_SERVICE bei Störungsmeldungen: Die Haltestelle wird bei jeder Fahrt übersprungen, zu der sie gehört. Alternativ kann für das Feld „schedule_relationship“ in StopTimeUpdate der Wert SKIPPED eingetragen werden. |
| Ändern | Aufgrund eines intensiven Überprüfungsprozesses kann es mehr als 2 Tage dauern, bis Änderungen zu sehen sind. | Nein. Nur Löschen ist möglich. |
| Statisch (mindestens 2 bis 7 Tage im Voraus) | Echtzeit (ca. 1 Minute) | |
| Hinzufügen | Das Hinzufügen einer Haltestellenzeit in der Datei „stop_times.txt“ entspricht dem Einfügen einer bestehenden Haltestelle zusammen mit einer definierten Fahrt. Es kann 2 Tage dauern, bis die Änderungen live zu sehen sind. | Nicht möglich. |
| Löschen | Entfernen Sie in der Datei „stop_times.txt“ Haltestellenzeiten aus gewünschten Fahrten, wenn Sie die entsprechenden Haltestellen in „trips.txt“ herausnehmen möchten. Es kann 2 Tage dauern, bis die Änderungen live zu sehen sind. | Für das Feld „schedule_relationship“ in StopTimeUpdate kann der Wert SKIPPED eingetragen werden. |
| Ändern | Die Datei „stop_times“ lässt sich falls gewünscht ändern. Die Änderungen sind nach 2 Tagen live zu sehen. |
Im Prinzip sind die VP und die TU das Ergebnis geänderter Haltestellenzeiten in Echtzeit. Bei Störungsmeldungen mit den Auswirkungen SIGNIFICANT_DELAYS (erhebliche Verspätungen) und MODIFIED_SERVICE (geänderter Fahrbetrieb) können auch geänderte Haltestellenzeiten angegeben werden. |
| Statisch (mindestens 2 bis 7 Tage im Voraus) | Echtzeit (ca. 1 Minute) | |
| Hinzufügen |
Mit calendar_dates.txt können Sie den Dienst explizit nach Datum aktivieren oder deaktivieren. Mithilfe von calendar_dates.txt und calendar.txt können Sie Ausnahmen für die in calendar.txt definierten Standarddiensteinstellungen festlegen. Wenn der Dienst im Allgemeinen regelmäßig ausgeführt wird, mit wenigen Änderungen zu bestimmten Terminen (z. B. bei besonderen Veranstaltungen oder zu Schulzeiten), ist dies ein guter Ansatz. Es dauert 2 Tage, bis sie live zu sehen sind, aber der GTFS-Feed muss nicht wesentlich geändert werden. Wenn ein Fahrzeug Teil der Fahrt und im Fahrbetrieb ist, muss eine einzelne Zeile bearbeitet werden. Zwischen „Fahrbetrieb“ und „Fahrt“ lässt sich auf der untersten Ebene eine 1:1-Zuordnung herstellen. |
Mit den entsprechenden Werten im Feld „schedule_relationship“ des Echtzeitfeeds können Sie Informationen zu außerplanmäßigen Fahrten angeben. Die Form und die Haltestellenzeit in „stop_time“ müssen auf Basis einer bestehenden Fahrt vordefiniert sein. Mit ADDED werden geplante Fahrten mit neuer Startzeit (start_time) hinzugefügt, sofern die übergeordnete Fahrt keine Blocktransfers hat. Eine konsistente Startzeit ist wichtig für die Unterscheidung zwischen Fahrten. Mit ADDITIONAL_SERVICE werden in Störungsmeldungen zusätzliche Busse beschrieben, die auf bestehenden Linien eingesetzt werden. |
| Löschen |
Entfernen Sie die Fahrt und alle Bezüge (Takte, Haltestellenzeiten, Fahrten). In 2 Tagen live zu sehen. Eine andere Möglichkeit besteht darin, die entsprechenden Einträge aus „calendar.txt“ zu entfernen oder in „calendar_dates.txt“ Ausnahmen hinzuzufügen. |
Durch eine Fahrtaktualisierung mit „schedule_relationship SKIPPED“ erreichen Sie dasselbe. Durch die Störungsmeldung mit der Auswirkung NO_SERVICE (kein Fahrbetrieb) oder REDUCED_SERVICE (eingeschränkter Fahrbetrieb) wird dies ebenfalls dem Nutzer angezeigt. Verwenden Sie beschreibenden Text. |
| Ändern |
Sie können Fahrten bei Bedarf ändern. Eine andere Möglichkeit besteht darin, entsprechende Einträge in „calendar.txt“ zu definieren oder in „calendar_dates.txt“ Ausnahmen hinzuzufügen. |
Die Änderung von Haltestellen für Fahrten ist nicht zulässig. Aber Verspätungen und die vorzeitige Ankunft werden durch TU oder VP angegeben. Haltestellen und Teile von Fahrten können durch Störungsmeldungen in Echtzeit blockiert werden (siehe oben). |
| Statisch (2 bis 7 Tage im Voraus) | Echtzeit (ca. 1 Minute) | |
| Hinzufügen | Zum Hinzufügen einer Route müssen Sie in „routes.txt“ eine Zeile einfügen. Die Route ist aber erst zu sehen, wenn in „trips.txt“ Fahrten erstellt und dieser Route zugewiesen werden. | Nicht möglich oder wird nicht empfohlen. |
| Löschen | Sie haben die Möglichkeit, Routen zu entfernen. Die sich darauf beziehenden Fahrten müssen Sie entweder ebenfalls entfernen oder einer anderen Route zuweisen. In 2 Tagen live zu sehen. |
Durch NO_SERVICE (kein Fahrbetrieb) würden alle mit dieser Route verbundenen Fahrten gestoppt. Haltestellen auf dieser Route, die auch für andere Routen oder Fahrten genutzt werden, wären nicht betroffen. Hinweis: Das Löschen der eigentlichen Route ist nach wie vor ein statisches Konzept. |
| Ändern |
Sie können Fahrten bei Bedarf ändern. Hinweis: Nutzer erkennen Routen an den entsprechenden Farben oder Namen. Von häufigen Änderungen ist daher abzuraten. |
Nicht möglich oder wird nicht empfohlen. |
Weitere Informationen zu Echtzeitfeeds
Wichtig: Die Echtzeitänderung von Formen oder Fahrtwegen und von Kernelementen statischer Feeds wird derzeit nicht unterstützt oder empfohlen.
Es ist möglich, Daten in Echtzeit hinzuzufügen und zu löschen. Hierzu muss im statischen Feed eine Beschreibung des Wegs, der Haltestellenfolge (stop_sequence) und der Haltestellenzeiten (stop_time) vorhanden sein – also eine Fahrt, die als Modell verwendet werden kann.
Die vorausschauende Verwendung von „calendar.txt“ und „calendar_dates.txt“ wird empfohlen. Ein Beispiel: Berücksichtigen Sie Schneetage und geben Sie dazu Fahrten an, die möglicherweise nicht im aktuellen Betrieb, aber in künftigen Eventualfällen durchgeführt werden. Definieren Sie also Fahrten im Voraus. Dann können Sie zu gegebener Zeit die entsprechenden Fahrten über den Echtzeitfeed aktivieren oder deaktivieren (Standard).
Häufig gestellte Fragen
F: An der Haltestelle X gab es einen kleinen Unfall. Daher möchte ich diesen Ort so bald wie möglich umgehen und stattdessen die Haltestelle Y nutzen. Ist das möglich?A: Die möglichen Maßnahmen hängen davon ab, wann das Festival stattfindet.
Wenn es noch mehr als 2 Tage bis zum Festival sind:
Deaktivieren Sie mithilfe von „calendar_dates.txt“ für die Dauer des Festivals alle vorhandenen geänderten Fahrten. Sie können für diesen Zeitraum auch neue Fahrten einfügen. Neue Haltestellen lassen sich nur schwer hinzufügen. Deshalb sollten Sie für diesen Fall mindestens eine Woche im Voraus planen. Sie haben aber die Möglichkeit, bestehende Haltestellen zu verwenden. So ändern Sie Haltestellen:
- Erstellen Sie für die betroffenen bestehenden Fahrten mit den regulären und den auszuschließenden Kalenderdaten einen neuen Kalender und neue Einträge in „calendar_dates“ (neue service_id).
- Verweisen Sie die betroffenen Fahrten auf diesen neuen Kalender (service_id).
- Erstellen Sie Einträge in „calendar_dates“ mit einer neuen service_id für die Tage der Veranstaltung, an denen neue, spezielle Routen und abgeänderte Versionen der betroffenen Fahrten verwendet werden sollen.
- Erstellen Sie Fahrten und Formen für abgeänderte Versionen der betroffenen Fahrten sowie Routen, Fahrten und Formen für Sonderlinien. Diese sollten alle auf die in Schritt 3 erstellte service_id verweisen.
- Verwenden Sie nach der Veranstaltung wieder das frühere Feedformat.
Wenn es weniger als 2 Tage bis zum Festival sind:
Wir können bestehende Fahrten streichen. Dies kann durch Störungsmeldungen mit der Auswirkung MODIFIED_SERVICE mitgeteilt werden. Die Zeit ist zu knapp, um neue Haltestellen oder Haltestellenzeiten in die Routenpläne aufzunehmen. Wir können aber bestehenden Linien (fahrplan- oder taktbasiert) Fahrzeuge hinzufügen, um dem stärkeren Betrieb Rechnung zu tragen.
A: Das geht nur, wenn der statische Feed eine Fahrt mit derselben Haltestellenfolge (stop_sequence) enthält. Andernfalls ist es nicht möglich, dies in weniger als zwei Tagen in den Index aufzunehmen.
Es kann aber auf Basis einer Fahrt mit anderen Startzeiten eine TU oder VP festgelegt und das Feld „Schedule_Relationship“ auf ADDED eingestellt werden. Dadurch wird mit den Haltestellen der angegebenen „trip_id“ eine Fahrt mit der neuen Startzeit eingeführt.
Wichtig: Die Werte für „start_time“, „direction_id“, „start_date“ und „trip_id“ dürfen nach dem Hinzufügen nicht geändert werden, damit der Bezug zur betroffenen Fahrt bestehen bleibt. Bei Fahrten mit Blocktransfers ist das nicht zulässig. TU- und VP-Feed können wie unten dargestellt aussehen.
Das folgende Beispiel ist aber lediglich als Orientierunghilfe zu verstehen, nicht als gültiger GTFS Realtime-Code.
# Headerinformationen
header {
# Version der Geschwindigkeitsangabe (derzeit „2.0“)
gtfs_realtime_version: "2.0"
# Gibt an, ob es sich um einen vollständigen oder einen inkrementellen Datensatz handelt
incrementality: FULL_DATASET
# Zeitpunkt, zu dem der Datensatz auf dem Server erstellt wurde
timestamp: 1284457468
}
# Im Feed können mehrere Entitäten enthalten sein.
entity {
# Eindeutige ID für die Entität
id: "add-a-trip"
# Entitätstyp
trip_update {
trip {
# Auswahl der betroffenen GTFS-Entität („trip“ – Fahrt)
Schedule_relationship: ADDED
trip_id: "tripid_of_trip_to_copy" # In GTFS Static definiert
route_id: "routeid_of_trip_to_copy" # In GTFS Static definiert
# Darf KEINE Blocktransfers enthalten.
start_time: "10:00:00" # Ortszeit, zu der diese Ad-hoc-Fahrt beginnt
start_date: "20180201" # Lokales Datum, an dem diese Ad-hoc-Fahrt beginnt
}
...
}
}