GTFS Realtime-Referenz

Mit einem GTFS Realtime-Feed können Betreiber ihren Kunden in Echtzeit Informationen über Betriebsstörungen (nicht verfügbare Haltestellen, nicht bediente Linien, wichtige Verspätungen usw.), zur Position ihrer Fahrzeuge und zu den voraussichtlichen Ankunftszeiten zur Verfügung stellen.

Auf dieser Website wird Version 2.0 der Feedspezifikation erläutert und dokumentiert.

Begriffsdefinitionen

Required

In GTFS Realtime ab Version 2.0 ist in der Spalte Required (Erforderlich) angegeben, welche Felder ein Feedersteller angeben muss, damit die Daten zu öffentlichen Verkehrsmitteln gültig sind und von einer verarbeitenden Anwendung interpretiert werden können.

Die folgenden Werte werden im Feld Required verwendet:

  • Required: Dieses Feld muss vom Ersteller eines GTFS Realtime-Feeds angegeben werden.
  • Conditionally required (Bedingt erforderlich): Dieses Feld ist unter bestimmten Bedingungen erforderlich, die im Feld Description (Beschreibung) beschrieben werden. Wenn diese Bedingungen nicht vorliegen, ist das Feld optional.
  • Optional: Dieses Feld ist optional und muss von Erstellern nicht implementiert werden. Sind die Daten jedoch in den zugrunde liegenden automatischen Fahrzeugortungssystemen verfügbar (z. B. VehiclePosition timestamp), empfehlen wir Feederstellern, diese optionalen Felder nach Möglichkeit anzugeben.

Semantische Anforderungen waren in Version 1.0 von GTFS Realtime nicht definiert. Daher erfüllen Feeds mit gtfs_realtime_version von 1 diese Anforderungen möglicherweise nicht. Weitere Informationen hierzu finden Sie im Vorschlag für semantische Anforderungen.

Cardinality

Cardinality (Kardinalität) steht für die Anzahl der Elemente, die für ein bestimmtes Feld zur Verfügung gestellt werden können. Folgende Werte sind möglich:

Sehen Sie immer in den Feldern Required und Description nach, ob ein Feld erforderlich, bedingt erforderlich oder optional ist. Weitere Informationen zur Kardinalität von Protokollzwischenspeichern finden Sie unter gtfs-realtime.proto.

Datentypen für Protokollzwischenspeicher

Die folgenden Protokollzwischenspeicher-Datentypen werden zur Beschreibung von Feedelementen verwendet:

  • message (Nachricht): Komplexer Typ
  • enum (Aufzählung): Liste mit festen Werten

Experimentelle Felder

Felder, die als experimental (experimentell) gekennzeichnet sind, können sich ändern und wurden noch nicht offiziell in die Spezifikation übernommen. Zukünftig wird es unter Umständen ein eigenes Feld experimentell geben.

Elementindex

Elemente

FeedMessage (Nachricht)

Der Inhalt einer Feednachricht. Jede Nachricht im Stream wird als Antwort auf eine entsprechende GET-HTTP-Anfrage abgerufen. Ein Echtzeitfeed wird immer im Verhältnis zu einem bestehenden GTFS-Feed definiert. Alle Entitäts-IDs werden in Bezug auf den GTFS-Feed aufgelöst.

Felder

Field Name Type Required Cardinality Description
header FeedHeader Required One Metadaten zu diesem Feed und dieser Feednachricht
entity FeedEntity Conditionally required Many Inhalt des Feeds. Wenn für den Betreiber Echtzeitinformationen verfügbar sind, muss dieses Feld angegeben werden. Ist dieses Feld leer, sollten Nutzer davon ausgehen, dass für den Betreiber keine Echtzeitinformationen vorliegen.

FeedHeader (Nachricht)

Metadaten zu einem Feed (in Feednachrichten enthalten)

Felder

Field Name Type Required Cardinality Description
gtfs_realtime_version string Required One Version der Feedspezifikation. Die aktuelle Version ist 2.0.
incrementality Incrementality Required One
timestamp uint64 Required One Dieser Zeitstempel gibt an, wann der Inhalt dieses Feeds erstellt wurde (Angabe in der Serverzeit). Es handelt sich um eine POSIX-Zeitangabe, also die Anzahl der Sekunden seit dem 1. Januar 1970 um 00:00:00 (UTC). Um Zeitverzerrungen zwischen Systemen zu vermeiden, die Echtzeitinformationen generieren und verarbeiten, sollten Sie timestamp unbedingt von einem Zeitserver abrufen. Es ist vollkommen akzeptabel, Stratum-3- oder sogar niederrangige Strata-Server zu verwenden, da Zeitunterschiede von einigen Sekunden tolerierbar sind.

Incrementality (Aufzählung)

