GTFS-Anforderungen

Der Partner muss einen GTFS-Feed bereitstellen, der alle Standardspezifikationen sowie die unten aufgeführten Spezifikationen erfüllt. Dieser Feed sollte alle Reisepläne enthalten, die der Partner präsentieren möchte. Wenn Sie diese Informationen angeben, können Fahrplan- und Routeninformationen bei Google angezeigt werden. Ein Partner kann zusätzliche Preis- und Verfügbarkeitsinformationen für einige oder alle Reisepläne im bereitgestellten Feed angeben.

Standardanforderungen

Static GTFS-Referenz: Alle Standardanforderungen werden angewendet.

Best Practices für GTFS: Bitte halten Sie sich an die Best Practices, als wären sie erforderlich.

GTFS-Feeds hochladen: Folgen Sie dieser Anleitung, um den GTFS-Feed hochzuladen.

Aktualisierungen: Nachdem Feeds hochgeladen wurden, können sie gemäß der hier beschriebenen Vorgehensweise aktualisiert werden. Im Allgemeinen kann es zwei bis drei Tage dauern, bis diese Feed-Aktualisierungen vollständig übertragen wurden.

Zusätzliche Anforderungen

Umfang

• Ein einzelner GTFS-Feed muss ein einzelnes Land oder einen Teil eines Landes abdecken. Fahrten, die Landesgrenzen überschreiten, müssen in separaten kontinentweiten Feeds angegeben werden. Wenn ein GTFS-Feed ein Gebiet abdeckt, das größer als ein Land ist, wenden Sie sich bitte an das Travel Transport-Team.
  • Dateien in der GTFS-ZIP-Datei sollten kleiner als 4 GB sein. Dateien, die größer als diese sind, sind in der Regel ein Zeichen für schlechte Praktiken, z. B. das Ignorieren der von frequencies.txt angebotenen Komprimierungsoptionen oder ähnlicher Funktionen. Dies kann zu Problemen bei der Verarbeitung führen. Wenn Sie Dateien benötigen, die größer als 4 GB sind, wenden Sie sich bitte an das Travel Transport-Team unter [e-mail].
  • Bei jeder Aktualisierung von GTFS-Daten sollten Daten für den gesamten zukünftigen Betriebszeitraum von Diensten in einem GTFS-Feed angegeben werden. Eine Segmentierung von Diensten nach unterschiedlichen Zeiträumen ist nicht zulässig.
• Alle Datumsangaben für einen bestimmten Betreiber müssen in einem einzigen Feed enthalten sein.

Übersetzungen

• Übersetzungen können mit translations.txt bereitgestellt werden und sind in Ländern erforderlich, in denen:
  • Informationen für Nutzer können in verschiedenen oder nicht lateinischen Schriftsystemen bereitgestellt werden.
  • Informationen für Nutzer können in mehreren Sprachen bereitgestellt werden oder wenn Entitäten in diesen Sprachen unterschiedliche Namen verwenden (z. B. Brüssel/Brussel/Bruxelles).
• Zu übersetzende Entitäten
  • Namen von Agenturen, Haltestellen und Routen
  • Zielschilder von Fahrten/Haltestellen

Routennamen, Kurznamen für Fahrten und Zielschilder

• Zielschilder müssen für alle Fahrten entweder in trips.txt (wenn das Zielschild während der gesamten Fahrt gleich bleibt) oder in stop_times.txt (wenn sich das Zielschild in verschiedenen Phasen der Fahrt ändert) angegeben werden.
• Die Beschilderung muss mit den Informationen übereinstimmen, die Nutzer vor Ort finden. Beispielsweise Zielschilder am Fahrzeug oder auf Schildern.
• Wenn eine Route einen Namen hat, muss er als „long_name“ in routes.txt angegeben werden.
• Wenn eine Route eine bestimmte Nummer oder alphanumerische Kennung hat, die für alle Fahrten auf dieser Route und in beide Richtungen gilt, muss sie als „short_name“ in routes.txt angegeben werden.
• Wenn Fahrten auf der Route individuelle Kennungen haben (z. B. Zugnummern), müssen diese Kennungen als kurze Namen für die Fahrten angegeben werden.
• Bei Fernverkehrsdiensten ohne Routennummern oder -namen ist die Auswahl eines Routennamens problematisch. Die allgemeine Richtlinie in solchen Situationen ist, dass eine Kombination aus dem Routennamen und dem Zielschild dem Nutzer helfen sollte, das Fahrzeug eindeutig zu identifizieren. So kann beispielsweise der Name des Betreibers als Routenname verwendet werden, während das Ziel der Fahrt (falls im Fahrzeug angezeigt) als Fahrtziel verwendet werden sollte.

Beispiele

• Kamayani Express Train 11071 der Indian Railways von Mumbai nach Varanasi. Hinweis: Die Nummer 11071 bezieht sich auf eine bestimmte Zugfahrt von Mumbai nach Varanasi, nicht auf die Route selbst.
  • routes.txt:
    • short_name: <empty>
    • long_name: Kamayani Express
  • trips.txt:
    • trip_short_name: 11071
    • headsign: Varanasi
