Wymagania GTFS

Partner powinien dostarczyć plik danych GTFS, który spełnia wszystkie standardowe wymagania, oraz te wymienione poniżej. Powinien on obejmować wszystkie plany podróży, które partner chce wyświetlać. Podanie tych informacji umożliwi wyświetlanie w Google rozkładu jazdy i tras. Pamiętaj, że partner może ujawnić dodatkowe informacje o cenie i dostępności w przypadku niektórych lub wszystkich planów podróży w udostępnionym pliku danych.

Wymagania domyślne

Dokumentacja statycznego GTFS – stosowane są wszystkie wymagania domyślne.

Sprawdzone metody dotyczące GTFS – stosuj te sprawdzone metody tak, jakby były wymagane.

Przesyłanie plików danych GTFS. Aby przesłać plik danych GTFS, postępuj zgodnie z tą procedurą.

Aktualizacje: pamiętaj, że po przesłaniu plików danych można je aktualizować, wykonując czynności opisane tutaj. Zwykle pełne zastosowanie zmian w pliku danych może potrwać 2–3 dni.

Dodatkowe wymagania

Zakres

• Jeden plik danych GTFS musi obejmować cały kraj lub jego część. Podróże poza granicami kraju należy podawać w oddzielnych plikach danych dla całego kontynentu. Jeśli plik danych GTFS obejmuje coś większego niż kraj, skontaktuj się z zespołem ds. transportu turystycznego.
  • Rozmiar plików w pliku ZIP GTFS nie powinien przekraczać 4 GB. Większe pliki są zwykle oznaką złych praktyk, takich jak ignorowanie opcji kompresji dostępnych w frequencies.txt lub podobnych. Może to powodować problemy podczas przetwarzania. Jeśli potrzebujesz plików większych niż 4 GB, skontaktuj się z zespołem ds. transportu publicznego, pisząc na adres [e-mail].
  • Dane dotyczące całego przyszłego okresu działania usług w pliku danych GTFS należy podawać przy każdej aktualizacji danych GTFS. Podział usług na segmenty według różnych okresów nie jest akceptowalny.
• Wszystkie daty dla danego operatora muszą znajdować się w jednym pliku danych.

Tłumaczenia

• Tłumaczenia można dostarczyć przez translations.txt. Będą one wymagane w krajach, w których:
  • Informacje dla użytkowników mogą być przekazywane przy użyciu innych skryptów lub skryptów w języku innym niż łaciński
  • Informacje dla użytkowników mogą być udostępniane w kilku językach lub w przypadku, gdy podmioty mogą używać różnych nazw w tych językach (np.Bruksela/Bruksela/Bruksela).
• Encje do przetłumaczenia
  • nazwy agencji/przystanków/tras
  • znaki podróży/stopy

Nazwy tras, krótkie nazwy podróży i znaki informacyjne

• Należy podawać znaki główne w przypadku wszystkich przejazdów w cenie trips.txt (jeśli znak główny pozostaje spójny przez cały czas trwania podróży) lub w stop_times.txt (jeśli znak nagłówkowy zmienia się na różnych etapach podróży).
• Znaki i oznaczenia powinny odpowiadać informacjom, które użytkownicy mogą znaleźć na ziemi. Mogą to być na przykład znaki główne umieszczone na pojeździe lub na szyldach.
• Jeśli trasa ma nazwę, należy ją podać w polu routes.txt w polu „long_name”.
• Jeśli trasa ma określony identyfikator numeryczny lub alfanumeryczny, który odnosi się do wszystkich przejazdów tą trasą i w obu kierunkach, należy podać ją w polu routes.txt jako Short_name.
• Jeśli podróże w obrębie trasy mają indywidualne identyfikatory (np. numery pociągów), należy je podawać jako krótkie nazwy podróży.
• W przypadku usług długodystansowych, które nie mają numerów ani nazw tras, wybór nazwy trasy staje się problematyczny. Ogólna wskazówka w takich sytuacjach jest taka, że połączenie nazwy trasy i znaku kierunkowego powinno ułatwić użytkownikowi jednoznaczne zidentyfikowanie pojazdu. Na przykład nazwa przewoźnika może być używana jako nazwa trasy, a miejsce docelowe podróży (jeśli jest wyświetlane w pojeździe) powinno być znakiem kierunkowym podróży.

Przykłady

• Kolejka Indian Railways Kamayani Express 11071 z Bombaju do Waranasi. Uwaga: numer 11071 wskazuje konkretną trasę pociągiem z Bombaju do Waranasi, a nie samą trasę.
  • routes.txt:
    • short_name: <puste>
    • Long_name: Kamayani Express
  • trips.txt:
    • try_short_name: 11071
    • znak główkowy: Varanasi
