Fahrt mit TripDescriptor auswählen

Wichtig: Der TripDescriptor darf während der gesamten Fahrtdauer nicht geändert werden. Er wird für die Auswahl einer einzelnen Fahrt verwendet.

Zum Verknüpfen einer Echtzeitfahrt mit ihrem statischen GTFS-Prototyp (General Transit Feed Specification) wird die untergeordnete TripDescriptor-Nachricht verwendet. In diesem Artikel wird beschrieben, wie Sie eine Fahrt für schedule_relationship als SCHEDULED oder CANCELED auswählen.

Fahrt hinzufügen oder zuordnen

Wenn Sie eine Fahrt in Echtzeit mit schedule_relationship als ADDED hinzufügen möchten, finden Sie weitere Informationen unter Fahrt in Echtzeit hinzufügen.

Falls Sie eine Fahrt in Echtzeit mit einem statischen Datensatz abgleichen möchten, müssen Sie in TripDescriptor ein Tupel angeben:

• trip_id
• start_time
• start_date

Sollte der Wert trip_id nicht verfügbar sein, können Sie ihn durch route_id und direction_id ersetzen. Für einen korrekten Abgleich sind start_time und start_date erforderlich.

TripDescriptor für häufigkeitsbasierte und nicht häufigkeitsbasierte Fahrpläne angeben

Nicht häufigkeitsbasierte TripDescriptors

• Die Felder trip_id und start_date sind erforderlich, um eine Fahrt im statischen Fahrplan zu identifizieren. Das Feld start_time ist optional. Falls angegeben, muss diese mit einer der Startzeiten am angegebenen Startdatum aus dem statischen Fahrplan übereinstimmen.
• Wenn trip_id nicht verfügbar ist, müssen Sie stattdessen gültige Werte für <route_id, direction_id, start_date> angeben.
  • Damit die Abgleichmethode mit route_id und direction_id funktioniert, muss der statische GTFS-Feed den Wert direction_ids enthalten. Diese Methode ist nicht ideal, weil sie nach bestem Wissen und Gewissen funktioniert und sich ändern kann.

Beispielcode

trip_update {

    trip {

      trip_id: "non_frequency-expanded-trip"

      start_date: "20160203"

    }

  }

trip_update {

    trip {

      route_id: "route1"

      direction_id: 0

      start_time: "10:10:00"

      start_date: "20160203"

    }

}

Häufigkeitsbasierte TripDescriptors

Häufigkeitsbasierte Fahrten werden in der Datei frequencies.txt definiert. Für diese Arten von Fahrten ist das Feld start_time erforderlich, weil eine bestimmte Zeitkomponente benötigt wird, um eine einzelne Fahrt zu identifizieren.

• Zum Identifizieren einer Fahrt aus dem statischen Zeitplan ist ein Tupel aus trip_id, start_date und start_time erforderlich. Wenn entsprechende Informationen fehlen, erfolgt der Abgleich einer Fahrt nach bestem Wissen und Gewissen.
• Falls Sie trip_id nicht angeben können, müssen Sie stattdessen gültige Werte für route_id, direction_id, start_date und start_time zur Verfügung stellen. Damit die Abgleichmethode mit route_id und direction_id funktioniert, muss der statische GTFS-Feed den Wert „direction_ids“ enthalten. Diese Methode ist nicht ideal.

Beachten Sie Folgendes, wenn Sie den Wert start_time angeben:

• Das Feld start_time muss mit der geplanten Startzeit aus dem statischen Datensatz übereinstimmen.
• start_time muss in allen TripDescriptors, die dieselbe Fahrt repräsentieren, sowie in allen Feedgruppen gleich bleiben.
• Passen Sie nicht die start_time an, um die erste Abfahrtszeit an der ersten Haltestelle zu korrigieren. Verwenden Sie dafür stattdessen StopTimeUpdates.
• Der Wert start_time sollte zwar nicht sehr von der Abfahrtszeit an der ersten Haltestelle abweichen, muss aber nicht exakt damit übereinstimmen.

Hinweis: Fallen trip_id und start_time in das Intervall exact_time=1, muss start_time um ein exaktes Vielfaches von headway_secs nach dem Beginn des Intervalls liegen.

Beispiel

Wir legen am 25. Mai 2015 um 10:00 Uhr fest, dass eine Fahrt mit trip_id=T um start_time=10:10:00 beginnt. Diese Informationen stellen wir per Echtzeitfeed um 10:01 Uhr bereit. Um 10:05 Uhr stellen wir fest, dass die Fahrt um 10:13 Uhr statt um 10:10 Uhr beginnt. In unserem Echtzeitfeed können wir diese Fahrt immer noch 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:00 Uhr an.

Wenn der Wert start_time geändert wird, kann das dazu führen, dass die Abfahrtszeit eines zweiten Busses angegeben wird. In diesem Szenario ist eine Abfahrt um 10:10 Uhr und eine andere um 10:13 Uhr.

Beispielcode:

trip_update {

    trip {

         trip_id: "T"

         start_date: "20150525"

         start_time: "10:10:00"

    }

    stop_time_update {

      stop_sequence: 1

      departure {

        delay: 180

      }

    }

}