Bestimmt, ob der aktuelle Abrufvorgang inkrementell ist

  • FULL_DATASET: Diese Feedaktualisierung überschreibt alle vorherigen Echtzeitinformationen für den Feed. Daher wird sie voraussichtlich einen vollständigen Snapshot aller bekannten Echtzeitinformationen enthalten.
  • DIFFERENTIAL: Derzeit wird dieser Modus nicht unterstützt und das Verhalten für Feeds, die diesen Modus verwenden, ist nicht angegeben. In der GTFS Realtime-Mailingliste wird darüber diskutiert, das Verhalten des DIFFERENTIAL-Modus vollständig zu spezifizieren. Die Dokumentation wird aktualisiert, sobald diese Diskussionen abgeschlossen sind.

Werte

Value
FULL_DATASET
DIFFERENTIAL

FeedEntity (Nachricht)

Eine Definition (oder Aktualisierung) einer Entität im Feed mit Daten zu öffentlichen Verkehrsmitteln. Wenn die Entität nicht gelöscht wird, sollte genau eines der Felder trip_update, vehicle und alert ausgefüllt sein.

Felder

Field Name Type Required Cardinality Description
id string Required One Eindeutige Feed-ID für diese Entität. Die IDs werden nur verwendet, um die Inkrementalität zu unterstützen. Die tatsächlichen Entitäten, auf die im Feed verwiesen wird, müssen mithilfe von expliziten Selektoren angegeben werden. Weitere Informationen finden Sie im Folgenden unter EntitySelector.
is_deleted bool Optional One Gibt an, ob diese Entität gelöscht werden soll. Sollte nur für Feeds mit einer Incrementality von DIFFERENTIAL angegeben werden. Dieses Feld darf NICHT für Feeds mit einer Incrementality von FULL_DATASET angegeben werden.
trip_update TripUpdate Conditionally required One Daten zu Echtzeitverspätungen bei der Abfahrt im Rahmen einer Fahrt. Mindestens eines der Felder trip_update, vehicle oder alert muss angegeben werden.
vehicle VehiclePosition Conditionally required One Daten zur Echtzeitposition eines Fahrzeugs. Mindestens eines der Felder trip_update, vehicle oder alert muss angegeben werden.
alert Alert Conditionally required One Daten zur Echtzeitbenachrichtigung. Mindestens eines der Felder trip_update, vehicle oder alert muss angegeben werden.

TripUpdate (Nachricht)

Echtzeitaktualisierungen zum Fortschritt eines Fahrzeugs auf einer Fahrt. Weitere Informationen finden Sie in der allgemeinen Diskussion zu Entitäten für Updates zu Fahrten.

Abhängig vom Wert von ScheduleRelationship kann mit einem TripUpdate Folgendes angegeben werden:

  • Eine Fahrt gemäß Fahrplan
  • Eine Fahrt entlang einer Route, aber ohne festen Fahrplan
  • Eine Fahrt, die dem Fahrplan hinzugefügt oder daraus entfernt wurde

Die Aktualisierungen können sich auf zukünftige prognostizierte Ankunfts- und Abfahrtsereignisse oder auf vergangene Ereignisse beziehen. In den meisten Fällen sind Informationen zu vergangenen Ereignissen ein Messwert. Daher wird empfohlen, für die Unsicherheit den Wert 0 anzugeben. Es kann jedoch auch Fälle geben, in denen dies nicht zutrifft. Daher darf der Unsicherheitswert für vergangene Ereignisse von 0 abweichen. Wenn die Unsicherheit eines Updates nicht 0 ist, ist es entweder eine ungefähre Vorhersage für eine noch nicht abgeschlossene Fahrt, die Messung ist nicht präzise oder es handelt sich um eine Vorhersage für die Vergangenheit, die nach dem Ereignis nicht überprüft wurde.

Hinweis: Das Update kann eine Fahrt beschreiben, die bereits abgeschlossen ist. Hier reicht es aus, ein Update für die letzte Haltestelle der Fahrt zur Verfügung zu stellen. Wenn der Zeitpunkt der Ankunft an der letzten Haltestelle in der Vergangenheit liegt, erkennt der Kunde, dass die gesamte Fahrt in der Vergangenheit liegt. Es ist möglich, aber auch irrelevant, Updates für vorherige Haltestellen anzugeben. Diese Option ist für Fahrten, die vor dem Fahrplan abgeschlossen wurden, am relevantesten. Laut Fahrplan wird die Fahrt jedoch aktuell noch fortgesetzt. Wenn die Updates für diese Fahrt entfernt würden, könnte der Kunde annehmen, dass die Fahrt derzeit noch fortgesetzt wird. Der Feedanbieter kann alte Aktualisierungen dauerhaft löschen, muss es jedoch nicht tun. Dies ist einer der Fälle, in denen das Löschen in der Praxis nützlich wäre.

Felder

