Przegląd
Jeśli nie jesteś dostawcą plików 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ć partnerowi przesyłanie nowych wersji plików przystanków i rynków, nasz zespół udostępni mu szczegóły dotyczące skrzynki 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 Partner Server API i w precyzyjnych linkach do biletów. |
stop_name |
Tekst (wymagane) | Możliwa do odczytania przez człowieka nazwa 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 identyfikatory przystanków powinny być stałe.
Specyfikacja pliku danych o zestawie produktów (opcjonalnie)
Na podstawie zmapowanych przystanków generujemy zestaw rynków dla tej integracji (listę zawierającą popularne pary miejsc docelowych i początkowych). Możesz zmniejszyć ten zestaw rynków, przesyłając plik danych z zestawem rynków.
Zestaw rynków działa jak 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 sekcji Linki do zakupu 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 wiele kluczy segmentów, po jednym na segment.