GTFS Realtime Referenz

Mit einem GTFS Realtime Realtime-Feed können Verkehrsunternehmen ihre Kunden in Echtzeit über Störungen ihres Dienstes (geschlossene Bahnhöfe, ausgefallene Linien, große Verspätungen usw.), den Standort ihrer Fahrzeuge und die voraussichtlichen arrival informieren.

Die Version 2.0 der Feed-Spezifikation wird auf dieser Website diskutiert und dokumentiert. Gültige Versionen sind "2.0", "1.0".

Begriffsdefinitionen

Erforderlich

In GTFS v2.0 und höher beschreibt die Spalte Erforderlich, welche Felder von einem Produzenten zur Verfügung gestellt werden müssen, damit die Verkehrsdaten gültig und für eine konsumierende Anwendung sinnvoll sind.

Die folgenden Werte werden im Feld " Erforderlich" verwendet:

• Erforderlich: Dieses Feld muss von einem GTFS bereitgestellt werden.
• Bedingt erforderlich: Dieses Feld ist unter bestimmten Bedingungen erforderlich, die in der Feldbeschreibung aufgeführt sind. Außerhalb dieser Bedingungen ist das Feld optional.
• Wahlweise: Dieses Feld ist optional und muss von den Produzenten nicht implementiert werden. Wenn die Daten jedoch in den zugrundeliegenden automatischen vehicle verfügbar sind (z. B. VehiclePosition timestamp), wird empfohlen, dass die Hersteller diese optionalen Felder nach Möglichkeit bereitstellen.

Beachten Sie, dass die semantischen Anforderungen in GTFS 1.0 nicht definiert wurden und daher Feeds mit gtfs_realtime_version von 1 diese Anforderungen möglicherweise nicht erfüllen (siehe den Vorschlag für semantische Anforderungen für weitere Einzelheiten).

Kardinalität

DieKardinalität gibt die Anzahl der Elemente an, die für ein bestimmtes Feld bereitgestellt werden können, wobei die folgenden Werte gelten:

• One - Für dieses Feld kann ein einzelnes One-Element angegeben werden. Dies entspricht den erforderlichen und optionalen Kardinalitäten des Protokollpuffers.
• Viele - Für dieses Feld können viele Elemente (0, 1 oder mehr) angegeben werden. Dies entspricht der wiederholten Kardinalität des Protokollpuffers.

Verweisen Sie immer auf die Felder Erforderlich und Beschreibung, um zu sehen, ob ein Feld erforderlich, bedingt erforderlich oder optional ist. Für die Kardinalität des Protokollpuffers verweisen Sie bitte auf GTFS-realtime/proto/GTFS-realtime.proto">GTFS.proto.

Protokollpuffer-Datentypen

Die folgenden Protokollpuffer-Datentypen werden zur Beschreibung von Feed-Elementen verwendet:

• message: Komplexer Typ
• enum: Liste von Festwerten

Experimentelle Felder

Felder, die als experimentell gekennzeichnet sind, unterliegen Änderungen und sind noch nicht offiziell in die Spezifikation aufgenommen worden. Ein experimentelles Feld kann in der Zukunft formell angenommen werden.

Element-Index

• FeedMessage
  • FeedHeader
    • Incrementality
  • FeedEntity
    • TripUpdate
      • TripDescriptor
        • ScheduleRelationship
      • VehicleDescriptor
      • StopTimeUpdate
        • StopTimeEvent
        • ScheduleRelationship
        • StopTimeProperties
      • TripProperties
    • VehiclePosition
      • TripDescriptor
        • ScheduleRelationship
      • VehicleDescriptor
      • Position
      • VehicleStopStatus
      • CongestionLevel
      • OccupancyStatus
      • CarriageDetails
    • Alert
      • TimeRange
      • EntitySelector
        • TripDescriptor
          • ScheduleRelationship
      • Cause
      • Effect
      • TranslatedString
        • Translation
      • SeverityLevel

Elemente

message FeedMessage

Der Inhalt einer message. Jede message im Stream wird als Antwort auf eine entsprechende HTTP-GET-Anfrage erhalten. Ein Echtzeit-Feed wird immer mit Bezug auf einen bestehenden GTFS definiert. Alle entity werden in Bezug auf den GTFS aufgelöst.

Felder

Feldname	Typ	Erforderlich	Kardinalität	Beschreibung
header	FeedHeader	Erforderlich	Eine	Metadaten zu diesem Feed und der message.
entity	FeedEntity	Bedingt erforderlich	Viele	Inhalt des Feeds. Wenntime für das Versandverfahren verfügbar sind, muss dieses Feld angegeben werden. Wenn dieses Feld EMPTY ist, sollten die Verbraucher davon ausgehen, dass keinetime für das System verfügbar sind.

message FeedHeader

Metadaten zu einem Feed, die in Feed-Nachrichten enthalten sind.

Felder

Feldname	Typ	Erforderlich	Kardinalität	Beschreibung
gtfs_realtime_version	string	Erforderlich	Eine	Version der Feed-Spezifikation. Die aktuelle Version ist 2.0.
Incrementality	Incrementality	Erforderlich	Eine
timestamp	uint64	Erforderlich	Eine	Dieser timestamp gibt den Zeitpunkt an, zu dem der Inhalt dieses Feeds erstellt wurde (in time). In time (d. h. die Anzahl der Sekunden seit dem 1. Januar 1970 00:00:00 UTC). Um time zwischen Systemen zu vermeiden, die Echtzeitinformationen produzieren und konsumieren, wird dringend empfohlen, den timestamp von einem time abzuleiten. Die Verwendung von Servern der Schicht 3 oder noch niedrigerer Schichten ist völlig akzeptabel, da time von bis zu einigen Sekunden tolerierbar sind.

enum Incrementality

Legt fest, ob der aktuelle Abruf inkrementell ist.

• FULL_DATASET: Diese Feed-Aktualisierung überschreibt alle vorangegangenen Echtzeitinformationen für den Feed. Daher wird erwartet, dass diese Aktualisierung einen FULL Schnappschuss aller bekannten Echtzeitinformationen liefert.
• DIFFERENTIAL: Derzeit wird dieser Modus nicht unterstützt und das Verhalten ist für Feeds, die diesen Modus verwenden, nicht spezifiziert. Auf der GTFS-realtime">GTFS Realtime Realtime-Mailingliste wird diskutiert, wie das Verhalten des DIFFERENTIAL vollständig spezifiziert werden kann, und die Dokumentation wird aktualisiert, sobald diese Diskussionen abgeschlossen sind.

Werte

Wert
FULL_DATASET
DIFFERENTIAL

message FeedEntity

Eine Definition (oder Aktualisierung) einer entity im Transit-Feed. Wenn die entity nicht gelöscht wird, sollte genau eines der Feldertrip_update",vehicle",Alert" undShape" ausgefüllt werden.

Felder

Feldname	Typ	Erforderlich	Kardinalität	Beschreibung
id	string	Erforderlich	Eine	Feed-unique identifier für diese entity. Die IDs werden nur zur Unterstützung der Incrementality verwendet. Die tatsächlichen Entitäten, auf die der Feed verweist, müssen durch explizite Selektoren angegeben werden (siehe EntitySelector weiter unten für weitere INFO).
is_deleted	bool	Optional	Eine	Angabe, ob diese entity gelöscht werden soll. Sollte nur für Feeds mit der Incrementality DIFFERENTIAL angegeben werden - dieses Feld sollte NICHT für Feeds mit der Incrementality FULL_DATASET angegeben werden.
trip_update	TripUpdate	Bedingt erforderlich	Eine	Daten über die departure einer trip. Mindestens eines der Felder trip_update, vehicle, Alert oder Shape muss angegeben werden - alle diese Felder dürfen nicht EMPTY sein.
vehicle	VehiclePosition	Bedingt erforderlich	Eine	Daten über die Position eines vehicle. Mindestens eines der Felder trip_update, vehicle, Alert oder Shape muss angegeben werden - alle diese Felder dürfen nicht EMPTY sein.
Alert	Alert	Bedingt erforderlich	Eine	Daten über die Alert. Mindestens eines der Felder trip_update, vehicle, Alert oder Shape muss angegeben werden - alle diese Felder dürfen nicht EMPTY sein.
Shape	Shape	Bedingt erforderlich	Eine	Daten über die in Echtzeit ADDED Shapes, z. B. für eine DETOUR. Mindestens eines der Felder trip_update, vehicle, Alert oder Shape muss angegeben werden - alle diese Felder dürfen nicht EMPTY sein. Vorsicht! dieses Feld ist noch experimentellund kann sich ändern. Sie kann in der Zukunft formell angenommen werden.