Field Name Type Required Cardinality Description
trip TripDescriptor Required One Die Fahrt, auf die sich diese Nachricht bezieht. Für jede tatsächliche Fahrtinstanz darf es maximal eine TripUpdate-Entität geben. Wenn keine vorhanden ist, sind keine Vorhersageinformationen verfügbar. Dies bedeutet nicht, dass die Fahrt nach Fahrplan verläuft.
vehicle VehicleDescriptor Optional One Zusätzliche Informationen zum Fahrzeug, mit dem diese Fahrt durchgeführt wird.
stop_time_update StopTimeUpdate Conditionally required Many Aktualisierungen von StopTimes für die Fahrt (sowohl künftige, d. h. Vorhersagen, als auch einige vergangene, d. h. bereits erfolgte). Die Aktualisierungen müssen nach stop_sequence sortiert werden und gelten für alle folgenden Haltestellen der Fahrt bis zum nächsten angegebenen stop_time_update. Für die Fahrt muss mindestens eine stop_time_update angegeben werden, es sei denn, trip.schedule_relationship ist CANCELED. Wenn die Fahrt ausfällt, müssen keine stop_time_updates angegeben werden.
timestamp uint64 Optional One Uhrzeit, zu der der Echtzeitfortschritt des Fahrzeugs gemessen wurde. Es handelt sich um eine POSIX-Zeitangabe, also die Anzahl der Sekunden seit dem 1. Januar 1970 um 00:00 Uhr UTC.
delay int32 Optional One Aktuelle Fahrplanabweichung für die Fahrt. delay sollte nur angegeben werden, wenn die Vorhersage relativ zu einem vorhandenen Fahrplan in GTFS erfolgt.
delay (in Sekunden) kann positiv (d. h. Verspätung des Fahrzeugs) oder negativ (d. h., das Fahrzeug liegt vor dem Zeitplan) sein. Wenn delay den Wert 0 hat, ist das Fahrzeug pünktlich.
Informationen zu Verspätungen in StopTimeUpdates haben Vorrang vor solchen Informationen auf Fahrtebene. Verspätungen auf Fahrtebene werden daher nur bis zur nächsten Haltestelle der Fahrt weitergegeben (StopTimeUpdate delay-Wert angegeben).
Feederstellern wird dringend empfohlen, einen TripUpdate.timestamp-Wert anzugeben, der Aufschluss darüber gibt, wann der delay-Wert zuletzt aktualisiert wurde. So lässt sich die Aktualität der Daten beurteilen.
Achtung: Dieses Feld ist experimentell und kann sich noch ändern. Es wird unter Umständen in der Zukunft offiziell eingeführt.

StopTimeEvent (Nachricht)

Zeitangaben für ein einzelnes vorhergesagtes Ereignis (entweder Ankunft oder Abfahrt). Diese Informationen setzen sich aus der Verspätung und/oder der geschätzten Zeit sowie der Unsicherheit zusammen.

  • delay sollte verwendet werden, wenn die Vorhersage relativ zu einem vorhandenen Fahrplan in GTFS angegeben wird.
  • time sollte unabhängig davon angegeben werden, ob es einen vorhergesagten Fahrplan gibt oder nicht. Wenn sowohl time als auch delay angegeben ist, hat time Vorrang, obwohl time, wenn sie für eine geplante Fahrt angegeben wird, normalerweise der geplanten Zeit in GTFS plus der Verspätung entspricht.

Die Unsicherheit wird sowohl auf die Uhrzeit als auch auf die Verspätung angewendet. Die Unsicherheit gibt ungefähr den erwarteten Fehler der tatsächlichen Verspätung an. Die genaue statistische Bedeutung wird jedoch noch nicht definiert. Die Unsicherheit kann den Wert 0 haben, etwa bei Zügen mit computergestützter Zeitsteuerung.

Felder

Field Name Type Required Cardinality Description
delay int32 Conditionally required One Das Feld delay (in Sekunden) kann positiv (d. h. Verspätung des Fahrzeugs) oder negativ (d. h., das Fahrzeug liegt vor dem Zeitplan) sein. delay 0 bedeutet, dass das Fahrzeug pünktlich ist. In StopTimeEvent muss entweder delay oder time gefüllt sein. Es dürfen nicht beide Felder leer sein.
time int64 Conditionally required One Ein Ereignis als absolute Zeit. Es handelt sich um eine POSIX-Zeitangabe, also die Anzahl der Sekunden seit dem 1. Januar 1970 um 00:00 Uhr UTC. In StopTimeEvent muss entweder delay oder time gefüllt sein. Es dürfen nicht beide Felder leer sein.
uncertainty int32 Optional One Wenn die Unsicherheit weggelassen wird, wird sie als unbekannt gewertet. Wenn Sie eine vollkommen gewisse Vorhersage treffen möchten, geben Sie als Unsicherheit 0 an.

StopTimeUpdate (Nachricht)

Echtzeitaktualisierungen zur Ankunfts- und/oder Abfahrtsereignissen für eine bestimmte Haltestelle einer Fahrt. Weitere Informationen finden Sie in der allgemeinen Diskussion über Aktualisierungen von Haltestellenzeiten in der TripDescriptor und zur Dokumentation für Entitäten für Updates zu Fahrten.

Updates können für vergangene und zukünftige Ereignisse zur Verfügung gestellt werden. Der Ersteller darf vergangene Ereignisse weglassen, muss dies aber nicht tun. Das Update ist über stop_sequence oder stop_id mit einer bestimmten Haltestelle verknüpft, daher muss eines dieser Felder festgelegt werden. Wenn dieselbe stop_id während einer Fahrt mehrmals erreicht wird, sollte stop_sequence in allen StopTimeUpdates für diese stop_id dieser Fahrt angegeben werden.