• Ein Bus von Buenos Aires nach Córdoba, betrieben von Chevallier Bus. Hinweis: Auf dem Bus, der diesen Dienst betrieben hat, wird kein bestimmter Routenname angezeigt. Stattdessen werden der Name der Betreiberagentur und das Ziel deutlich angezeigt. Diese Fahrt hat keine individuelle Nummer/Kennung, die sie von anderen Fahrten desselben Verkehrsverbunds oder auf derselben Strecke unterscheidet. In diesem Fall ist es zulässig, „Chevallier“ sowohl als Namen des Verkehrsverbunds (in agencies.txt) als auch als langen Namen der Route (in routes.txt) zu verwenden. Das Ziel sollte für das Zielschild verwendet werden. Der Kurzname der Fahrt sollte leer bleiben.
  • routes.txt:
    • short_name: <empty>
    • long_name: Chevallier
  • trips.txt:
    • trip_short_name: <empty>
    • Zielanzeige: Córdoba

Haltestellenzeiten

Sowohl „arrival_time“ als auch „departure_time“ müssen in stop_times.txt angegeben werden.

Reisestruktur

• Langstreckenfahrten, die mehrere Städte/Gebiete bedienen, sollten ohne Segmentierung (z.B. A –> B –> C, nicht [A –> B, A –> C, B –> C]) bereitgestellt werden, wobei A, B und C Stadtteile sind. Ein Fernbus, der von Buenos Aires nach Córdoba fährt und in Rosario hält, sollte beispielsweise als Reise mit Haltestellen in diesen drei Städten dargestellt werden, nicht als drei Reisen „Buenos Aires – Rosario“, „Buenos Aires – Córdoba“ und „Rosario – Córdoba“.
• Wenn der Datenanbieter die Informationen zur richtigen Fahrtstruktur nicht abrufen kann, werden segmentierte Fahrten von Stadt zu Stadt möglicherweise im Einzelfall bereitgestellt. Wenn solche Fahrten von Stadt zu Stadt mehrere Abhol- oder Abgabeorte innerhalb einer Stadt (Stadtgebiet) haben, ist eine Segmentierung von Haltestelle zu Haltestelle nicht zulässig. Alle Abhol- und Abgabeorte sollten in einer einzigen Fahrt aufgeführt werden.

Stationsstrukturen

Bei großen Bahnhöfen mit mehreren Bahnsteigen/Gleisen müssen die Beziehungen zwischen Bahnhof und Bahnsteig im Feed angegeben werden. Die einzelnen Gleise/Bahnsteige müssen über das Feld „platform_code“ in stops.txt identifiziert werden. Fahrzeuge, die regelmäßig von einem bestimmten Bussteig oder Bahnsteig abfahren oder an einem bestimmten Bussteig oder Bahnsteig ankommen, sollten im GTFS-Feed mit diesem Bussteig oder Bahnsteig verknüpft werden. Wenn sich das Abfahrts- oder Ankunftsgleis oder der Abfahrts- oder Ankunftsbereich an verschiedenen Abfahrtszeiten/-tagen ändert, können diese Informationen in GTFS Realtime angegeben werden.

Standorte von Bahnhöfen/Haltestellen

• Bei großen Bahnhöfen mit mehreren Bahnsteigen oder Buchten sollte der Standort des Bahnhofs auf den Standort des Haupteingangs für Fußgänger (falls der Bahnhof ein Gebäude oder eine Struktur hat) oder auf den Standort des Wartebereichs für Fahrgäste (bei Bahnhöfen im Freien) festgelegt werden.
• Bei kleineren Haltestellen am Straßenrand sollte der Standort einer Haltestelle auf den Standort des Haltestellenschilds festgelegt werden, sofern ein solches vorhanden ist. Wenn eine bestimmte Haltestellenmarkierung nicht identifiziert werden kann, sollte der Standort auf der richtigen Straßenseite und in der Nähe des tatsächlichen Standorts entlang der Straße platziert werden, an dem das Fahrzeug hält (idealerweise innerhalb von 10 Metern).

Zusätzliche GTFS-Erweiterungen

Nur für Partner erforderlich, die Preis-/Verfügbarkeitsinformationen durch Implementierung der Partner-APIs präsentieren möchten.

Google Transit-Fahrkartenerweiterung

• Partner sollten die Spezifikation für die Google Transit-Fahrkartenerweiterung implementieren, die eine Teilmenge der GTFS-Fahrkartenerweiterung ist.
• Für Ticketing-IDs gelten die folgenden Anforderungen:
  • Ticketing-IDs sollten stabil sein (d.h. sich nur selten und aus gutem Grund ändern). Wenn sich Ticket-IDs ändern, ist eine Abwärtskompatibilität erforderlich (mindestens eine Woche lang).
  • Um die Parameter des SegmentKey in API-Anfragen zu bestimmen, sind ticketing_trip_id (in trips.txt) und ticketing_stop_id (in ticketing_identifiers.txt) erforderlich. Der Fallback auf stop_sequence wird nicht unterstützt, da er nicht stabil ist.

GTFS-Fares v1

In der GTFS Static-Referenz werden die optionalen Dateien fare_attributes.txt und fare_rules.txt angegeben. Wenn ein Partner die Partner-APIs verwendet, sollten diese Dateien nicht bereitgestellt werden.