• Autobus z Buenos Aires do Kordoby obsługiwany przez Chevallier Bus. Uwaga: autobus obsługujący tę usługę nie wyświetla konkretnej nazwy trasy. Zamiast tego w dobrze widocznym miejscu wyświetla się nazwa agencji operacyjnej i jej miejsce docelowe. Ta podróż nie ma indywidualnego numeru/identyfikatora, która odróżniałaby ją od innych podróży obsługiwanych przez tę samą agencję lub obsługujących tę samą trasę. W takim przypadku można użyć słowa „Chevallier” zarówno jako nazwy agencji (w języku: agencies.txt), jak i trasy long_name (w języku: routes.txt). Jako cel podróży należy użyć znaku „trip_short_name”. trip_short_name powinien pozostać pusty.
  • routes.txt:
    • short_name: <puste>
    • Long_name: Chevallier
  • trips.txt:
    • try_short_name: <puste>
    • znak główkowy: Córdoba

Czasy zatrzymania

Zarówno godzina przyjazdu, jak i godzina odjazdu muszą być podane w polu stop_times.txt.

Struktura podróży

• Podróże na długie dystanse, które obsługują wiele miast lub obszarów, powinny być podawane w całości bez podziału na segmenty (np. A->B->C nie [A->B,A->C,B->C]), gdzie A, B, C to obszary miast. Na przykład autobus dalekobieżny z Buenos Aires do Kordoby, z przystankiem w Rosario, powinien być przedstawiony jako podróż z przesiadkami w tych 3 miastach, a nie jako 3 przejazdy „Buenos Aires – Rosario”, „Buenos Aires – Córdoba” czy „Rosario–Córdoba”.
• Jeśli dostawca danych nie może uzyskać informacji o prawidłowej strukturze podróży, możemy podać kilka osobnych podróży między miastami. Jeśli tego typu podróże między miastem mają wiele punktów rozpoczęcia lub transportu w obrębie miasta (obszaru miejskiego), segmentacja „stop-to-stop” jest niedozwolona. Wszystkie punkty odbioru i miejsca docelowe powinny być wymienione w jednej podróży.

Struktury stacji

W przypadku dużych stacji z wieloma platformami/przystaniami należy określić relacje stacja-platforma w kanale, a konkretne stacje/platformy – za pomocą pola platform_code w stops.txt. Pojazdy, które regularnie odjeżdżają z określonej zatoki lub platformy bądź do niej przyjeżdżają, powinny być powiązane z tą zatoką lub platformą w pliku danych GTFS. Jeśli platforma odlotu/przylotu lub zatoczka zmieni się w różnych dniach lub godzinach odlotu, te informacje można podać w czasie rzeczywistym w czasie rzeczywistym.

Lokalizacje stacji/przystanków

• W przypadku dużych stacji z wieloma platformami lub zatokami lokalizacja stacji powinna być ustawiona na lokalizację najbardziej widocznego wejścia dla pieszych (jeśli dworzec ma budynek lub budynek) albo poczekalnię dla pasażerów (w przypadku stacji na zewnątrz).
• W przypadku mniejszych przystanków po jednej stronie drogi lokalizacja przystanku powinna być wskazana w miejscu, w którym można zidentyfikować słupek autobusowy. Jeśli nie można zidentyfikować konkretnego słupa autobusowego, lokalizacja powinna znajdować się po właściwej stronie drogi oraz w pobliżu rzeczywistego miejsca wzdłuż drogi (najlepiej w promieniu 10 m), w którym pojazd się zatrzymuje.

Dodatkowe rozszerzenia GTFS

Wymagane tylko w przypadku partnerów, którzy chcą wyświetlać informacje o cenie i dostępności za pomocą interfejsów API partnerów.

Rozszerzenie sprzedaży biletów transportu publicznego Google

• Partnerzy powinni wdrożyć specyfikację rozszerzenia Google Transit Ticketing, która jest podzbiorem rozszerzenia GTFS-Ticketing.
• Oto wymagania dotyczące identyfikatorów wyświetlania biletów:
  • Identyfikatory sprzedaży biletów powinny być stabilne (tzn. z uzasadnionych powodów nie mogą się zmieniać rzadko). W przypadku zmiany identyfikatorów sprzedaży biletów wymagana będzie zgodność wsteczna (przez minimalny okres wynoszący co najmniej 1 tydzień).
  • Aby określić parametry SegmentKey w żądaniach do interfejsu API, wymagane są parametry ticketing_trip_id (w trips.txt) i ticketing_stop_id (w ticketing_identifiers.txt). Wartość zastępcza typu stop_sequence nie jest obsługiwana, ponieważ jest niestabilna.

GTFS-Fares v1

Dokumentacja statycznej GTFS określa opcjonalne pliki fare_attributes.txt i fare_rules.txt. Jeśli partner przeprowadzi integrację z interfejsami API, nie należy udostępniać tych plików.