message TripUpdate

Echtzeit-Aktualisierung des Fortschritts eines vehicle auf einer trip. Bitte beachten Sie auch die allgemeine Diskussion über die trip-updates">Entitäten zur Aktualisierung vontrip.

Je nach dem Wert von ScheduleRelationship kann ein TripUpdate angeben:

• Eine trip, die entlang des Fahrplans verläuft.
• Eine trip, die entlang einer Route verläuft, aber keinen festen Fahrplan hat.
• Eine trip, die in Bezug auf den Fahrplan ADDED oder entfernt wurde.
• Eine neue trip, die eine Kopie einer bestehenden trip im statischen GTFS ist. Sie wird zu dem in TripProperties angegebenen Servicedatum und der dort angegebenen time durchgeführt.

Die Aktualisierungen können sich auf zukünftige, vorhergesagte arrival oder auf vergangene, bereits eingetretene Ereignisse beziehen. In den meisten Fällen handelt es sich bei den Informationen über vergangene Ereignisse um einen gemessenen Wert, so dass empfohlen wird, dass der uncertainty 0 ist. Es kann jedoch Fälle geben, in denen dies nicht zutrifft, so dass für vergangene Ereignisse ein von 0 abweichender uncertainty zulässig ist. Ist der uncertainty einer Aktualisierung nicht 0, handelt es sich entweder um eine ungefähre Vorhersage für eine trip, die noch nicht abgeschlossen ist, oder die Messung ist nicht präzise, oder die Aktualisierung war eine Vorhersage für die Vergangenheit, die nach dem Eintreten des Ereignisses nicht überprüft wurde.

Wenn ein vehicle mehrere Fahrten innerhalb desselben Blocks bedient (weitere Informationen über Fahrten und Blöcke finden Sie in GTFS trips.txt):

• sollte der Feed ein TripUpdate für die trip enthalten, die gerade von dem vehicle bedient wird. Die Produzenten werden ermutigt, TripUpdates für eine oder mehrere Fahrten nach der aktuellen trip in den Block dieses vehicle aufzunehmen, wenn der Produzent von der Qualität der Vorhersagen für diese zukünftige(n) trip(en) überzeugt ist. Durch die Aufnahme mehrerer TripUpdates für dasselbe vehicle wird vermieden, dass die Vorhersagen für die Fahrgäste beim Übergang von einer trip zu einer anderen "aufpoppen" und dass die Fahrgäste im Voraus über Verspätungen informiert werden, die sich auf nachfolgende Fahrten auswirken (z. B. wenn die bekannte delay die geplanten Wartezeiten zwischen den Fahrten überschreitet).
• Die jeweiligen TripUpdate müssen nicht in der Reihenfolge, in der sie im Block SCHEDULED sind, zum Feed ADDED werden. Wenn es beispielsweise Fahrten mit den trip_ids 1, 2 und 3 gibt, die alle zu einem Block gehören, und das vehicle fährt zuerst die trip 1, dann die trip 2 und dann die trip 3, können die trip_update in beliebiger Reihenfolge erscheinen - zum Beispiel ist das Hinzufügen der trip 2, dann der trip 1 und dann der trip 3 zulässig.

Es ist zu beachten, dass die Aktualisierung eine bereits abgeschlossene trip beschreiben kann; zu diesem end reicht es aus, eine Aktualisierung für den letzten Halt der trip zu liefern. Wenn die arrival an der letzten Haltestelle in der Vergangenheit liegt, schließt der Kunde daraus, dass die gesamte trip in der Vergangenheit liegt (es ist möglich, wenn auch unwichtig, auch Aktualisierungen für vorhergehende Haltestellen zu liefern). Diese Option ist vor allem für eine trip relevant, die vorzeitig beendet wurde, trip aber laut Fahrplan zum aktuellen time noch andauert. Das Entfernen der Aktualisierungen für diese trip könnte dazu führen, dass der Kunde annimmt, die trip sei noch im Gange. Beachten Sie, dass der Feed-Anbieter vergangene Aktualisierungen löschen darf, aber nicht muss - dies ist ein Fall, in dem dies praktisch nützlich wäre.

Felder

Feldname	Typ	Erforderlich	Kardinalität	Beschreibung
trip	TripDescriptor	Erforderlich	Eine	Die trip, für die diese message gilt. Es kann höchstens eine entity für jede tatsächliche trip geben. Wenn es keine gibt, bedeutet dies, dass keine Vorhersageinformationen verfügbar sind. Es bedeutet nicht bedeutet, dass die trip planmäßig verläuft.
vehicle	VehicleDescriptor	Optional	Eine	Zusätzliche Informationen über das vehicle, das für diese trip eingesetzt wird.
stop_time_update	StopTimeUpdate	Bedingt erforderlich	Viele	Aktualisierungen der Haltestellenzeiten für die trip (sowohl zukünftige, d. h. Vorhersagen, als auch in einigen Fällen vergangene, d. h. bereits erfolgte). Die Aktualisierungen müssen nach stop_sequence sortiert sein und für alle folgenden Haltestellen der trip bis zum nächsten angegebenen stop_time_update gelten. Es muss mindestens eine stop_time_update für die trip angegeben werden, es sei denn, die trip.schedule_relationship ist CANCELED oder DUPLICATED - ist die trip CANCELED, müssen keine stop_time_updates angegeben werden. Wenn die trip DUPLICATED ist, können stop_time_updates bereitgestellt werden, umtime für die neue trip anzuzeigen.
timestamp	uint64	Optional	Eine	Der jüngste Zeitpunkt, zu dem dertime des vehicle gemessen wurde, um die Stoppzeiten für die Zukunft zu schätzen. Wenn Haltestellenzeiten in der Vergangenheit angegeben werden, können die arrival früher als dieser Wert liegen. In time (d. h. die Anzahl der Sekunden seit dem 1. Januar 1970 00:00:00 UTC).
delay	int32	Optional	Eine	Die aktuelle Fahrplanabweichung für die trip. delay sollte nur angegeben werden, wenn die Vorhersage relativ zu einem bestehenden Fahrplan in GTFS gegeben wird. Diedelay (in Sekunden) kann positiv (d. h., das vehicle ist verspätet) oder negativ (d. h., das vehicle ist dem Fahrplan voraus) sein. Eine delay von 0 bedeutet, dass das vehicle genau time ist. delay in StopTimeUpdates haben Vorrang vor delay trip, so dass delay trip nur bis zur nächsten Haltestelle entlang der trip mit einem angegebenen delay weitergegeben werden. Feed-Anbietern wird dringend empfohlen, einen TripUpdate.timestamp anzugeben, der angibt, wann der delay zuletzt aktualisiert wurde, um die Aktualität der Daten zu bewerten. Vorsicht! dieses Feld ist noch experimentellund kann sich ändern. Sie kann in der Zukunft formell angenommen werden.
trip_properties	TripProperties	Optional	Eine	Liefert die aktualisierten Eigenschaften für die trip. Vorsicht! diese message ist noch experimentellund kann sich ändern. Sie kann in der Zukunft formell angenommen werden.

message StopTimeEvent

Zeitangaben für ein einzelnes vorhergesagtes Ereignis (entweder arrival oder departure). Die Zeitangabe besteht aus der delay und/oder der geschätzten time und der uncertainty.

• delay sollte verwendet werden, wenn die Vorhersage relativ zu einem bestehenden Zeitplan in GTFS gegeben wird.
• Dietime sollte unabhängig davon angegeben werden, ob es einen vorausgesagten Fahrplan gibt oder nicht. Wenn sowohl time als auch delay angegeben werden, hat die time Vorrang (obwohl normalerweise die time, wenn sie für eine SCHEDULED trip angegeben wird, gleich der SCHEDULED time in GTFS + delay sein sollte).