Felder

Field Name Type Required Cardinality Description
stop_sequence uint32 Conditionally required One Muss mit stop_times.txt im entsprechenden GTFS-Feed übereinstimmen. In StopTimeUpdate muss entweder stop_sequence oder stop_id gefüllt sein. Es dürfen nicht beide Felder leer sein. stop_sequence ist für Fahrten erforderlich, die mehrmals die gleiche stop_id erreichen (z. B. Rundrouten). Damit lässt sich unterscheiden, auf welche Haltestelle sich die Vorhersage bezieht.
stop_id string Conditionally required One Muss mit stops.txt im entsprechenden GTFS-Feed übereinstimmen. In StopTimeUpdate muss entweder stop_sequence oder stop_id gefüllt sein. Es dürfen nicht beide Felder leer sein.
arrival StopTimeEvent Conditionally required One Wenn schedule_relationship leer oder SCHEDULED ist, muss in StopTimeUpdate entweder arrival oder departure angegeben werden. Es dürfen nicht beide Felder leer sein. arrival und departure können leer sein, wenn schedule_relationship SKIPPED ist. Wenn schedule_relationship NO_DATA ist, müssen arrival und departure leer sein.
departure StopTimeEvent Conditionally required One Wenn schedule_relationship leer oder SCHEDULED ist, muss in StopTimeUpdate entweder arrival oder departure angegeben werden. Es dürfen nicht beide Felder leer sein. arrival und departure können leer sein, wenn schedule_relationship SKIPPED ist. Wenn schedule_relationship NO_DATA ist, müssen arrival und departure leer sein.
schedule_relationship ScheduleRelationship Optional One Die Standardbeziehung ist SCHEDULED.

ScheduleRelationship (Aufzählung)

Die Beziehung zwischen diesem StopTime und dem statischen Fahrplan.

Werte

Value Comment
SCHEDULED Das Fahrzeug fährt die Haltestellen gemäß dem statischen Fahrplan an, wenn auch nicht unbedingt zu den Uhrzeiten, die der Fahrplan vorgibt. Das ist das Standardverhalten. Es muss entweder arrival oder departure angegeben werden.
SKIPPED Die Haltestelle wird ausgelassen, das heißt, das Fahrzeug hält hier nicht. Die Felder arrival und departure sind optional.
NO_DATA Für diese Haltestelle sind keine Daten angegeben. Das bedeutet, dass keine Echtzeitinformationen verfügbar sind. Wenn der Wert festgelegt ist, wird NO_DATA an nachfolgende Haltestellen weitergegeben. Dies ist daher die empfohlene Methode anzugeben, ab welcher Haltestelle Ihnen keine Echtzeitinformationen mehr zur Verfügung stehen. Wenn NO_DATA festgelegt ist, sollte weder arrival noch departure angegeben sein.

VehiclePosition (Nachricht)

Positionsinformationen für ein bestimmtes Fahrzeug in Echtzeit.

Felder

Field Name Type Required Cardinality Description
trip TripDescriptor Optional One Die Fahrt, die mit diesem Fahrzeug durchgeführt wird. Kann leer oder unvollständig sein, wenn das Fahrzeug für eine bestimmte Fahrtinstanz nicht identifiziert werden kann.
vehicle VehicleDescriptor Optional One Zusätzliche Informationen zum Fahrzeug, mit dem diese Fahrt durchgeführt wird. Jeder Eintrag sollte eine eindeutige Fahrzeug-ID haben.
position Position Optional One Die aktuelle Position dieses Fahrzeugs.
current_stop_sequence uint32 Optional One Der Haltestellenabfolgenindex der aktuellen Haltestelle. Die Bedeutung von current_stop_sequence (d. h. die zugehörige Haltestelle) wird durch current_status bestimmt. Wenn current_status fehlt, wird IN_TRANSIT_TO angenommen.
stop_id string Optional One Kennzeichnet die aktuelle Haltestelle. Der Wert muss mit dem in stops.txt im entsprechenden GTFS-Feed übereinstimmen.
current_status VehicleStopStatus Optional One Der genaue Status des Fahrzeugs bezogen auf die aktuelle Haltestelle. Wird ignoriert, wenn current_stop_sequence fehlt.
timestamp uint64 Optional One Zeitpunkt, zu dem die Position des Fahrzeugs erfasst wurde. Es handelt sich um eine POSIX-Zeitangabe, also die Anzahl der Sekunden seit dem 1. Januar 1970 um 00:00 Uhr UTC.
congestion_level CongestionLevel Optional One
occupancy_status OccupancyStatus Optional One Die Fahrgastauslastung des Fahrzeugs.
Hinweis: Dieses Feld ist noch experimentell und kann sich ändern. Es wird unter Umständen künftig offiziell eingeführt.

VehicleStopStatus (Aufzählung)

Werte

Value Comment
INCOMING_AT Das Fahrzeug ist kurz davor, in die Haltestelle einzufahren (auf dem Haltestellendisplay blinkt normalerweise das Fahrzeugsymbol).
STOPPED_AT Das Fahrzeug steht an der Haltestelle.
IN_TRANSIT_TO Das Fahrzeug ist von der vorherigen Haltestelle abgefahren und ist unterwegs.

