Wymagania GTFS

Partner powinien przesłać dane GTFS, które spełniają wszystkie standardowe specyfikacje oraz te wymienione poniżej. Plik danych powinien obejmować wszystkie plany podróży, które partner chce wyświetlać. Podanie tych informacji umożliwi wyświetlanie w Google informacji o rozkładach jazdy i trasach. Pamiętaj, że partner może udostępniać dodatkowe informacje o cenie i dostępności w przypadku niektórych lub wszystkich planów podróży w przesłanym pliku danych.

Wymagania domyślne

Statyczny plik GTFS – wszystkie domyślne wymagania są stosowane.

Sprawdzone metody GTFS – stosuj sprawdzone metody tak, jakby były wymagane.

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

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

Dodatkowe wymagania

Zakres

• Jeden plik danych GTFS musi obejmować jeden kraj lub jego część. Podróże, które przekraczają granice krajów, muszą być podawane w oddzielnych plikach danych obejmujących cały kontynent. Jeśli plik danych GTFS obejmuje obszar większy niż kraj, skontaktuj się z zespołem ds. transportu w Google.
  • Pliki w pliku ZIP GTFS powinny mieć rozmiar mniejszy niż 4 GB. Pliki większe niż ten rozmiar zwykle wskazują na nieprawidłowe praktyki, takie jak ignorowanie opcji kompresji oferowanych przez frequencies.txt lub podobne funkcje. Może to powodować problemy podczas przetwarzania. Jeśli uważasz, że potrzebujesz plików większych niż 4 GB, skontaktuj się z zespołem ds. podróży i transportu, pisząc na adres [e-mail].
  • Przy każdej aktualizacji danych GTFS należy podawać dane dotyczące całego przyszłego okresu działania usług w pliku danych GTFS. Podział usług na różne okresy nie jest akceptowany.
• Wszystkie daty dla danego operatora muszą być zawarte w jednym pliku danych.

Tłumaczenia

• Tłumaczenia mogą być dostarczane za pomocą translations.txt i będą wymagane w krajach, w których:
  • Informacje dla użytkowników mogą być podawane w różnych skryptach lub w skryptach innych niż łacińskie.
  • Informacje dla użytkowników mogą być podawane w wielu językach lub w przypadku, gdy podmioty mogą używać różnych nazw w tych językach (np.Bruksela/Brussel/Bruxelles).
• Encje do przetłumaczenia
  • nazwy agencji, przystanków i tras,
  • nagłówki przejazdu/przystanku,

Nazwy tras, krótkie nazwy przejazdów i tablice kierunkowe

• Kierunki muszą być podane dla wszystkich przejazdów w trips.txt(jeśli kierunek pozostaje niezmienny przez cały przejazd) lub w stop_times.txt (jeśli kierunek zmienia się na różnych etapach przejazdu).
• Tablice kierunkowe powinny odpowiadać informacjom, które użytkownicy mogą znaleźć na ziemi. Na przykład tablice kierunkowe wyświetlane na pojeździe lub na tablicach informacyjnych.
• Jeśli trasa ma nazwę, musi być ona podana jako long_name w pliku routes.txt.
• Jeśli trasa ma konkretny numer lub identyfikator alfanumeryczny, który odnosi się do wszystkich przejazdów na tej trasie w obu kierunkach, musi być podany jako short_name w pliku routes.txt.
• Jeśli przejazdy w ramach trasy mają indywidualne identyfikatory (np. numery pociągów), należy je podać jako krótkie nazwy przejazdów.
• W przypadku usług dalekobieżnych, które nie mają numerów ani nazw tras, wybranie nazwy trasy staje się problematyczne. Ogólna zasada w takich sytuacjach jest taka, że połączenie nazwy trasy i tablicy kierunkowej powinno pomóc użytkownikowi w jednoznacznym zidentyfikowaniu pojazdu. Na przykład nazwa przewoźnika może być używana jako nazwa trasy, a miejsce docelowe przejazdu (jeśli jest wyświetlane w pojeździe) powinno być używane jako nagłówek przejazdu.

Przykłady

• Pociąg Indian Railways Kamayani Express 11071 z Mumbai do Varanasi. Uwaga: numer 11071 identyfikuje konkretną podróż pociągiem z Mumbaju do Waranasi, a nie samą trasę.
  • routes.txt:
    • short_name: <empty>
    • long_name: Kamayani Express
  • trips.txt:
    • trip_short_name: 11071
    • headsign: Varanasi
