Updates zu Fahrten spiegeln Schwankungen im Fahrplan wider. Wir erwarten, solche Updates für alle von Ihnen geplanten echtzeitfähigen Fahrten zu erhalten. Updates zu Fahrten enthalten normalerweise voraussichtliche Ankunfts- und Abfahrtszeiten für die Haltestellen der Route. Es können aber auch komplexere Fälle berücksichtigt werden, etwa ausgefallene oder zusätzliche Fahrten oder Fahrten mit abweichender Route.
Erinnerung: Bei GTFS ist eine Fahrt eine Abfolge von zwei oder mehr Haltestellen, die zu einer bestimmten Zeit angefahren werden.
Pro geplanter Fahrt sollte es maximal ein Update geben. Gibt es für eine geplante Fahrt kein Update, wird davon ausgegangen, dass keine Echtzeitdaten zur Fahrt verfügbar stehen. Der Datennutzer sollte nicht davon ausgehen, dass die Fahrt planmäßig verläuft.
Updates der Haltestellenzeiten
Ein Update zu einer Fahrt besteht aus einer oder mehreren Aktualisierungen der Haltestellenzeiten des oder der Fahrzeuge. Diese werden als StopTimeUpdate
-Nachrichten bezeichnet und können für vergangene und zukünftige Haltestellenzeiten angegeben werden. Sie können frühere Haltestellenzeiten verwerfen, müssen das aber nicht tun. Ersteller von Daten sollten ein in der Vergangenheit liegendes StopTimeUpdate
nicht löschen, wenn es für die angegebene Fahrt auf eine Haltestelle mit einer geplanten Ankunftszeit in der Zukunft verweist (d. h., das Fahrzeug war vor der im Fahrplan angegebenen Uhrzeit an der Haltestelle). Andernfalls würde das System davon ausgehen, dass es für diese Haltestelle kein Update gibt.
Beispielsweise sind die folgenden Daten im GTFS Realtime-Feed:
- Haltestelle 4 – Vorhergesagt um 10:18 Uhr (geplant um 10:20 Uhr – 2 Minuten früher)
- Haltestelle 5 – Vorhergesagt um 10:30 Uhr (geplant um 10:30 Uhr – rechtzeitig)
Die Vorhersage für Haltestelle 4 darf erst um 10:21 Uhr aus dem Feed entfernt werden, auch wenn der Bus die Haltestelle tatsächlich um 10:18 Uhr erreicht. Wenn das StopTimeUpdate
für Haltestelle 4 um 10:18 Uhr oder 10:19 Uhr aus dem Feed gelöscht werden würde und die geplante Ankunftszeit 10:20 Uhr ist, sollte der Verarbeiter der Daten davon ausgehen, dass derzeit keine Echtzeitinformationen für Haltestelle 4 verfügbar sind und daher Fahrplandaten von GTFS verwendet werden müssen.
Jedes StopTimeUpdate
ist mit einer Haltestelle verknüpft. Normalerweise kann hierzu ein GTFS-stop_sequence
oder ein GTFS-stop_id
verwendet werden. Wenn Sie jedoch ein Update für eine Fahrt ohne GTFS-trip_id
zur Verfügung stellen, müssen Sie stop_id
angeben, da stop_sequence
keinen Wert hat. Die stop_id
muss weiterhin auf eine stop_id
in GTFS verweisen. Wenn dieselbe stop_id
während einer Fahrt mehrmals erreicht wird, sollte stop_sequence
in allen StopTimeUpdate
-Nachrichten für diese stop_id
dieser Fahrt angegeben werden.
Das Update kann genaue Zeitangaben für arrival
und/oder departure
an einer Haltestelle in StopTimeUpdate
enthalten (mithilfe von StopTimeEvent
).
Hier sollte entweder ein absoluter time
- oder delay
-Wert enthalten sein, also die Abweichung von der geplanten Zeit in Sekunden. Das Feld delay
kann nur verwendet werden, wenn sich das Update auf eine geplante GTFS-Fahrt bezieht und nicht auf eine häufigkeitsbasierte Fahrt. In diesem Fall sollte die Zeit der geplanten Zeit zuzüglich der Verspätung entsprechen. Sie können für die Vorhersage auch uncertainty
zusammen mit StopTimeEvent
angeben. Dies wird im Abschnitt Unsicherheit weiter unten ausführlicher erläutert.
Für jedes StopTimeUpdate
ist die standardmäßige Fahrplanbeziehung scheduled
. (Hinweis: Dies unterscheidet sich von der Fahrplanbeziehung für die Fahrt.) Sie können dies zu skipped
ändern, wenn das Fahrzeug nicht an der Haltestelle hält, oder zu no data
, wenn Sie nur für einen Teil der Fahrt Echtzeitdaten haben.
Updates sollten in der Reihenfolge nach stop_sequence
(oder stop_ids
) sortiert werden, wie sie bei der Fahrt stattfinden.
Wenn eine oder mehrere Haltestellen der Fahrt fehlen, wird das Update für alle nachfolgenden Haltestellen übernommen. Wenn also die Haltestellenzeit für eine bestimmte Haltestelle aktualisiert wird und keine anderen Informationen vorliegen, werden die Zeiten für alle nachfolgenden Haltestellen entsprechend geändert.
Beispiel 1
Bei einer Fahrt mit 20 Haltestellen bedeutet ein StopTimeUpdate
mit einer Ankunfts- und Abfahrtsverspätung von 0
(StopTimeEvent
) für stop_sequence
der aktuellen Haltestelle, dass die Fahrt planmäßig verläuft.
Beispiel 2
Bei derselben Fahrt werden drei StopTimeUpdate
-Nachrichten zur Verfügung gestellt:
- Verspätung von 300 Sekunden für
stop_sequence
3 - Verspätung von 60 Sekunden für
stop_sequence
8 - Verspätung für eine nicht angegebene Dauer für
stop_sequence
10
Dies wird dann so interpretiert:
- Die
stop_sequence
-Nachrichten 1 und 2 haben eine unbekannte Verspätung. - Die
stop_sequence
-Nachrichten 3, 4, 5, 6 und 7 haben eine Verspätung von 300 Sekunden. - Die
stop_sequence
-Nachrichten 8 und 9 haben eine Verspätung von 60 Sekunden. - Die
stop_sequence
-Nachrichten 10 bis 20 haben eine unbekannte Verspätung.
Fahrtbeschreibung
Die von der Fahrtbeschreibung angegebenen Informationen hängen von der Fahrplanbeziehung der zu aktualisierenden Fahrt ab. Es gibt eine Reihe von Optionen, die Sie festlegen können:
Wert | Kommentar |
---|---|
Scheduled |
Diese Fahrt folgt einem GTFS-Fahrplan oder ist nah genug, um sie diesem zuzuordnen. |
Added |
Diese Fahrt war nicht geplant und wurde hinzugefügt, etwa, um der gestiegenen Nachfrage gerecht zu werden oder ein ausgefallenes Fahrzeug ersetzen. |
Unscheduled |
Diese Fahrt wird durchgeführt und ist mit keinem Fahrplan verknüpft. Das ist beispielsweise der Fall, wenn es keinen Fahrplan gibt und die Busse als Shuttleservice eingesetzt werden. |
Canceled |
Die Fahrt war geplant, ist jetzt aber entfernt. |
In den meisten Fällen sollten Sie die trip_id
der geplanten Fahrt in GTFS angeben, auf die sich dieses Update bezieht.
Systeme mit wiederholten trip_id-Werten
Bei Systemen mit wiederholten trip_id
-Werten, etwa Fahrten, die mit frequencies.txt
modelliert werden (häufigkeitsbasierte Fahrten), ist die trip_id
keine eindeutige Kennung für eine einzelne Fahrt, da keine bestimmte Zeitkomponente vorhanden ist.
Damit solche Fahrten in einem TripDescriptor
eindeutig identifiziert werden können, müssen drei Kennungen angegeben werden:
trip_id
start_time
start_date
start_time
muss zuerst veröffentlicht werden. Alle späteren Feedaktualisierungen müssen dieselbe start_time
verwenden, wenn sie sich auf dieselbe Fahrt beziehen. StopTimeUpdate
muss verwendet werden, um Anpassungen anzugeben. start_time
muss nicht genau mit der Abfahrtszeit an der ersten Station übereinstimmen, sollte aber nicht weit davon entfernt sein.
Ein Beispiel: Wir beschließen am 25. Mai 2015 um 10:00 Uhr, dass eine Fahrt mit trip_id=T
um start_time=10:10:00
beginnt, und stellen diese Information per Echtzeitfeed um 10:01 Uhr bereit. Um 10:05 Uhr stellen wir plötzlich fest, dass die Fahrt nicht um 10:10 Uhr, sondern um 10:13 Uhr starten wird. In unserem neuen Echtzeitfeed können wir diese Fahrt weiterhin als (T, 2015-05-25, 10:10:00)
ausweisen, geben aber zusätzlich mit einem StopTimeUpdate
die Abfahrt an der ersten Haltestelle für 10:13 Uhr an.
Alternativer Fahrtabgleich
Nicht häufigkeitsbasierte Fahrten können auch durch einen TripDescriptor
eindeutig identifiziert werden, der eine Kombination aus diesen Werten enthält:
route_id
direction_id
start_time
start_date
Dabei ist start_time
die Abfahrtszeit gemäß statischem Fahrplan, sofern die Kombination der angegebenen IDs einer eindeutigen Fahrt zugeordnet wird.
Unsicherheit
Die Unsicherheit betrifft sowohl die Uhrzeit als auch den Verspätungswert eines StopTimeUpdate
.
Die Unsicherheit gibt den erwarteten Fehler der tatsächlichen Verspätung grob als Ganzzahl in Sekunden an. Die genaue statistische Bedeutung ist jedoch noch nicht definiert. Die Unsicherheit kann den Wert 0
haben, etwa bei Zügen mit computergestützter Zeitsteuerung.
Wenn ein Fernbus beispielsweise mit einer geschätzten Verspätung von 15 Minuten an der nächsten Haltestelle ankommt und das Fehlerfenster 4 Minuten beträgt (+2/-2 Minuten), hat uncertainty
den Wert 240
.