CongestionLevel (Aufzählung)

Stauneigung, die sich auf dieses Fahrzeug auswirkt

Werte

Value
UNKNOWN_CONGESTION_LEVEL
RUNNING_SMOOTHLY
STOP_AND_GO
CONGESTION
SEVERE_CONGESTION

OccupancyStatus (Aufzählung)

Die Fahrgastauslastung des Fahrzeugs.

Hinweis: Dieses Feld ist noch experimentell und kann sich ändern. Es wird unter Umständen künftig offiziell eingeführt.

Werte

Value Comment
EMPTY Das Fahrzeug wird aufgrund der meisten Messwerte als leer angesehen und hat nur wenige oder keine Fahrgäste. Es können aber noch Fahrgäste zusteigen.
MANY_SEATS_AVAILABLE Im Fahrzeug oder Wagen ist eine große prozentuale Anzahl von Sitzplätzen verfügbar. Ab welchem prozentualen Anteil verfügbarer Sitzplätze diese Kategorie als erfüllt gilt, liegt im Ermessen des Erstellers.
FEW_SEATS_AVAILABLE Im Fahrzeug oder Wagen ist eine kleine prozentuale Anzahl von Sitzplätzen verfügbar. Ab welchem prozentualen Anteil verfügbarer Sitzplätze diese Kategorie als erfüllt gilt, liegt im Ermessen des Erstellers.
STANDING_ROOM_ONLY Im Fahrzeug oder Wagen sind derzeit nur Stehplätze verfügbar.
CRUSHED_STANDING_ROOM_ONLY Im Fahrzeug oder Wagen sind derzeit nur Stehplätze verfügbar und der Platz ist begrenzt.
FULL Das Fahrzeug wird aufgrund der meisten Messwerte als voll angesehen. Unter Umständen können allerdings weiterhin Fahrgäste zusteigen.
NOT_ACCEPTING_PASSENGERS Es können keine weiteren Fahrgäste zusteigen. Normalerweise können Fahrgäste einsteigen.
NO_DATA_AVAILABLE Für das Fahrzeug oder den Wagen sind derzeit keine Auslastungsdaten verfügbar.
NOT_BOARDABLE Das Fahrzeug oder der Wagen ist nicht für Fahrgäste vorgesehen, ein Zustieg ist prinzipiell nicht möglich. Dieser Wert eignet sich für Sonderfahrzeuge oder -wagen (Lokomotive, Wartungswagen usw.).

Alert (Nachricht)

Eine Warnung, die auf einen Vorfall im öffentlichen Nahverkehrsnetz hinweist

Felder

Field Name Type Required Cardinality Description
active_period TimeRange Optional Many Zeit, zu der die Benachrichtigung dem Nutzer präsentiert werden soll. Fehlt diese Angabe, wird die Benachrichtigung angezeigt, solange sie im Feed ist. Wenn mehrere Zeiträume angegeben sind, wird die Benachrichtigung in allen angezeigt.
informed_entity EntitySelector Required Many Entitäten, deren Nutzer diese Benachrichtigung erhalten sollen. Mindestens eine informed_entity muss angegeben werden
cause Cause Optional One
effect Effect Optional One
url TranslatedString Optional One Die URL, über die zusätzliche Informationen zur Benachrichtigung verfügbar sind.
header_text TranslatedString Required One Kopfzeile für die Benachrichtigung. Dieser Nur-Text-String wird hervorgehoben, etwa durch Fettformatierung.
description_text TranslatedString Required One Beschreibung der Benachrichtigung. Dieser Nur-Text-String ist als Haupttext der Benachrichtigung formatiert oder er wird angezeigt, wenn der Nutzer explizit eine Maximierung anfordert. Die Informationen in der Beschreibung müssen die Informationen in der Kopfzeile ergänzen.

Cause (Aufzählung)

Die Ursache dieser Benachrichtigung

Werte

Value
UNKNOWN_CAUSE
OTHER_CAUSE
TECHNICAL_PROBLEM
STRIKE
DEMONSTRATION
ACCIDENT
HOLIDAY
WEATHER
MAINTENANCE
CONSTRUCTION
POLICE_ACTIVITY
MEDICAL_EMERGENCY

Effect (Aufzählung)

Die Auswirkungen dieses Problems auf die betroffene Entität

Werte

Value
NO_SERVICE
REDUCED_SERVICE
SIGNIFICANT_DELAYS
DETOUR
ADDITIONAL_SERVICE
MODIFIED_SERVICE
OTHER_EFFECT
UNKNOWN_EFFECT
STOP_MOVED

TimeRange (Nachricht)

Ein Zeitintervall. Das Intervall wird zum Zeitpunkt t als aktiv betrachtet, wenn t größer oder gleich start und kleiner als end ist.

Felder