• Autobus z Buenos Aires do Córdoby obsługiwany przez Chevallier Bus. Uwaga: autobus obsługujący tę usługę nie wyświetla nazwy konkretnej trasy. Zamiast tego wyświetla nazwę agencji obsługującej i miejsce docelowe. Ta konkretna podróż nie ma indywidualnego numeru ani identyfikatora, który odróżniałby ją od innych podróży obsługiwanych przez tę samą agencję lub na tej samej trasie. W takim przypadku można użyć nazwy „Chevallier” zarówno jako nazwy agencji (w polu agencies.txt), jak i długiej nazwy trasy (w polu routes.txt). W polu headsign należy użyć nazwy miejsca docelowego. Pole trip_short_name powinno pozostać puste.
  • routes.txt:
    • short_name: <empty>
    • long_name: Chevallier
  • trips.txt:
    • trip_short_name: <empty>
    • tablica kierunkowa: Córdoba

Czasy zatrzymania

W przypadku atrybutu stop_times.txt należy podać zarówno czas przyjazdu, jak i czas odjazdu.

Struktura podróży

• Podróże na długich dystansach obejmujące wiele miast lub obszarów powinny być podawane w całości, bez podziału na segmenty (np. A–>B–>C, a nie [A–>B, A–>C, B–>C]), gdzie A, B, C to obszary miejskie. Na przykład autobus dalekobieżny, który jedzie z Buenos Aires do Córdoby i zatrzymuje się w Rosario, powinien być reprezentowany jako podróż z przystankami w tych trzech miastach, a nie jako trzy podróże: „Buenos Aires – Rosario”, „Buenos Aires – Córdoba” i „Rosario – Córdoba”.
• W przypadkach, gdy dostawca danych nie może uzyskać informacji o prawidłowej strukturze podróży, podzielone podróże między miastami mogą być udostępniane w poszczególnych przypadkach. Jeśli takie przejazdy między miastami mają wiele punktów odbioru lub wysiadania w mieście (obszarze miejskim), segmentacja od przystanku do przystanku jest niedozwolona – wszystkie punkty odbioru i wszystkie punkty wysiadania powinny być wymienione w ramach jednego przejazdu.

Obiekty stacji

W przypadku dużych stacji z wieloma peronami lub stanowiskami w pliku danych należy określić relacje między stacją a peronem, a konkretne stanowiska lub perony muszą być identyfikowane za pomocą pola platform_code w stops.txt. Pojazdy, które regularnie odjeżdżają z określonego stanowiska lub peronu albo na nie przyjeżdżają, powinny być powiązane z tym stanowiskiem lub peronem w danych GTFS. Jeśli peron lub stanowisko odjazdu lub przyjazdu zmienia się w różnych dniach i godzinach odjazdu, te informacje można podać w GTFS w czasie rzeczywistym.

Lokalizacje stacji/przystanków

• W przypadku dużych stacji z wieloma peronami lub stanowiskami lokalizacja stacji powinna być ustawiona na lokalizację jej najbardziej widocznego wejścia dla pieszych (jeśli stacja ma budynek lub konstrukcję) lub na lokalizację poczekalni dla pasażerów (w przypadku stacji na zewnątrz).
• W przypadku mniejszych przystanków przy drodze lokalizacja przystanku powinna być ustawiona na lokalizację słupka przystankowego, jeśli można go zidentyfikować. Jeśli nie można zidentyfikować konkretnego słupka przystankowego, lokalizację należy umieścić po właściwej stronie drogi, w pobliżu rzeczywistego miejsca, w którym zatrzymuje się pojazd (najlepiej w odległości do 10 m).

Dodatkowe rozszerzenia GTFS

Wymagane tylko w przypadku partnerów, którzy chcą wyświetlać informacje o cenie lub dostępności, wdrażając interfejsy API partnera.

Rozszerzenie sprzedaży biletów w Transporcie publicznym Google

• Partnerzy powinni wdrożyć specyfikację rozszerzenia sprzedaży biletów Transportu publicznego Google, która jest podzbiorem rozszerzenia GTFS-Ticketing.
• Wymagania dotyczące identyfikatorów biletów:
  • Identyfikatory zgłoszeń powinny być stałe (tzn. mogą się rzadko zmieniać z uzasadnionych powodów). W przypadku zmiany identyfikatorów biletów wymagana będzie wsteczna zgodność (przez co najmniej 1 tydzień).
  • Aby określić parametry klucza segmentu w żądaniach interfejsu API, ticketing_trip_id (w trips.txt) i ticketing_stop_id (w ticketing_identifiers.txt) są wymagane. Wycofanie się z stop_sequence jest nieobsługiwane, ponieważ nie jest stabilne.

GTFS-Fares w wersji 1

Specyfikacja statycznego GTFS określa opcjonalne pliki fare_attributes.txt i fare_rules.txt. Jeśli partner korzysta z interfejsów API partnera, nie należy przesyłać tych plików.