Übersicht
Wenn Sie nicht der Anbieter der GTFS-Feeds für Google Maps sind, ist Ihre Integration eine reine Haltestellenintegration. Für diese Integration müssen wir wissen, wie Sie die verschiedenen Zug- oder Bushaltestellen identifizieren.
Allgemeine Feedspezifikationen
Beim Start der Integration erstellen wir eine eindeutige ID für jede Integration, z. B. ch_google_test (Ländercode, Partnername, Integration) oder eu_google (Regionscode, Partnername).
Partner stellen eine Datei mit Textdateien im CSV-Format bereit, die pro Integration angewendet werden. Jede CSV-Datei muss eine Kopfzeile mit Spaltennamen enthalten, die mit dem in der entsprechenden Feedspezifikationstabelle angegebenen Feldnamen übereinstimmen.
Damit Partner neue Versionen der Haltestellen- und Marktdateien hochladen können, teilt unser Team während des Onboardings SFTP-Dropbox-Details mit. Für jeden Dateityp gibt es eine.
Feedspezifikation für Haltestellen (erforderlich)
Die Haltestellendatei sollte die folgenden Spalten enthalten:
| Feldname | Typ (siehe GTFS) | Beschreibung |
|---|---|---|
stop_id |
ID (erforderlich) | Die eindeutige ID, die eine Haltestelle oder einen Bahnhof identifiziert. Größere Bahnhöfe sollten nur einen Eintrag enthalten. Diese ID wird verwendet, wenn Aufrufe an die Partner Server API erfolgen und in den Ticket-Deeplinks. |
stop_name |
Text (erforderlich) | Ein für Menschen lesbarer Name zum Debuggen der Haltestellenzuordnung, zum Füllen des Cache und für Daten zur Preisgenauigkeit. |
stop_lat |
Breitengrad (erforderlich) | Breitengrad der Haltestelle. |
stop_lon |
Längengrad (erforderlich) | Längengrad der Haltestelle. |
Wir verwenden einen automatisierten Aufnahmeprozess, bei dem Partner kontinuierlich aktualisierte ZIP-Dateien bereitstellen können, wenn sich die darin enthaltenen Informationen ändern. Ein Partner kann beispielsweise das bereitgestellte Inventar erweitern, indem er die Liste der Haltestellen verlängert. Ähnlich wie bei GTFS sollten stop_ids jedoch stabil sein.
Feedspezifikation für Marktsets (optional)
Mit den zugeordneten Haltestellen generieren wir das Marktset für diese Integration (eine Liste mit beliebten Paaren von Start- und Zielorten). Sie haben dann die Möglichkeit, dieses Marktset zu reduzieren, indem Sie einen Marktset-Feed bereitstellen.
Das Marktset dient als Zulassungsliste für unseren Cache-Fülldienst. Wenn kein Marktset angegeben wird, sind standardmäßig alle Märkte aktiviert. Wenn Sie ein Marktset bereitstellen, werden nur die in der Liste enthaltenen Märkte abgefragt. Wenn Nutzer Märkte außerhalb dieser Zulassungsliste abfragen, senden unsere Systeme weiterhin eine Live-Abfrage für den angeforderten Markt und das angeforderte Datum. Wir versuchen jedoch nicht, diese proaktiv im Cache zu speichern.
Die Marktset-Datei sollte die folgenden Spalten enthalten:
| Feldname | Typ (siehe GTFS) | Beschreibung |
|---|---|---|
origin_stop_id |
ID (erforderlich) | Die stop_id des Startorts des Marktes. |
destination_stop_id |
ID (erforderlich) | Die stop_id des Zielorts des Marktes. |
Partnerkonfiguration
Bei Verwendung der reinen Haltestellenintegration benötigen wir zusätzliche Informationen für die statische Partnerkonfiguration, wie im Abschnitt Partnerkonfiguration beschrieben.
Spezifikation für Empfehlungslinks
Das Format und die Parameter des Buchungslinks (auch
Ticketing link) sind unter Ticketlinks definiert.
Parameter der Partner API
Die SegmentKeys-Parameter für die Partner API
(GetBulkTripOptionsRequest)
basieren auf der Deeplink-Spezifikation. Wir verwenden
SegmentKeys, die
nur from_ticketing_stop_time_id, to_ticketing_stop_time_id, service_date, boarding_time und arrival_time enthalten.
ticketing_trip_id bleibt leer. Wir geben die Route einschließlich aller Umstiege vollständig an, indem wir mehrere SegmentKeys angeben, einen pro Segment.