Field Name Type Required Cardinality Description
start uint64 Conditionally required One Die Startzeit als POSIX-Zeitangabe, also die Anzahl der Sekunden seit dem 1. Januar 1970 um 00:00:00 (UTC). Fehlt diese Angabe, beginnt das Intervall bei minus unendlich. Wenn ein TimeRange angegeben wird, muss entweder start oder end angegeben werden. Es dürfen nicht beide Felder leer sein.
end uint64 Conditionally required One Die Endzeit als POSIX-Zeitangabe, also die Anzahl der Sekunden seit dem 1. Januar 1970 um 00:00:00 (UTC). Fehlt diese Angabe, endet das Intervall bei plus unendlich. Wenn ein TimeRange angegeben wird, muss entweder start oder end angegeben werden. Es dürfen nicht beide Felder leer sein.

Position (Nachricht)

Eine geografische Position eines Fahrzeugs

Felder

Field Name Type Required Cardinality Description
latitude float Required One Grad nördlicher Breite im WGS-84-Koordinatensystem
longitude float Required One Grad östlicher Länge im WGS-84-Koordinatensystem
bearing float Optional One Ausrichtung in Grad, im Uhrzeigersinn vom geografischen Norden aus gerechnet, d. h., 0 ist Norden und 90 ist Osten. Das kann die Kompasspeilung oder die Richtung sein, in der sich nächste Haltestelle oder der nächste Zwischenpunkt befindet. Dies sollte nicht aus der Abfolge der vorherigen Positionen abgeleitet werden, die Clients anhand vorheriger Daten berechnen können.
odometer double Optional One Wegstreckenzähler (in Metern).
speed float Optional One Aktuelle Geschwindigkeit des Fahrzeugs in Metern pro Sekunde

TripDescriptor (Nachricht)

Eine Beschreibung, die eine einzelne Instanz einer GTFS-Fahrt identifiziert.

Zum Angeben einer einzelnen Fahrtinstanz reicht in vielen Fällen eine trip_id alleine. In den folgenden Fällen sind jedoch zusätzliche Informationen erforderlich, um zu einer einzelnen Fahrtinstanz aufzulösen:

  • Wenn die Fahrt in frequencies.txt definiert ist, sind zusätzlich zu trip_id auch start_date und start_time erforderlich.
  • Wenn die Fahrt länger als 24 Stunden dauert oder so stark verspätet ist, dass sie mit einer geplanten Fahrt am nächsten Tag kollidieren würde, geben Sie sowohl start_date als auch trip_id an.
  • Wenn das Feld trip_id nicht angegeben werden kann, müssen Sie die Felder route_id, direction_id, start_date und start_time angeben.

In allen Fällen gilt: Wenn sowohl die route_id als auch die trip_id angegeben wird, muss die route_id mit dem Feld route_id übereinstimmen, das der angegebenen Fahrt in der GTFS-Datei trips.txt zugewiesen ist.

Das Feld trip_id kann weder allein noch in Kombination mit anderen TripDescriptor-Feldern zur Identifizierung mehrerer Fahrtinstanzen verwendet werden. Wird die TripDescriptor zu null oder mehreren Fahrtinstanzen aufgelöst (statt zu einer einzelnen), wird dies als Fehler betrachtet. Die Entität, die die fehlerhafte TripDescriptor enthält, kann von Nutzern verworfen werden.

Wenn beispielsweise eine Fahrt in der GTFS-Datei frequencies.txt mit exact_times=0 definiert ist, darf in TripDescriptor niemals eine trip_id allein angegeben werden. Grund hierfür ist, dass Sie beim Auflösen einer einzelnen Fahrtinstanz, die zu einer bestimmten Uhrzeit beginnt, auch start_time angeben müssen.

Die Stationsabfolgen-IDs in TripUpdate reichen nicht aus, wenn die trip_id nicht bekannt ist. Zusätzlich müssen stop_id-Felder angegeben werden. Außerdem sind absolute Ankunfts- und Abfahrtszeiten zur Verfügung zu stellen.

Felder

