GTFS-Anforderungen

Der Partner muss einen GTFS-Feed zur Verfügung stellen, der allen Standardspezifikationen sowie den unten aufgeführten Spezifikationen entspricht. Dieser Feed sollte alle Reisepläne abdecken, die der Partner anzeigen möchte. Wenn Sie diese Informationen angeben, werden Fahrplan- und Routeninformationen auf Google angezeigt. Partner können optional zusätzliche Preis- und Verfügbarkeitsinformationen für einige oder alle Reisepläne im bereitgestellten Feed anzeigen lassen.

Standardanforderungen

Statische GTFS-Referenz: Es werden alle Standardanforderungen angewendet.

Best Practices für GTFS – Befolgen Sie die Best Practices so, als ob sie erforderlich wären.

GTFS-Feeds hochladen: Gehen Sie wie hier beschrieben vor, um einen GTFS-Feed hochzuladen.

Updates: Sobald Feeds hochgeladen wurden, können sie wie hier beschrieben aktualisiert werden. Im Allgemeinen kann es zwei bis drei Tage dauern, bis diese Feedaktualisierungen vollständig wirksam werden.

Zusätzliche Anforderungen

Umfang

• Ein GTFS-Feed muss ein einzelnes Land oder einen Teil eines Landes abdecken. Fahrten, die über Ländergrenzen hinweg verlaufen, müssen in separaten Feeds für den gesamten Kontinent bereitgestellt werden. Wenn ein GTFS-Feed mehr Elemente als ein Land abdeckt, wenden Sie sich bitte an das Travel Transport Team.
  • Dateien in der GTFS-ZIP-Datei sollten nicht größer als 4 GB sein. Größere Dateien sind normalerweise ein Zeichen für schlechte Vorgehensweisen, wenn z. B. die von frequencies.txt oder ähnlichen Funktionen angebotenen Komprimierungsoptionen ignoriert werden. Dies kann zu Problemen bei der Verarbeitung führen. Wenn Sie der Meinung sind, dass 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 die Daten des gesamten zukünftigen Betriebs von Diensten in einem GTFS-Feed zur Verfügung gestellt werden. Eine Segmentierung von Diensten nach verschiedenen Zeiträumen ist nicht akzeptabel.
• Alle Daten für einen bestimmten Operator müssen in einem einzigen Feed enthalten sein.

Übersetzungen

• Übersetzungen können über translations.txt bereitgestellt werden und sind in folgenden Ländern erforderlich:
  • Die Informationen für Nutzer werden in verschiedenen Schriftsystemen oder in anderen Skripts als lateinischen Schriftsystemen bereitgestellt.
  • Die Informationen für Nutzer können in mehreren Sprachen zur Verfügung gestellt werden oder wenn Entitäten in diesen Sprachen unterschiedliche Benennungen verwenden können (z. B. Brüssel/Brüssel/Brüssel).
• Zu übersetzende Entitäten
  • Namen der Betreiber/Haltestellen/Routen
  • Zielschilder für Fahrt/Haltestelle

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 konsistent bleibt) oder in stop_times.txt (wenn sich das Zielschild in verschiedenen Phasen der Fahrt ändert) angegeben werden.
• Zielschilder sollten mit den Informationen auf dem Boden übereinstimmen. Dies können beispielsweise Zielschilder sein, die am Fahrzeug oder auf Schildern angebracht sind.
• Wenn eine Route einen Namen hat, muss sie als long_name in routes.txt angegeben werden.
• Wenn eine Route eine bestimmte Nummer oder eine alphanumerische Kennung hat, die für alle Fahrten auf dieser Route und in beide Richtungen gilt, muss sie als Kurzname in routes.txt angegeben werden.
• Wenn Fahrten innerhalb der Route individuelle Kennungen haben (z. B. Zugnummern), müssen diese Kennungen als Kurznamen für Fahrten angegeben werden.
• Bei Ferndiensten, die keine Routennummern oder -namen haben, wird die Auswahl eines Routennamens problematisch. In solchen Fällen gilt als allgemeine Richtlinie, dass eine Kombination aus Routenname und Zielschild dem Nutzer helfen sollte, das Fahrzeug eindeutig zu identifizieren. Beispielsweise kann der Name des Betreibers als Routenname verwendet werden, während das Ziel der Fahrt (falls auf dem Fahrzeug angegeben) als Zielschild verwendet werden sollte.

Beispiele

• Indian Railways Kamayani Express Train 11071 von Mumbai nach Varanasi. Hinweis: Die Nummer 11071 identifiziert eine bestimmte Zugfahrt von Mumbai nach Varanasi, nicht die Route selbst.
  • routes.txt:
    • Kurzname: <leer>
    • long_name: Kamayani Express
  • trips.txt:
    • trip_short_name: 11071
    • Zielschild: Varanasi