gilt dieuncertainty gleichermaßen für time und delay. Die uncertainty gibt grob den erwarteten Fehler bei der tatsächlichen delay an (aber beachten Sie, dass wir ihre genaue statistische Bedeutung noch nicht definiert haben). Es ist möglich, dass die uncertainty 0 ist, z. B. bei Zügen, die von einem Computer gesteuert werden.

Felder

Feldname	Typ	Erforderlich	Kardinalität	Beschreibung
delay	int32	Bedingt erforderlich	Eine	Diedelay (in Sekunden) kann positiv sein (was bedeutet, dass das vehicle Verspätung hat) oder negativ (was bedeutet, dass das vehicle dem Zeitplan voraus ist). Eine delay von 0 bedeutet, dass das vehicle genau time ist. In einem StopTimeEvent muss entweder die delay oder die time angegeben werden - beide Felder dürfen nicht EMPTY sein.
time	int64	Bedingt erforderlich	Eine	Ereignis als absolute time. In time (d. h. die Anzahl der Sekunden seit dem 1. Januar 1970 00:00:00 UTC). In einem StopTimeEvent muss entweder delay oder time angegeben werden - beide Felder dürfen nicht EMPTY sein.
uncertainty	int32	Optional	Eine	Wenn die uncertainty nicht angegeben wird, wird sie als unbekannt interpretiert. Um eine völlig sichere Vorhersage anzugeben, setzen Sie die uncertainty auf 0.

message StopTimeUpdate

Echtzeitaktualisierung von arrival und/oder departure für eine bestimmte Haltestelle auf einer trip. Bitte beachten Sie auch die allgemeine Diskussion über die Aktualisierung von time in der Dokumentation message-tripdescriptor">TripDescriptor und trip-updates">trip Updates Entities.

Aktualisierungen können sowohl für vergangene als auch für zukünftige Ereignisse angegeben werden. Der Produzent darf, muss aber nicht, vergangene Ereignisse auslassen.

Die Aktualisierung ist entweder über stop_sequence oder stop_id mit einer bestimmten Haltestelle verknüpft, so dass eines dieser Felder unbedingt gesetzt sein muss. Wird dieselbe stop_id mehr als einmal während einer trip angefahren, so sollte stop_sequence in allen StopTimeUpdates für diese stop_id auf dieser trip angegeben werden.

Felder

Feldname	Typ	Erforderlich	Kardinalität	Beschreibung
stop_sequence	uint32	Bedingt erforderlich	Eine	Muss dieselbe sein wie in stop_times.txt im entsprechenden GTFS. Entweder stop_sequence oder stop_id müssen in einem StopTimeUpdate angegeben werden - beide Felder dürfen nicht EMPTY sein. stop_sequence ist für Fahrten erforderlich, die dieselbe stop_id mehr als einmal anfahren (z. B. eine Schleife), um zu unterscheiden, für welche Haltestelle die Vorhersage gilt. Wenn StopTimeProperties.assigned_stop_id ausgefüllt ist, dann stop_sequence ausgefüllt werden.
stop_id	string	Bedingt erforderlich	Eine	Muss dieselbe sein wie in stops.txt im entsprechenden GTFS. Entweder stop_sequence oder stop_id müssen in einem StopTimeUpdate angegeben werden - beide Felder dürfen nicht EMPTY sein. Wenn StopTimeProperties.assigned_stop_id ausgefüllt ist, ist es vorzuziehen, das Feld stop_id und verwenden Sie nur stop_sequence. Wenn StopTimeProperties.assigned_stop_id und stop_id ausgefüllt werden, stop_id muss übereinstimmen assigned_stop_id.
arrival	StopTimeEvent	Bedingt erforderlich	Eine	Wenn schedule_relationship EMPTY oder SCHEDULED ist, muss entweder arrival oder departure in einem StopTimeUpdate angegeben werden - beide Felder können nicht EMPTY sein. arrival und departure können beide EMPTY sein, wenn schedule_relationship SKIPPED ist. Wenn schedule_relationship NO_DATA ist, müssen arrival und departure EMPTY sein.
departure	StopTimeEvent	Bedingt erforderlich	Eine	Wenn schedule_relationship EMPTY oder SCHEDULED ist, muss entweder arrival oder departure innerhalb eines StopTimeUpdate angegeben werden - beide Felder können nicht EMPTY sein. arrival und departure können beide EMPTY sein, wenn schedule_relationship SKIPPED ist. Wenn schedule_relationship NO_DATA ist, müssen arrival und departure EMPTY sein.
departure_occupancy_status	OccupancyStatus	Optional	Eine	Der voraussichtliche Belegungsstatus des vehicle unmittelbar nach departure von der angegebenen Haltestelle. Falls vorhanden, muss stop_sequence angegeben werden. Um departure_occupancy_status ohne arrival oder departure anzugeben, ist dieses Feld auszufüllen und StopTimeUpdate zu setzen.schedule_relationship = NO_DATA. Vorsicht! dieses Feld ist noch experimentellund kann sich ändern. Sie kann in der Zukunft formell angenommen werden.
schedule_relationship	ScheduleRelationship	Optional	Eine	Die Standardbeziehung ist SCHEDULED.
stop_time_properties	StopTimeProperties	Optional	Eine	Echtzeit-Updates für bestimmte in GTFS stop_times.txt definierte Eigenschaften Vorsicht! dieses Feld ist noch experimentellund kann sich ändern. Sie kann in der Zukunft formell angenommen werden.

enum ScheduleRelationship

Die Beziehung zwischen dieser StopTime und dem statischen Zeitplan.

Werte

Wert	Kommentar
SCHEDULED	Das vehicle fährt nach seinem statischen Zeitplan für Haltestellen, wenn auch nicht unbedingt nach den Zeiten des Zeitplans. Dies ist die Voreinstellung Verhalten. Es muss mindestens eine der arrival und departure angegeben werden. Frequenzbasierte FahrtenGTFS frequencies.txt mit exact_times = 0) sollten keinen SCHEDULED haben und stattdessen UNSCHEDULED verwenden.
SKIPPED	Die Haltestelle wird SKIPPED, d. h. das vehicle hält nicht an dieser Haltestelle. arrival und departure sind optional. Wenn gesetzt SKIPPED nicht auf nachfolgende Haltestellen derselben trip übertragen (d. h. das vehicle hält an den nachfolgenden Haltestellen der trip an, es sei denn, diese Haltestellen haben ebenfalls eine stop_time_update mit schedule_relationship: SKIPPED). delay von einem vorherigen Halt in der trip hat über die Haltestelle SKIPPED Haltestelle. Mit anderen Worten: Wenn eine stop_time_update mit einer arrival oder departure Vorhersage nicht für eine Haltestelle nach der SKIPPED nicht gesetzt ist, wird die Vorhersage vor der SKIPPED Haltestelle auf die Haltestelle nach der SKIPPED Haltestelle und die nachfolgenden Haltestellen der trip übertragen, bis eine stop_time_update für eine nachfolgende Haltestelle gegeben ist.
NO_DATA	Für diese Haltestelle sind keine Daten angegeben. Dies bedeutet, dass keine Echtzeit-Zeitinformationen verfügbar sind. Wenn NO_DATA gesetzt ist, werden die Daten über die nachfolgenden Haltestellen weitergegeben, so dass dies der empfohlene Weg ist, um anzugeben, ab welcher Haltestelle keine Echtzeit-Zeitinformationen vorliegen. Wenn NO_DATA gesetzt ist, sollte weder die arrival noch die departure angegeben werden.
UNSCHEDULED	Das vehicle fährt eine frequenzbasierte tripGTFS frequencies.txt mit exact_times = 0). Dieser Wert sollte nicht für Fahrten verwendet werden, die nicht in GTFS frequencies.txt definiert sind, oder für Fahrten in GTFS frequencies.txt mit exact_times = 1. Fahrten, die stop_time_updates mit schedule_relationship: UNSCHEDULED definiert sind, müssen auch den TripDescriptor schedule_relationship: UNSCHEDULED Vorsicht! dieses Feld ist noch experimentellund kann sich ändern. Sie kann in der Zukunft formell angenommen werden.