Field Name Type Required Cardinality Description
trip_id string Conditionally required One Die trip_id aus dem GTFS-Feed, auf den sich dieser Selektor bezieht. Ob die trip_id erforderlich ist, hängt vom Typ der Fahrt ab:
• Nicht häufigkeitsbasierte Fahrten: Das Feld trip_id allein reicht aus, um diese Fahrten eindeutig zu identifizieren. Nicht häufigkeitsbasierte Fahrten sind nicht in der GTFS-Datei frequencies.txt definiert.
• Häufigkeitsbasierte Fahrten: Die Felder trip_id, start_time und start_date sind alle erforderlich. Häufigkeitsbasierte Fahrten sind in der GTFS-Datei frequencies.txt definiert.
• Fahrplanbasierte Fahrten: Das Feld trip_id kann nur weggelassen werden, wenn sich die Fahrt anhand einer Kombination aus den angegebenen Feldern route_id, direction_id, start_time und start_date eindeutig identifizieren lässt. Fahrplanbasierte Fahrten sind in der GTFS-Datei frequencies.txt nicht definiert.
route_id string Conditionally required One Die route_id aus dem GTFS-Feed, auf den sich dieser Selektor bezieht. Wenn trip_id weggelassen wird, müssen route_id, direction_id, start_time und schedule_relationship=SCHEDULED festgelegt sein, um eine Fahrtinstanz zu identifizieren.
direction_id uint32 Conditionally required One Die direction_id aus der GTFS-Feeddatei trips.txt, die die Richtung angibt. Wenn trip_id weggelassen wird, muss direction_id angegeben werden.
Hinweis: Dieses Feld ist noch experimentell und kann sich ändern. Es wird unter Umständen künftig offiziell eingeführt.
start_time string Conditionally required One Die ursprünglich geplante Startzeit für diese Fahrtinstanz. Mit dem Feldtyp Time wird das Format des Feldes definiert, etwa 11 : 15 : 35 oder 25 : 15 : 35. Ob das Feld start_time erforderlich ist, hängt vom Typ der Fahrt ab:
• Die trip_id entspricht einer nicht häufigkeitsbasierten Fahrt: Das Feld start_time muss entweder weggelassen werden oder dem Wert von departure_time in der Datei stop_times.txt des GTFS-Feeds entsprechen.
• Die trip_id entspricht einer häufigkeitsbasierten Fahrt: start_time ist immer erforderlich und muss für Updates zu Fahrten und Fahrzeugpositionen angegeben werden. Häufigkeitsbasierte Fahrten sind in der GTFS-Datei frequencies.txt definiert.
◦ Wenn die häufigkeitsbasierte Fahrt einem GTFS-Datensatz vom Typ exact_times=1 entspricht: Das Feld start_time muss ein Vielfaches (einschließlich 0) von headway_secs nach der start_time (frequencies.txt) für den entsprechenden Zeitraum enthalten.
◦ Wenn die häufigkeitsbasierte Fahrt einem exact_times=0-GTFS-Datensatz entspricht: Die start_time kann beliebig sein und wird anfangs als erste Abfahrt der Fahrt erwartet. Nachdem dieser Wert festgelegt wurde, wird die start_time für diese häufigkeitsbasierte exact_times=0-Fahrt als unveränderlich angesehen, auch wenn sich die erste Abfahrtszeit ändert. Nachfolgende Zeitänderungen können stattdessen in einer StopTimeUpdate-Nachricht widergespiegelt werden.
• Die trip_id wird ausgelassen: Die start_time muss angegeben werden.
start_date string Conditionally required One Das Startdatum dieser Fahrtinstanz im Format YYYYMMDD. Ob start_date erforderlich ist, hängt vom Typ der Fahrt ab:
• Geplante Fahrten: start_date muss angegeben werden. Damit sollen Fahrten unterschieden werden, die so stark verspätet sind, dass sie mit einer geplanten Fahrt am nächsten Tag kollidieren. Beispiel: Ein Zug fährt täglich um 8:00 Uhr und 20:00 Uhr. Hat dieser Zug nun 12 Stunden Verspätung, wären zwei unterschiedliche Fahrten für dieselbe Zeit geplant.
Hinweis: Dieses Feld ist für geplante Fahrten, bei denen solche Konflikte nicht möglich sind, optional. Das ist zum Beispiel der Fall, wenn ein Dienst in einem stündlichen Takt verkehrt und ein Fahrzeug, das eine Stunde zu spät fährt, als nicht mehr relevant für den Fahrplan gilt.
• Häufigkeitsbasierte Fahrten: start_date muss angegeben werden. Häufigkeitsbasierte Fahrten sind in der GTFS-Datei frequencies.txt definiert, geplante Fahrten jedoch nicht.
• trip_id wird ausgelassen: start_date muss angegeben werden.
schedule_relationship ScheduleRelationship Optional One Die Beziehung zwischen dieser Fahrt und dem statischen Fahrplan. Wenn die TripDescriptor in einem Alert vom Typ EntitySelector enthalten ist, wird das Feld schedule_relationship von Nutzern ignoriert, wenn sie die entsprechende Fahrtinstanz identifizieren.

ScheduleRelationship (Aufzählung)

Die Beziehung zwischen dieser Fahrt und dem statischen Fahrplan. Wenn eine Fahrt gemäß einem vorübergehenden Fahrplan durchgeführt wird und nicht in GTFS dargestellt wird, sollte sie nicht als SCHEDULED, sondern als ADDED gekennzeichnet werden.

Werte

Value Comment
SCHEDULED Fahrt, die gemäß GTFS-Fahrplan durchgeführt wird oder nah genug an der geplanten Fahrt ist, um mit ihr verbunden zu werden
ADDED Eine Extrafahrt, die zusätzlich zu einem aktiven Fahrplan hinzugefügt wurde, etwa um ein ausgefallenes Fahrzeug zu ersetzen oder auf plötzliche Auslastungsspitzen zu reagieren
UNSCHEDULED Eine Fahrt, die stattfindet, aber keinem Fahrplan zugewiesen ist. Mit diesem Wert werden Fahrten identifiziert, die in der GTFS-Datei frequencies.txt mit exact_times = 0 definiert sind. Der Wert sollte nicht zur Beschreibung von Fahrten verwendet werden, die nicht in der GTFS-Datei frequencies.txt definiert sind, oder zur Beschreibung von Fahrten, die mit exact_times = 1 in der GTFS-Datei frequencies.txt enthalten sind.
CANCELED Eine Fahrt, die im Fahrplan war, aber entfernt wurde

