Updates zu Fahrten

Stay organized with collections Save and categorize content based on your preferences.

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 vorhergesagte Ankunfts- und Abfahrtszeiten für die Haltestellen der Route. Außerdem können solche Updates komplexere Szenarien vermitteln, 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.