message StopTimeProperties

Echtzeit-Aktualisierung für bestimmte in GTFS stop_times.txt definierte Eigenschaften.

Achtung: Diese message ist noch experimentell und kann geändert werden. Sie kann in Zukunft formell angenommen werden.

Felder

Feldname	Typ	Erforderlich	Kardinalität	Beschreibung
assigned_stop_id	string	Optional	Eine	Unterstützt die Zuweisung von Haltestellentime. Bezieht sich auf eine stop_id die im GTFS definiert ist. stops.txt. Die neue assigned_stop_id sollte für den end nicht zu einem signifikant anderen trip führen als der stop_id definiert in GTFS stop_times.txt. Mit anderen Worten, der end sollte diese neue Haltestelle nicht als stop_id als "ungewöhnliche Änderung", wenn die neue Haltestelle in einer App ohne zusätzlichen Kontext angezeigt wurde. Dieses Feld ist zum Beispiel für Bahnsteigzuweisungen gedacht, indem es ein stop_id die zum gleichen Bahnhof gehört wie die ursprünglich im GTFS definierte Haltestelle stop_times.txt. Um eine Haltestelle zuzuweisen, ohne arrival oder departure zu liefern, füllen Sie dieses Feld aus und setzen Sie StopTimeUpdate.schedule_relationship = NO_DATA. Wenn dieses Feld ausgefüllt ist, StopTimeUpdate.stop_sequence muss ausgefüllt werden und StopTimeUpdate.stop_id sollte nicht ausgefüllt werden. Haltestellenzuweisungen sollten sich auch in anderen GTFS widerspiegeln (z. B, VehiclePosition.stop_id). Vorsicht! dieses Feld ist noch experimentellund kann sich ändern. Sie kann in der Zukunft formell angenommen werden.

message TripProperties

Definiert die aktualisierten Eigenschaften der trip

Achtung: Diese message ist noch experimentell und kann sich noch ändern. Sie kann in der Zukunft formell angenommen werden.
.

Felder

Feldname	Typ	Erforderlich	Kardinalität	Beschreibung
trip_id	string	Bedingt erforderlich	Eine	Definiert den Bezeichner einer neuen trip, die ein Duplikat einer bestehenden trip ist, die in (CSV) GTFS trips.txt definiert ist, aber zu einem anderen Abfahrtsdatum und/oder einer anderen time start (definiert durch TripProperties.start_date und TripProperties.start_time). Siehe Definition von trips.trip_id in (CSV) GTFS. Sein Wert muss sich von den in (CSV) GTFS verwendeten Werten unterscheiden. Dieses Feld ist erforderlich, wenn schedule_relationship ist DUPLICATEDAndernfalls darf dieses Feld nicht ausgefüllt werden und wird von den Verbrauchern ignoriert. Vorsicht! dieses Feld ist noch experimentellund kann sich ändern. Sie kann in der Zukunft formell angenommen werden.
start_date	string	Bedingt erforderlich	Eine	Leistungsdatum, an dem die DUPLICATED trip durchgeführt wird. Muss im Format JJJJMMTT angegeben werden. Dieses Feld ist erforderlich, wenn schedule_relationship ist DUPLICATEDAndernfalls darf dieses Feld nicht ausgefüllt werden und wird von den Verbrauchern ignoriert. Vorsicht! dieses Feld ist noch experimentellund kann sich ändern. Sie kann in der Zukunft formell angenommen werden.
start_time	string	Bedingt erforderlich	Eine	Definiert die time der trip, wenn sie DUPLICATED ist. Siehe Definition von stop_times.departure_time in (CSV) GTFS. Die arrival und departure für die trip werden auf der Grundlage des Offsets zwischen der ursprünglichen trip departure_time und diesem Feld. Wenn eine trip zum Beispiel Haltestelle A mit einer departure_time von 10:00:00 und Haltestelle B mit departure_time von 10:01:00hat, und dieses Feld mit dem Wert 10:30:00gefüllt ist, hat der Halt B auf der DUPLICATED trip den Wert SCHEDULED departure_time von 10:31:00. Echtzeit-Vorhersage delay Werte werden auf diese berechnete time angewendet, um die voraussichtliche time zu bestimmen. Wenn zum Beispiel eine departure delay von 30 für die Haltestelle B angegeben ist, dann ist die voraussichtliche time 10:31:30. Echtzeit-Vorhersage time Auf die Werte der Echtzeitvorhersage wird kein Offset angewandt, so dass die vorhergesagte time wie angegeben angezeigt wird. Wenn zum Beispiel eine departure time 10:31:30 für die Haltestelle B angegeben ist, dann ist die voraussichtliche time 10:31:30Dieses Feld ist erforderlich, wenn schedule_relationship ist DUPLICATED, andernfalls darf dieses Feld nicht ausgefüllt werden und wird von den Verbrauchern ignoriert. Vorsicht! dieses Feld ist noch experimentellund kann sich ändern. Sie kann in der Zukunft formell angenommen werden.
shape_id	string	Optional	Eine	Gibt die Shape der vehicle für diese trip an, wenn sie vom Original abweicht. Bezieht sich auf einen im (CSV) GTFS definierten Shape oder eine neue entity in einemtime. Siehe Definition der trips.shape_id in (CSV) GTFS. Vorsicht! dieses Feld ist noch experimentellund kann sich ändern. Sie kann in der Zukunft formell angenommen werden.

message VehiclePosition

Echtzeit-Positionsdaten für ein bestimmtes vehicle.

Felder

Feldname	Typ	Erforderlich	Kardinalität	Beschreibung
trip	TripDescriptor	Optional	Eine	Die trip, die dieses vehicle bedient. Kann EMPTY oder partial sein, wenn das vehicle nicht mit einer bestimmten trip identifiziert werden kann.
vehicle	VehicleDescriptor	Optional	Eine	Zusätzliche Informationen über das vehicle, das diese trip durchführt. Jeder Eintrag sollte eine eindeutige id haben.
Position	Position	Optional	Eine	Aktuelle Position des vehicle.
current_stop_sequence	uint32	Optional	Eine	Der Haltestellenfolgeindex der aktuellen Haltestelle. Die Bedeutung von current_stop_sequence (d. h. die Haltestelle, auf die er sich bezieht) wird durch current_status bestimmt. Wenn current_status fehlt, wird IN_TRANSIT_TO angenommen.
stop_id	string	Optional	Eine	Identifiziert die aktuelle Haltestelle. Der Wert muss derselbe sein wie in stops.txt im entsprechenden GTFS. Wenn StopTimeProperties.assigned_stop_id verwendet wird, um eine stop_idverwendet wird, sollte dieses Feld auch die Änderung des stop_id.
current_status	VehicleStopStatus	Optional	Eine	Der genaue Status des vehicle in Bezug auf die aktuelle Haltestelle. Wird ignoriert, wenn current_stop_sequence nicht vorhanden ist.
timestamp	uint64	Optional	Eine	Zeitpunkt, zu dem die Position des vehicle gemessen wurde. In time (d. h. die Anzahl der Sekunden seit dem 1. Januar 1970 00:00:00 UTC).
congestion_level	CongestionLevel	Optional	Eine
occupancy_status	OccupancyStatus	Optional	Eine	Der Stand der Fahrgastbelegung des vehicle oder Wagens. Wenn multi_carriage_details mit dem OccupancyStatus pro Wagen ausgefüllt ist, sollte dieses Feld das gesamte vehicle beschreiben, wobei alle Wagen, die Fahrgäste aufnehmen, berücksichtigt werden. Vorsicht! dieses Feld ist noch experimentellund kann sich ändern. Sie kann in der Zukunft formell angenommen werden.
occupancy_percentage	uint32	Optional	Eine	Ein Prozentwert, der den Grad der Fahrgastbelegung des vehicle angibt. Der Wert 100 sollte die maximale Gesamtbelegung darstellen, für die das vehicle ausgelegt ist, einschließlich Sitz- und Stehplätzen, und die nach den geltenden Betriebsvorschriften zulässig ist. Der Wert kann 100 überschreiten, wenn mehr Fahrgäste als die maximal vorgesehene Kapazität vorhanden sind. Die Genauigkeit von occupancy_percentage sollte so gering sein, dass einzelne Fahrgäste beim Ein- und Aussteigen nicht erfasst werden können. Wenn multi_carriage_details mit occupancy_percentage per carriage ausgefüllt ist, sollte dieses Feld das gesamte vehicle beschreiben, wobei alle Wagen, die Fahrgäste aufnehmen, berücksichtigt werden. Vorsicht! dieses Feld ist noch experimentellund kann sich ändern. Sie kann in der Zukunft formell angenommen werden.
multi_carriage_details	CarriageDetails	Optional	Viele	Angaben zu den mehreren Wagen des betreffenden vehicle. Das erste Vorkommen steht für den ersten Wagen des vehicle, unter Berücksichtigung der aktuellen Fahrtrichtung. Die Anzahl der Vorkommen des Feldes multi_carriage_details gibt die Anzahl der Wagen des vehicle an. Es umfasst auch nicht einstiegsfähige Wagen, wie Lokomotiven, MAINTENANCE usw., da sie den Fahrgästen wertvolle Informationen darüber liefern, wo sie auf einem Bahnsteig stehen müssen. Vorsicht! dieses Feld ist noch experimentellund kann sich ändern. Sie kann in der Zukunft formell angenommen werden.

