Przegląd
Jeśli nie jesteś dostawcą danych GTFS dla Map Google, Twoja integracja jest tylko przystankowa. W przypadku tej integracji musimy wiedzieć, jak identyfikujesz różne przystanki pociągów lub autobusów.
Ogólne specyfikacje pliku danych
Na początku integracji tworzymy unikalny identyfikator każdej integracji, np. ch_google_test (kod kraju, nazwa partnera, integracja) lub eu_google (kod regionu, nazwa partnera).
Partnerzy przesyłają plik zawierający pliki tekstowe w formacie CSV, które są stosowane w przypadku każdej integracji. Każdy plik CSV musi zawierać wiersz nagłówka z nazwami kolumn, które są zgodne z „Nazwą pola” podaną w odpowiedniej tabeli specyfikacji pliku danych.
Aby umożliwić partnerom przesyłanie nowych wersji plików przystanków i rynków, nasz zespół udostępni szczegóły skrzynki referencyjnej SFTP (po jednej dla każdego typu pliku) podczas procesu wprowadzania.
Specyfikacja pliku danych o przystankach (wymagana)
Plik przystanków powinien zawierać te kolumny:
| Nazwa pola | Typ (patrz GTFS) | Opis |
|---|---|---|
stop_id |
Identyfikator (wymagany) | Unikalny identyfikator, który określa przystanek lub stację. Większe stacje powinny zawierać tylko jeden wpis. Jest on używany podczas wywoływania interfejsu API serwera partnera i w precyzyjnych linkach do biletów. |
stop_name |
Tekst (wymagane) | Nazwa czytelna dla człowieka, która służy do debugowania mapowania przystanków, wypełniania pamięci podręcznej i danych dotyczących dokładności cen. |
stop_lat |
Szerokość geograficzna (wymagana) | Szerokość geograficzna przystanku. |
stop_lon |
Długość geograficzna (wymagana) | Długość geograficzna przystanku. |
Będziemy korzystać z automatycznego procesu przesyłania, w którym partnerzy mogą stale dostarczać zaktualizowane pliki ZIP, gdy zmienią się zawarte w nich informacje. Na przykład partner może zwiększyć liczbę dostępnych zasobów reklamowych, rozszerzając listę przystanków. Podobnie jak w przypadku GTFS, wartość stop_ids powinna być stabilna.
Specyfikacja pliku danych o zestawie produktów (opcjonalnie)
Na podstawie zmapowanych przystanków generujemy zestaw rynków dla tej integracji (lista zawierająca popularne pary miejsc docelowych i początkowych). Możesz zmniejszyć ten zestaw rynków, przesyłając plik danych zestawu rynków.
Zestaw rynków działa jako lista dozwolonych dla naszej usługi wypełniania pamięci podręcznej. Domyślnie, jeśli nie podasz żadnego zestawu rynków, włączone będą wszystkie rynki. Jeśli podasz zestaw rynków, zapytania będą kierowane tylko na rynki uwzględnione na liście. Jeśli użytkownicy wysyłają zapytania dotyczące rynków spoza tej listy dozwolonych, nasze systemy nadal będą wysyłać zapytanie na żywo dotyczące konkretnego rynku i daty, ale nie będziemy próbować aktywnie zapisywać go w pamięci podręcznej.
Plik zestawu rynków powinien zawierać te kolumny:
| Nazwa pola | Typ (patrz GTFS) | Opis |
|---|---|---|
origin_stop_id |
Identyfikator (wymagany) | Pochodzenie stop_id rynku. |
destination_stop_id |
Identyfikator (wymagany) | Miejsce docelowe stop_id na rynku. |
Konfiguracja partnera
W przypadku integracji typu „tylko zatrzymanie” wymagamy dodatkowych informacji do konfiguracji statycznej partnera, zgodnie z opisem w sekcji Konfiguracja partnera.
Specyfikacja linków rekomendacyjnych
Format i parametry linku do rezerwacji (zwanego też Ticketing link) są zdefiniowane w linkach do sprzedaży biletów.
Parametry interfejsu API partnera
Parametry SegmentKeys w interfejsie Partner API (GetBulkTripOptionsRequest) są oparte na specyfikacji precyzyjnego linku. Używamy SegmentKeys, w tym tylko from_ticketing_stop_time_id, to_ticketing_stop_time_id, service_date, boarding_time i arrival_time, pozostawiając ticketing_trip_id puste. W pełni określimy trasę, w tym wszystkie przesiadki, podając kilka kluczy segmentów, po jednym na segment.