VehicleDescriptor (Nachricht)

Informationen zur Identifikation des Fahrzeugs, das die Fahrt durchführt

Felder

Field Name Type Required Cardinality Description
id string Optional One Systeminterne ID des Fahrzeugs. Sie muss für jedes Fahrzeug eindeutig sein und wird zum Nachverfolgen des Fahrzeugs im System verwendet. Diese ID sollte für den Endnutzer nicht sichtbar sein. Verwenden Sie daher das Feld label.
label string Optional One Für den Nutzer sichtbares Label, also Informationen, die dem Fahrgast präsentiert werden müssen, damit er das richtige Fahrzeug identifizieren kann.
license_plate string Optional One Das Kennzeichen des Fahrzeugs

EntitySelector (Nachricht)

Ein Selektor für eine Entität in einem GTFS-Feed. Die Werte der Felder müssen mit den entsprechenden Feldern im GTFS-Feed übereinstimmen. Es muss mindestens ein Spezifizierer angegeben werden. Wenn mehrere vorhanden sind, sollten sie als vom logischen AND-Operator verknüpft interpretiert werden. Außerdem muss die Kombination der Spezifizierer mit den entsprechenden Informationen im GTFS-Feed übereinstimmen. Damit einer Entität in GTFS eine Benachrichtigung zugewiesen werden kann, muss sie mit allen bereitgestellten EntitySelector-Feldern übereinstimmen. Beispielsweise gilt eine EntitySelector mit den Feldern route_id: "5" und route_type: "3" nur für den Bus route_id: "5", nicht aber für andere Routen in route_type: "3". Wenn eine Benachrichtigung sowohl für route_id: "5" als auch für route_type: "3" zugewiesen werden soll, sollte der Ersteller zwei separate EntitySelector-Felder angeben ‒ das eine verweist dabei auf route_id: "5" und das andere auf route_type: "3".

Es muss mindestens ein Spezifizierer angegeben werden. Es dürfen nicht alle Felder in einer EntitySelector leer sein.

Felder

Field Name Type Required Cardinality Description
agency_id string Conditionally required One Die agency_id aus dem GTFS-Feed, auf den sich dieser Selektor bezieht.
route_id string Conditionally required One Die route_id aus der GTFS, auf die sich dieser Selektor bezieht. Wenn direction_id angegeben ist, muss auch route_id angegeben werden.
route_type int32 Conditionally required One Die route_type aus der GTFS, auf die sich dieser Selektor bezieht.
direction_id uint32 Conditionally required One Die direction_id aus dem GTFS-Feed trips.txt, mit dem alle Fahrten in eine Richtung für eine Route ausgewählt werden, angegeben durch route_id. Wenn direction_id angegeben ist, muss auch route_id angegeben werden.
trip TripDescriptor Conditionally required One Die Fahrtinstanz aus der GTFS, auf die sich der Selektor bezieht. Dieser TripDescriptor muss in einer einzelnen Fahrtinstanz in den GTFS-Daten aufgelöst werden. Zum Beispiel kann ein Ersteller nicht nur einen trip_id für exact_times=0-Fahrten angeben. Wenn das Feld ScheduleRelationship in diesem TripDescriptor ausgefüllt ist, wird es von der verarbeitenden Anwendung beim Identifizieren der GTFS-Fahrt ignoriert.
stop_id string Conditionally required One Die stop_id aus dem GTFS-Feed, auf den sich dieser Selektor bezieht.

TranslatedString (Nachricht)

Eine internationalisierte Nachricht mit den sprachspezifischen Versionen eines Text-Snippets oder einer URL. Einer der Strings aus einer Nachricht wird ausgewählt. Die Auflösung funktioniert so: Wenn die Sprache der Benutzeroberfläche mit dem Sprachcode einer Übersetzung übereinstimmt, wird die erste übereinstimmende Übersetzung ausgewählt. Wenn eine Standardsprache der Benutzeroberfläche (z. B. Englisch) mit dem Sprachcode einer Übersetzung übereinstimmt, wird die erste übereinstimmende Übersetzung ausgewählt. Wenn eine Übersetzung einen nicht spezifizierten Sprachcode hat, wird diese Übersetzung ausgewählt.

Felder

Field Name Type Required Cardinality Description
translation Translation Required Many Es muss mindestens eine Übersetzung angegeben werden.

Translation (Nachricht)

Ein lokalisierter String, der einer Sprache zugeordnet ist

Felder

Field Name Type Required Cardinality Description
text string Required One Ein UTF-8-String mit der Nachricht
language string Conditionally required One Der BCP-47-Sprachcode. Er kann weggelassen werden, wenn die Sprache unbekannt ist oder der Feed nicht internationalisiert wird. Maximal eine Übersetzung darf ein nicht spezifiziertes Sprach-Tag haben. Wenn es mehr als eine Übersetzung gibt, muss die Sprache angegeben werden.