enum VehicleStopStatus

Werte

Wert	Kommentar
INCOMING_AT	Das vehicle ist kurz davor, an der Haltestelle anzukommen (auf einer Haltestellenanzeige blinkt normalerweise das vehicle ).
STOPPED_AT	Das vehicle steht an der Haltestelle.
IN_TRANSIT_TO	Das vehicle hat die vorherige Haltestelle verlassen und befindet sich auf der Durchfahrt.

enum CongestionLevel

CONGESTION, von der das vehicle betroffen ist.

Werte

Wert
UNKNOWN_CONGESTION_LEVEL
RUNNING_SMOOTHLY
STOP_AND_GO
CONGESTION
SEVERE_CONGESTION

enum OccupancyStatus

Status der Fahrgastbelegung für das vehicle oder den Wagen.

Einzelne Hersteller veröffentlichen möglicherweise nicht alle OccupancyStatus. Daher dürfen die Verbraucher nicht davon ausgehen, dass die OccupancyStatus einer linearen Skala folgen. Die Verbraucher sollten die OccupancyStatus als den vom Hersteller angegebenen und beabsichtigten Zustand darstellen. Ebenso müssen die Hersteller OccupancyStatus verwenden, die den tatsächlichen Belegungszuständen der vehicle entsprechen.

Für die Beschreibung von Belegungsgraden auf einer linearen Skala, siehe occupancy_percentage.

Achtung: Dieses Feld ist noch experimentell und kann sich noch ändern. Es kann in Zukunft formell übernommen werden.

Werte

Wert	Bemerkung
EMPTY	Das vehicle gilt nach den meisten Maßstäben als EMPTY und hat nur wenige oder keine Fahrgäste an Bord, nimmt aber noch Fahrgäste auf.
MANY_SEATS_AVAILABLE	Das vehicle oder der Wagen verfügt über eine große Anzahl von freien Sitzplätzen. Die Anzahl der freien Sitzplätze im Verhältnis zur Gesamtzahl der verfügbaren Sitzplätze, die als groß genug gelten, um in diese Kategorie zu fallen, wird vom Hersteller nach eigenem Ermessen festgelegt.
FEW_SEATS_AVAILABLE	Das vehicle oder der Wagen verfügt über eine geringe Anzahl von Sitzplätzen. Es liegt im Ermessen des Herstellers, wie viele freie Sitzplätze im Verhältnis zu den insgesamt zur Verfügung stehenden Sitzplätzen als gering genug angesehen werden, um in diese Kategorie zu fallen.
STANDING_ROOM_ONLY	Das vehicle oder der Wagen kann derzeit nur stehende Fahrgäste aufnehmen.
CRUSHED_STANDING_ROOM_ONLY	Das vehicle oder der Wagen kann derzeit nur stehende Fahrgäste aufnehmen und hat nur begrenzten Platz für diese.
FULL	Das vehicle gilt nach den meisten Maßstäben als FULL, lässt aber möglicherweise noch Fahrgäste einsteigen.
NOT_ACCEPTING_PASSENGERS	Das vehicle oder der Wagen nimmt keine Fahrgäste auf. Das vehicle oder der Wagen nimmt normalerweise Fahrgäste zum Einsteigen auf.
NO_DATA_AVAILABLE	Für das vehicle oder den Wagen sind zu diesem time keine Belegungsdaten verfügbar.
NOT_BOARDABLE	Das vehicle oder der Wagen ist nicht besteigbar und nimmt nie Fahrgäste auf. Nützlich für spezielle Fahrzeuge oder Wagen (Lokomotive, MAINTENANCE, etc...).

message CarriageDetails

Wagenspezifische Details, verwendet für Fahrzeuge, die aus mehreren Wagen bestehen.

Achtung: Diese message ist noch experimentell und kann sich noch ändern. Sie kann in der Zukunft formell angenommen werden.

Felder

Feldname	Typ	Erforderlich	Kardinalität	Beschreibung
id	string	Optional	Eine	Identifizierung des Wagens. Sollte pro vehicle eindeutig sein. Vorsicht! dieses Feld ist noch experimentellund kann sich ändern. Sie kann in der Zukunft formell angenommen werden.
label	string	Optional	Eine	Vom Benutzer sichtbare label, die dem Fahrgast angezeigt werden kann, um die Identifizierung des Wagens zu erleichtern. Beispiel: "7712", "Wagen ABC-32", usw... Vorsicht! dieses Feld ist noch experimentellund kann sich ändern. Sie kann in der Zukunft formell angenommen werden.
occupancy_status	OccupancyStatus	Optional	Eine	Belegungsstatus für diesen bestimmten Wagen in diesem vehicle. Standardwert ist NO_DATA_AVAILABLE. Vorsicht! dieses Feld ist noch experimentellund kann sich ändern. Sie kann in der Zukunft formell angenommen werden.
occupancy_percentage	int32	Optional	Eine	Belegungsprozentsatz für diesen bestimmten Wagen, in diesem vehicle. Folgt den gleichen Regeln wie "VehiclePosition.occupancy_percentage". Verwenden Sie -1, wenn für den betreffenden Wagen keine Daten verfügbar sind. Vorsicht! dieses Feld ist noch experimentellund kann sich ändern. Sie kann in der Zukunft formell angenommen werden.
carriage_sequence	uint32	Erforderlich	Eine	Gibt die Reihenfolge dieses Wagens in Bezug auf die anderen Wagen in der CarriageStatus-Liste des vehicle an. Der erste Wagen in der Fahrtrichtung muss den Wert 1 haben, der zweite Wert entspricht dem zweiten Wagen in der Fahrtrichtung und muss den Wert 2 haben, usw. Beispiel: Der erste Wagen in Fahrtrichtung hat den Wert 1. Wenn der zweite Wagen in Fahrtrichtung den Wert 3 hat, verwerfen die Verbraucher die Daten für alle Wagen (d. h. das Feld multi_carriage_details ). Wagen ohne Daten müssen mit einer gültigen carriage_sequence dargestellt werden, und die Felder ohne Daten sollten weggelassen werden (alternativ könnten diese Felder auch einbezogen und auf die Werte "no data" gesetzt werden). Vorsicht! dieses Feld ist noch experimentellund kann sich ändern. Sie kann in der Zukunft formell angenommen werden.

message Alert

Eine Alert, die auf eine Art von Zwischenfall im öffentlichen Verkehrsnetz hinweist.

Felder