• Ein Bus von Buenos Aires nach Córdoba, der von Chevallier Bus betrieben wird. Hinweis: Für den Bus, der diesen Betrieb betrieb, wird kein bestimmter Routenname angezeigt. Stattdessen sind der Name des Betreibers und sein Ziel gut sichtbar. Diese Fahrt hat keine eigene Nummer/Kennung, die sie von anderen Fahrten unterscheidet, die von demselben Betreiber durchgeführt werden oder dieselbe Route bedienen. In diesem Fall kann „Chevallier“ sowohl als Name des Betreibers (in agencies.txt) als auch als „long_name“ der Route (in routes.txt) verwendet werden. „Destination“ sollte für das Zielschild verwendet werden. „trip_short_name“ sollte leer bleiben.
  • routes.txt:
    • Kurzname: <leer>
    • Langname: Chevallier
  • trips.txt:
    • trip_short_name: <leer>
    • Zielschild: Córdoba

Haltestellenzeiten

In stop_times.txt müssen sowohl „arrival_time“ als auch „Abreisezeit“ angegeben werden.

Reisestruktur

• Fernfahrten, die mehrere Städte/Gebiete abdecken, sollten durchgängig und ohne Segmentierung bereitgestellt werden (z.B. A->B->C nicht [A->B,A->C,B->C]), wobei A, B, C Stadtgebiete sind. Ein Langstreckenbus, der von Buenos Aires nach Córdoba fährt und eine Haltestelle in Rosario hat, sollte beispielsweise als Fahrt mit Stopps in diesen drei Städten dargestellt werden, nicht als drei Fahrten „Buenos Aires – Rosenario“, „Buenos Aires – Córdoba“ und „Rosario – Córdoba“.
• Falls der Datenanbieter nicht in der Lage ist, die Informationen zur korrekten Fahrtstruktur zu erhalten, können von Fall zu Fall segmentierte Fahrten von Stadt zu Stadt bereitgestellt werden. Wenn solche Fahrten innerhalb einer Stadt (Stadtbereich) mehrere Start- oder Absetzpunkte haben, ist die Segmentierung von Haltestellen zu Haltestellen nicht zulässig. Alle Start- und Zielpunkte sollten in einer einzelnen Fahrt aufgeführt sein.

Stationsstrukturen

Bei großen Stationen mit mehreren Bahnsteigen/Bays müssen die Beziehungen zwischen Bahnsteigen und Bahnsteigen im Feed angegeben werden. Die spezifischen Buchten/Bahnsteige müssen durch das Feld „platform_code“ in stops.txt angegeben werden. Fahrzeuge, die regelmäßig von einer bestimmten Bucht oder einem bestimmten Bahnsteig abfahren bzw. in diese einsteigen, sollten im GTFS-Feed mit dieser Bucht oder diesem Gleis verknüpft sein. Wenn sich der Abfahrts- oder Ankunftsbahnhof oder die Bucht an verschiedenen Abfahrtstagen/-zeiten ändert, können diese Informationen in GTFS Realtime zur Verfügung gestellt werden.

Haltestellenpositionen

• Bei großen Stationen mit mehreren Bahnsteigen oder Schächten sollte die Position der Station auf die Position des auffälligsten Fußgängereingangs (wenn die Station ein Gebäude oder ein Gebäude hat) oder auf die Position des Fahrgastwartebereichs (bei Außenstationen) festgelegt werden.
• Bei kleineren Haltestellen am Straßenrand sollte die Position der Haltestelle auf den Standort des Busmasts festgelegt werden, sofern dieser erkannt werden kann. Wenn ein bestimmter Busmast nicht identifiziert werden kann, sollte er auf der richtigen Straßenseite und in der Nähe des tatsächlichen Standorts auf der Straße platziert werden (idealerweise innerhalb von 10 m), wo das Fahrzeug anhält.

Zusätzliche GTFS-Erweiterungen

Nur für Partner erforderlich, die Preis- und Verfügbarkeitsinformationen durch Implementieren der Partner-APIs zur Verfügung stellen möchten.

Google Transit-Fahrkartenerweiterung

• Partner sollten die Spezifikation der Google Transit-Fahrkartenerweiterung implementieren, die eine Teilmenge der GTFS-Fahrkartenerweiterung ist.
• Für Ticket-IDs gelten die folgenden Anforderungen:
  • Ticket-IDs sollten stabil sein (d.h., sie dürfen sich aus gutem Grund selten ändern). Wenn sich Ticket-IDs ändern, ist Abwärtskompatibilität erforderlich (für den Mindestzeitraum von mindestens einer Woche).
  • Zum Ermitteln der Parameter von SegmentKey in API-Anfragen sind ticketing_trip_id (in trips.txt) und ticketing_stop_id (in ticketing_identifiers.txt) erforderlich. Das Fallback für stop_sequence wird nicht unterstützt, da es nicht stabil ist.

GTFS-Tarife (Version 1)

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