Feldname	Typ	Erforderlich	Kardinalität	Beschreibung
active_period	TimeRange	Optional	Viele	time, in der die Alert dem Benutzer angezeigt werden soll. Fehlt diese Angabe, wird die Alert so lange angezeigt, wie sie im Feed erscheint. Wenn mehrere Zeiträume angegeben werden, wird die Alert während aller Zeiträume angezeigt.
informed_entity	EntitySelector	Erforderlich	Viele	Entitäten, deren Benutzer über diese Alert informiert werden sollen. Es muss mindestens eine informed_entity angegeben werden.
Cause	Cause	Optional	Eine
Effect	Effect	Optional	Eine
url	TranslatedString	Optional	Eine	Die url, die zusätzliche Informationen über die Alert enthält.
header_text	TranslatedString	Erforderlich	Eine	header für die Alert. Dieser string wird hervorgehoben, z. B. durch Fettdruck.
description_text	TranslatedString	Erforderlich	Eine	Beschreibung für die Alert. Diese string wird als Text der Alert formatiert (oder auf ausdrückliche Anfrage des Benutzers angezeigt). Die Informationen in der Beschreibung sollten die Informationen in der header ergänzen.
tts_header_text	TranslatedString	Optional	Eine	text, der die header der Alert enthält und für text verwendet werden soll. Dieses Feld ist die text von header_text. Es sollte die gleichen Informationen wie header_text enthalten, aber so formatiert sein, dass es als text gelesen werden kann (z. B. Abkürzungen entfernt, Zahlen buchstabiert usw.)
tts_description_text	TranslatedString	Optional	Eine	text mit einer Beschreibung der Alert, die für text verwendet werden soll. Dieses Feld ist die text von description_text. Es sollte die gleichen Informationen wie description_text enthalten, aber so formatiert sein, dass es als text gelesen werden kann (z. B. Abkürzungen entfernt, Zahlen buchstabiert usw.)
severity_level	SeverityLevel	Optional	Eine	Schweregrad der Alert.
image	TranslatedImage	Optional	Eine	TranslatedImage, das zusammen mit dem text angezeigt wird. Wird verwendet, um die Effect einer DETOUR, Bahnhofsschließung usw. visuell zu erklären. Das image sollte das Verständnis der Alert fördern und darf nicht die einzige Stelle sein, an der die wesentlichen Informationen zu finden sind. Von folgenden Arten von Bildern wird abgeraten: image, die hauptsächlich text enthalten, Marketing- oder Markenbilder, die keine zusätzlichen Informationen liefern. Vorsicht! dieses Feld ist noch experimentellund kann sich ändern. Sie kann in der Zukunft formell angenommen werden.
image_alternative_text	TranslatedString	Optional	Eine	text, der das Aussehen des verlinkten image in dem image Feld (z. B. für den Fall, dass das image nicht angezeigt werden kann oder der Nutzer das image aus Gründen der Barrierefreiheit nicht sehen kann). Siehe die HTML Spezifikation für alt image text. Vorsicht! dieses Feld ist noch experimentellund kann sich ändern. Sie kann in der Zukunft formell angenommen werden.

enum Cause

Cause für diese Alert.

Werte

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

enum Effect

Die Effect dieses Problems auf die betroffene entity.

Werte

Wert
NO_SERVICE
REDUCED_SERVICE
SIGNIFICANT_DELAYS
DETOUR
ADDITIONAL_SERVICE
MODIFIED_SERVICE
OTHER_EFFECT
UNKNOWN_EFFECT
STOP_MOVED
NO_EFFECT
ACCESSIBILITY_ISSUE

enum SeverityLevel

Der Schweregrad des Alert.

Achtung: Dieses Feld ist noch experimentell und kann sich noch ändern. Es kann in der Zukunft formell angenommen werden.

Werte

Wert
UNKNOWN_SEVERITY
INFO
WARNING
SEVERE

message TimeRange

Ein time. Das Intervall gilt zum time t als aktiv, wenn t größer oder gleich der time und kleiner als die time ist.

Felder

Feldname	Typ	Erforderlich	Kardinalität	Beschreibung
start	uint64	Bedingt erforderlich	Eine	time, in time (d. h. Anzahl der Sekunden seit dem 1. Januar 1970 00:00:00 UTC). Fehlt diese Angabe, beginnt das Intervall bei minus unendlich. Wird ein TimeRange angegeben, muss entweder start oder end angegeben werden - beide Felder dürfen nicht EMPTY sein.
end	uint64	Bedingt erforderlich	Eine	time, in time (d. h. die Anzahl der Sekunden seit dem 1. Januar 1970 00:00:00 UTC). Fehlt sie, endet das Intervall bei plus unendlich. Wird ein TimeRange angegeben, muss entweder start oder end angegeben werden - beide Felder dürfen nicht EMPTY sein.

Position

Eine geografische Position eines vehicle.

Felder

Feldname	Typ	Erforderlich	Kardinalität	Beschreibung
latitude	float	Erforderlich	Eine	Grad Nord, im WGS-84-Koordinatensystem.
longitude	float	Erforderlich	Eine	Grad Ost, im WGS-84-Koordinatensystem.
bearing	float	Optional	Eine	bearing, in Grad, im Uhrzeigersinn von True North, d. h. 0 ist Norden und 90 ist Osten. Dies kann die bearing sein oder die Richtung zum nächsten Halt oder Zwischenziel. Die Peilung sollte nicht aus der Abfolge der vorherigen Positionen abgeleitet werden, die der Kunde aus früheren Daten berechnen kann.
odometer	double	Optional	Eine	Wert desodometer, in Metern.
speed	float	Optional	Eine	Vom vehicle gemessene momentane speed, in Metern pro Sekunde.

message TripDescriptor

Ein Deskriptor, der eine einzelne Instanz einer trip identifiziert.

Zur Angabe einer einzelnen trip reicht in vielen Fällen die trip_id allein aus. In den folgenden Fällen sind jedoch zusätzliche Informationen erforderlich, um eine einzelne trip aufzulösen:

• Für Reisen, die in frequencies.txt definiert sind, sind neben der trip_id auch start_date und start_time erforderlich
• Wenn die trip mehr als 24 Stunden dauert oder sich so verzögert, dass sie mit einer SCHEDULED trip am nächsten Tag kollidieren würde, ist zusätzlich zu trip_id auch start_date erforderlich.
• Wenn das Feld trip_id nicht angegeben werden kann, müssen route_id, direction_id, start_date und start_time angegeben werden

In allen Fällen, in denen route_id zusätzlich zu trip_id angegeben wird, muss die route_id dieselbe route_id sein, die der betreffenden trip in GTFS trips.txt zugewiesen wurde.

Das Feld trip_id kann weder allein noch in Kombination mit anderen TripDescriptor verwendet werden, um mehrere trip zu identifizieren. Zum Beispiel sollte ein TripDescriptor niemals trip_id allein für GTFS frequencies.txt exact_times=0 Fahrten angeben, da start_time auch erforderlich ist, um eine einzelne trip aufzulösen, die zu einer bestimmten time beginnt. Wenn der TripDescriptor nicht auf eine einzelne trip aufgelöst wird (d.h. er wird auf null oder mehrere trip aufgelöst), wird dies als Fehler betrachtet und die entity, die den fehlerhaften TripDescriptor enthält, kann von den Verbrauchern verworfen werden.

Wenn die trip_id nicht bekannt ist, reichen die station sequence ids in TripUpdate nicht aus, und die stop_ids müssen ebenfalls angegeben werden. Darüber hinaus müssen die absoluten arrival angegeben werden.

TripDescriptor.route_id kann nicht innerhalb eines Alert EntitySelector verwendet werden, um einen routenweiten Alert zu spezifizieren, der alle Fahrten für eine Route betrifft - verwenden Sie stattdessen EntitySelector.route_id.

Felder

Feldname	Typ	Erforderlich	Kardinalität	Beschreibung
trip_id	string	Bedingt erforderlich	Eine	Die trip_id aus dem GTFS, auf den sich dieser Selektor bezieht. Bei nicht frequenzbasierten Fahrten (Fahrten, die nicht in GTFS frequencies.txt definiert sind) reicht dieses Feld zur eindeutigen Identifizierung der trip aus. Für frequenzbasierte Fahrten, die in GTFS frequencies.txt definiert sind, sind trip_id, start_time und start_date alle erforderlich. Bei SCHEDULED Fahrten (Fahrten, die nicht in GTFS frequencies.txt definiert sind) kann trip_id nur weggelassen werden, wenn die trip durch eine Kombination aus route_id, direction_id, start_time und start_date eindeutig identifiziert werden kann und alle diese Felder vorhanden sind. Wenn schedule_relationship in einem TripUpdate DUPLICATED ist, identifiziert die trip_id die zu DUPLICATED machende trip aus dem statischen GTFS. Wenn schedule_relationship innerhalb einer VehiclePosition DUPLICATED ist, identifiziert die trip_id die neue doppelte trip und muss den Wert für das entsprechende TripUpdate enthalten.TripProperties.trip_id.
route_id	string	Bedingt erforderlich	Eine	Die route_id aus dem GTFS, auf die sich dieser Selektor bezieht. Wenn trip_id nicht angegeben wird, müssen route_id, direction_id, start_time und schedule_relationship=SCHEDULED gesetzt werden, um eine trip zu identifizieren. TripDescriptor.route_id sollte nicht innerhalb eines Alert EntitySelector verwendet werden, um einen routenweiten Alert anzugeben, der alle Fahrten einer Route betrifft - verwenden Sie stattdessen EntitySelector.route_id.
direction_id	uint32	Bedingt erforderlich	Eine	Die direction_id aus der GTFS trips.txt, die die Fahrtrichtung für Fahrten angibt, auf die sich dieser Selektor bezieht. Wenn trip_id weggelassen wird, muss direction_id angegeben werden. Vorsicht! dieses Feld ist noch experimentellund kann sich ändern. Sie kann in der Zukunft formell angenommen werden.
start_time	string	Bedingt erforderlich	Eine	Die ursprüngliche time dieser trip. Wenn die trip_id einer nicht frequenzbasierten trip entspricht, sollte dieses Feld entweder weggelassen werden oder dem Wert im GTFS entsprechen. Wenn die trip_id einer frequenzbasierten trip entspricht, die in GTFS frequencies.txt definiert ist, ist start_time erforderlich und muss für trip und vehicle angegeben werden. Wenn die trip einem GTFS exact_times=1 entspricht, muss start_time um ein Vielfaches (einschließlich Null) von headway_secs später sein als frequencies.txt start_time für den entsprechenden time. Entspricht die trip exact_times=0, dann kann die start_time beliebig sein und wird zunächst als erste departure der trip erwartet. Einmal festgelegt, sollte die start_time dieser frequenzbasierten trip als unveränderlich angesehen werden, auch wenn sich die erste time ändert - diese time kann stattdessen in einem StopTimeUpdate berücksichtigt werden. Wenn trip_id weggelassen wird, muss start_time angegeben werden. Format und Semantik des Feldes entsprechen denen von GTFSfrequencies.txt, z. B. 11:15:35 oder 25:15:35.
start_date	string	Bedingt erforderlich	Eine	Das start dieser trip im Format JJJJMMTT. Für SCHEDULED Fahrten (Fahrten, die nicht in GTFS frequencies.txt definiert sind) muss dieses Feld angegeben werden, um Fahrten zu unterscheiden, die so spät sind, dass sie mit einer SCHEDULED trip an einem anderen Tag kollidieren. Bei einem Zug, der beispielsweise jeden Tag um 8:00 und 20:00 Uhr abfährt und 12 Stunden Verspätung hat, gäbe es zwei verschiedene Fahrten zur gleichen time. Dieses Feld kann, muss aber nicht für Fahrpläne angegeben werden, bei denen solche Kollisionen unmöglich sind - z. B. bei einem stündlich verkehrenden Dienst, bei dem ein vehicle, das eine Stunde Verspätung hat, nicht mehr als mit dem Fahrplan verbunden gilt. Dieses Feld ist für frequenzbasierte Fahrten erforderlich, die in GTFS frequencies.txt definiert sind. Wenn trip_id weggelassen wird, muss start_date angegeben werden.
schedule_relationship	ScheduleRelationship	Optional	Eine	Die Beziehung zwischen dieser trip und dem statischen Fahrplan. Wenn TripDescriptor in einer Alert angegeben wird EntitySelector, die schedule_relationship angegeben wird, wird das Feld von den Verbrauchern bei der Identifizierung der passenden trip ignoriert.

enum ScheduleRelationship

Die Beziehung zwischen dieser trip und dem statischen Zeitplan. Wenn eine trip nach einem vorläufigen Zeitplan durchgeführt wird, der nicht in GTFS enthalten ist, sollte sie nicht als SCHEDULED, sondern als ADDED gekennzeichnet werden.

Werte

Wert	Bemerkung
SCHEDULED	Einetrip, die gemäß ihrem GTFS Schedule durchgeführt wird oder nahe genug an der SCHEDULED trip liegt, um mit ihr verbunden zu werden.
ADDED	Eine zusätzliche trip, die zusätzlich zu einem laufenden Fahrplan ADDED wurde, z. B. um ein defektes vehicle zu ersetzen oder um auf ein plötzliches Fahrgastaufkommen zu reagieren. HINWEIS: Derzeit ist das Verhalten von Feeds, die diesen Modus verwenden, nicht spezifiziert. Es gibt Diskussionen auf dem GTFS GitHub (1) (2) (3) um die vollständige Spezifizierung oder Ablehnung von ADDED und die Dokumentation wird aktualisiert, sobald diese Diskussionen abgeschlossen sind.
UNSCHEDULED	Eine trip, die läuft und der kein Fahrplan zugeordnet ist - dieser Wert wird verwendet, um Fahrten zu identifizieren, die in GTFS frequencies.txt mit exact_times = 0 definiert sind. Er sollte nicht verwendet werden, um Fahrten zu beschreiben, die nicht in GTFS frequencies.txt definiert sind, oder Fahrten in GTFS frequencies.txt mit exact_times = 1. Fahrten mit schedule_relationship: UNSCHEDULED müssen auch alle StopTimeUpdates setzen schedule_relationship: UNSCHEDULED
CANCELED	Eine trip, die im Fahrplan vorhanden war, aber entfernt wurde.
DUPLICATED	Eine neue trip, die mit Ausnahme des start und der time mit einer bestehenden trip identisch ist. Verwendet mit TripUpdate.TripProperties.trip_id, TripUpdate.TripProperties.start_dateund TripUpdate.TripProperties.start_time um eine bestehende trip aus dem statischen GTFS zu kopieren, aber mit einem anderen start und/oder einer anderen time. Das Duplizieren einer trip ist erlaubt, wenn der Dienst, der mit der ursprünglichen trip in (CSV) GTFS (in calendar.txt oder calendar_dates.txt) innerhalb der nächsten 30 Tage durchgeführt wird. Die zu DUPLICATED trip wird über TripUpdate.TripDescriptor.trip_id. Diese Aufzählung ändert nicht die bestehende trip, auf die durch TripUpdate.TripDescriptor.trip_id - Wenn ein Hersteller die ursprüngliche trip stornieren möchte, muss er eine separate TripUpdate mit dem Wert von CANCELED veröffentlichen. In GTFS definierte Fahrten frequencies.txt mit exact_times definierten Reisen, die EMPTY oder gleich 0 können nicht DUPLICATED werden. Die VehiclePosition.TripDescriptor.trip_id für die neue trip muss den passenden Wert aus TripUpdate.TripProperties.trip_id und VehiclePosition.TripDescriptor.ScheduleRelationship muss ebenfalls auf DUPLICATED. Bestehende Erzeuger und Verbraucher, die die Aufzählung ADDED zur Darstellung von DUPLICATED verwendet haben, müssen den Migrationsanleitung folgen, um auf die Aufzählung DUPLICATED umzustellen.

message VehicleDescriptor

Identifizierungsinformationen für das vehicle, das die trip durchführt.

Felder

Feldname	Typ	Erforderlich	Kardinalität	Beschreibung
id	string	Optional	Eine	Interne Systemidentifikation des vehicle. Sollte eindeutige pro vehicle angegeben werden und dient der Verfolgung des vehicle auf seinem Weg durch das System. Diese id sollte für den end nicht sichtbar sein; verwenden Sie zu diesem Zweck die label Feld
label	string	Optional	Eine	Benutzer sichtbares label, d. h. etwas, das dem Fahrgast gezeigt werden muss, um das richtige vehicle zu identifizieren.
license_plate	string	Optional	Eine	Das Nummernschild des vehicle.

message EntitySelector

Ein Selektor für eine entity in einem GTFS. Die Werte der Felder sollten den entsprechenden Feldern im GTFS entsprechen. Es muss mindestens ein Spezifizierer angegeben werden. Wenn mehrere angegeben werden, sollten sie als durch den logischen UND-Operator verbunden interpretiert werden. Außerdem muss die Kombination der Spezifizierer mit den entsprechenden Informationen im GTFS übereinstimmen. Mit anderen Worten: Damit sich eine Alert auf eine entity in GTFS beziehen kann, muss sie mit allen angegebenen EntitySelector übereinstimmen. Ein EntitySelector, der zum Beispiel die Felder route_id: "5" und route_type: "3" enthält, gilt nur für den route_id: "5" Bus - er gilt nicht für andere Routen mit route_type: "3". Wenn ein Hersteller möchte, dass eine Alert sowohl für route_id: "5" als auch für route_type: "3" gelten soll, sollte er zwei separate EntitySelectors bereitstellen, einen mit Verweis auf route_id: "5" und einen anderen mit Verweis auf route_type: "3".

Es muss mindestens ein Spezifizierer angegeben werden - alle Felder in einem EntitySelector können nicht EMPTY sein.

Felder

Feldname	Typ	Erforderlich	Kardinalität	Beschreibung
agency_id	string	Bedingt erforderlich	Eine	Die agency_id aus dem GTFS, auf den sich dieser Selektor bezieht.
route_id	string	Bedingt erforderlich	Eine	Die route_id aus dem GTFS, auf die sich dieser Selektor bezieht. Wenn direction_id angegeben wird, muss route_id ebenfalls angegeben werden.
route_type	int32	Bedingt erforderlich	Eine	Der route_type aus dem GTFS, auf den sich dieser Selektor bezieht.
direction_id	uint32	Bedingt erforderlich	Eine	Die direction_id aus der GTFS feed trips.txt, die verwendet wird, um alle Fahrten in einer Richtung für eine Route auszuwählen, die durch route_id angegeben wird. Wenn direction_id angegeben wird, muss route_id ebenfalls angegeben werden. Vorsicht! dieses Feld ist noch experimentellund kann sich ändern. Sie kann in der Zukunft formell angenommen werden.
trip	TripDescriptor	Bedingt erforderlich	Eine	Die trip aus dem GTFS, auf die sich dieser Selektor bezieht. Dieser TripDescriptor muss sich auf eine einzelne trip in den GTFS beziehen (z. B. kann ein Hersteller nicht nur eine trip_id für exact_times=0-Fahrten angeben). Wenn das Feld ScheduleRelationship in diesem TripDescriptor ausgefüllt ist, wird es von den Verbrauchern ignoriert, wenn sie versuchen, die trip zu identifizieren.
stop_id	string	Bedingt erforderlich	Eine	Die stop_id aus dem GTFS, auf den sich dieser Selektor bezieht.

message TranslatedString

Eine internationalisierte message mit sprachabhängigen Versionen eines text oder einer url. Eine der Zeichenketten aus einer message wird übernommen. Die Auflösung erfolgt wie folgt: Wenn die language der Benutzeroberfläche mit dem language einer Translation übereinstimmt, wird die erste passende Translation ausgewählt. Wenn eine language (z. B. Englisch) mit dem language einer Translation übereinstimmt, wird die erste passende Translation ausgewählt. Wenn eine Translation einen nicht spezifizierten language hat, wird diese Translation ausgewählt.

Felder

Feldname	Typ	Erforderlich	Kardinalität	Beschreibung
Translation	Translation	Erforderlich	Viele	Es muss mindestens eine Translation angegeben werden.

Translation

Eine lokalisierte string, die einer language zugeordnet ist.

Feldname	Typ	Erforderlich	Kardinalität	Beschreibung
text	string	Erforderlich	Eine	Eine string, die die message enthält.
language	string	Bedingt erforderlich	Eine	language. Kann weggelassen werden, wenn die language unbekannt ist oder wenn für den Feed überhaupt keine Internationalisierung vorgenommen wird. Höchstens eine Translation darf ein nicht spezifiziertes language haben - wenn es mehr als eine Translation gibt, muss die language angegeben werden.

message TranslatedImage

Eine internationalisierte message, die die einzelnen Sprachversionen eines image enthält. Eines der Bilder aus einer message wird ausgewählt. Bei der Auflösung wird wie folgt vorgegangen: Wenn die language der Benutzeroberfläche mit dem language einer Translation übereinstimmt, wird die erste passende Translation ausgewählt. Wenn eine language (z. B. Englisch) mit dem language einer Translation übereinstimmt, wird die erste passende Translation ausgewählt. Wenn eine Translation einen nicht spezifizierten language hat, wird diese Translation ausgewählt.

Achtung: Diese message ist noch experimentell und kann sich noch ändern. Sie kann in der Zukunft formell angenommen werden.

Felder

Feldname	Typ	Erforderlich	Kardinalität	Beschreibung
localized_image	LocalizedImage	Erforderlich	Viele	Es muss mindestens ein lokalisiertes image angegeben werden.

message LocalizedImage

Eine lokalisierte url, die einer language zugeordnet ist.

Feldname	Typ	Erforderlich	Kardinalität	Beschreibung
url	string	Erforderlich	Eine	string mit einer url, die auf ein image verweist. Das verlinkte image muss kleiner als 2 MB sein. Wenn sich ein image so stark ändert, dass eine Aktualisierung auf der Verbraucherseite erforderlich ist, muss der Hersteller die url auf eine neue URL aktualisieren. Die url sollte eine vollständig qualifizierte url sein, die http:// oder https:// enthält, und alle Sonderzeichen in der url müssen korrekt escaped werden. Siehe die folgenden url für eine Beschreibung, wie man voll qualifizierte url erstellt.
media_type	string	Erforderlich	Eine	IANA-Medientyp, um den Typ des anzuzeigenden image anzugeben. Der Typ muss mit "image/" start.
language	string	Bedingt erforderlich	Eine	BCP-47 language. Kann weggelassen werden, wenn die language unbekannt ist oder wenn für den Feed überhaupt keine Internationalisierung vorgenommen wird. Höchstens eine Translation darf ein nicht spezifiziertes language haben - gibt es mehr als eine Translation, muss die language angegeben werden.

Shape der_message_

Beschreibt den physischen Weg, den ein vehicle nimmt, wenn der Shape nicht Teil des (CSV) GTFS ist, wie z. B. bei einer Ad-hoc DETOUR. Shapes gehören zu Trips und bestehen aus einer kodierten Polylinie, um eine effizientere Übertragung zu ermöglichen. Shapes müssen die Lage der Haltestellen nicht exakt abbilden, aber alle Haltestellen einer trip sollten innerhalb eines kleinen Abstands zum Shape für diese trip liegen, d. h. in der Nähe von geraden Liniensegmenten, die die Shape verbinden

Achtung: Diese message ist noch experimentell und kann sich noch ändern. Sie kann in der Zukunft formell angenommen werden.
.

Felder

Feldname	Typ	Erforderlich	Kardinalität	Beschreibung
shape_id	string	Erforderlich	Eine	Bezeichner des Shape. Muss anders sein als die shape_id in der (CSV) GTFS definiert. Vorsicht! dieses Feld ist noch experimentellund kann sich ändern. Sie kann in der Zukunft formell angenommen werden.
encoded_polyline	string	Erforderlich	Eine	Kodierte Polyliniendarstellung der Shape. Dieser Linienzug muss mindestens zwei Punkte enthalten. Für weitere Informationen über kodierte Polylinien siehe https://developers.google.com/maps/documentation/utilities/polylinealgorithm Vorsicht! dieses Feld ist noch experimentellund kann sich ändern. Sie kann in der Zukunft formell angenommen werden.