Requisiti GTFS

Il partner deve fornire un feed GTFS che soddisfi tutte le specifiche standard, oltre a quelle elencate di seguito. Questo feed deve coprire tutti gli itinerari che il partner vuole mostrare. La fornitura di queste informazioni consentirà di visualizzare le informazioni su orari e percorsi su Google. Tieni presente che un partner può scegliere di mostrare informazioni aggiuntive su prezzi e disponibilità per alcuni o tutti gli itinerari nel feed fornito, se lo desidera.

Requisiti predefiniti

Riferimento GTFS statico: vengono applicati tutti i requisiti predefiniti.

Best practice GTFS: segui le best practice come se fossero obbligatorie.

Caricamento dei feed GTFS - segui questa procedura per caricare il feed GTFS.

Aggiornamenti: tieni presente che, una volta caricati, i feed possono essere aggiornati seguendo la procedura descritta qui. In genere, la propagazione completa di questi aggiornamenti dei feed può richiedere 2-3 giorni.

Requisiti aggiuntivi

Ambito

  • Un singolo feed GTFS deve coprire un singolo paese o una parte di un paese. I viaggi che attraversano i confini nazionali devono essere forniti in feed separati a livello di continente. Se un feed GTFS copre un'area più grande di un paese, contatta il team di trasporto di Travel.
    • Le dimensioni dei file all'interno del file ZIP GTFS devono essere inferiori a 4 GB. I file di dimensioni maggiori in genere indicano pratiche errate, ad esempio l'ignoranza delle opzioni di compressione offerte da frequencies.txt o funzionalità simili. Ciò potrebbe causare problemi durante l'elaborazione. Se ritieni di aver bisogno di file di dimensioni superiori a 4 GB, contatta il team di trasporto di Travel all'indirizzo transport-help@google.com.
    • Con ogni aggiornamento dei dati GTFS, devono essere forniti i dati per l'intero periodo futuro di funzionamento dei servizi all'interno di un feed GTFS. La segmentazione dei servizi in base a periodi di tempo diversi non è accettabile.
  • Tutte le date per un determinato operatore devono essere contenute in un singolo feed.

Traduzioni

  • Le traduzioni possono essere fornite utilizzando translations.txt e saranno obbligatorie nei paesi in cui:
    • Le informazioni per gli utenti possono essere fornite in script diversi o in script diversi dal latino.
    • Le informazioni per gli utenti possono essere fornite in più lingue o in cui le entità possono utilizzare nomi diversi in queste lingue (ad es.Bruxelles/Brussel/Bruxelles).
  • Entità da tradurre:
    • Nomi di aziende di trasporto, fermate e percorsi
    • Indicatori delle destinazioni delle corse e delle fermate

Nomi dei percorsi, nomi brevi delle corse e indicatori delle destinazioni

  • Gli indicatori delle destinazioni devono essere forniti per tutte le corse in trips.txt (se l'indicatore rimane coerente durante la corsa) o in stop_times.txt (se l'indicatore cambia durante le diverse fasi della corsa).
  • Gli indicatori delle destinazioni devono corrispondere alle informazioni che gli utenti possono trovare sul posto. Ad esempio, gli indicatori delle destinazioni visualizzati sul veicolo o sui cartelli.
  • Quando un percorso ha un nome, questo deve essere fornito come long_name in routes.txt.
  • Quando un percorso ha un numero o un identificatore alfanumerico specifico che si applica a tutte le corse su quel percorso e in entrambe le direzioni, questo deve essere fornito come short_name in routes.txt.
  • Quando le corse all'interno del percorso hanno identificatori individuali (ad esempio, numeri di treni), questi identificatori devono essere forniti come nomi brevi delle corse.
  • Per i servizi a lunga distanza che non hanno numeri o nomi di percorso, la scelta di un nome di percorso diventa problematica. La linea guida generale in queste situazioni è che una combinazione del nome del percorso e dell'indicatore della destinazione deve aiutare l'utente a identificare il veicolo in modo univoco. Ad esempio, il nome dell'azienda di trasporto può essere utilizzato come nome del percorso, mentre la destinazione della corsa (se visualizzata sul veicolo) deve essere utilizzata come indicatore della destinazione della corsa.

Esempi

  • Treno Kamayani Express 11071 delle Ferrovie indiane da Mumbai a Varanasi. Nota: il numero 11071 identifica una corsa in treno specifica da Mumbai a Varanasi, non il percorso stesso.
    • routes.txt:
      • short_name: <empty>
      • long_name: Kamayani Express
    • trips.txt:
      • trip_short_name: 11071
      • headsign: Varanasi
  • Un autobus da Buenos Aires a Córdoba gestito da Chevallier Bus. Nota: l'autobus che ha operato questo servizio non mostra un nome di percorso specifico. Mostra invece in modo ben visibile il nome dell'azienda di trasporto e la sua destinazione. Questa corsa specifica non ha un numero/identificatore individuale che la distingua dalle altre corse gestite dalla stessa azienda o che servono lo stesso percorso. In questo caso, è accettabile utilizzare "Chevallier" sia come nome dell'azienda di trasporto (in agencies.txt) sia come long_name del percorso (in routes.txt). La destinazione deve essere utilizzata per l'indicatore della destinazione. trip_short_name deve rimanere vuoto.
    • routes.txt:
      • short_name: <empty>
      • long_name: Chevallier
    • trips.txt:
      • trip_short_name: <empty>
      • headsign: Córdoba

Orari delle fermate

Sia arrival_time che departure_time devono essere forniti in stop_times.txt.

Struttura del viaggio

  • Le corse a lunga distanza che servono più città/aree devono essere fornite end-to-end senza segmentazione (ad es. A->B->C non [A->B,A->C,B->C]), dove A, B, C sono aree urbane. Ad esempio, un autobus a lunga distanza che viaggia da Buenos Aires a Córdoba, con una fermata a Rosario, deve essere rappresentato come una corsa con fermate in queste tre città, non come tre corse "Buenos Aires - Rosario", "Buenos Aires - Córdoba" e "Rosario - Córdoba".
  • Nei casi in cui il fornitore di dati non è in grado di ottenere le informazioni sulla struttura corretta della corsa, le corse segmentate da città a città possono essere fornite caso per caso. Se queste corse da città a città hanno più punti di carico o di rilascio all'interno di una città (area urbana), la segmentazione da fermata a fermata non è consentita: tutti i punti di carico e tutti i punti di rilascio devono essere elencati in una singola corsa.

Strutture delle stazioni

Per le stazioni di grandi dimensioni con più binari/banchine, le relazioni tra stazione e binario devono essere specificate nel feed e le banchine/i binari specifici devono essere identificati tramite il campo platform_code in stops.txt. I veicoli che partono o arrivano regolarmente a una banchina o a un binario specifico devono essere collegati a quella banchina o a quel binario nel feed GTFS. Se la banchina o il binario di partenza o di arrivo cambia in base ai giorni/orari di partenza, queste informazioni possono essere fornite in GTFS in tempo reale.

Posizioni delle stazioni/fermate

  • Per le stazioni di grandi dimensioni con più binari o banchine, la posizione della stazione deve essere impostata sulla posizione dell'ingresso pedonale più importante (se la stazione ha un edificio o una struttura) o sulla posizione dell'area di attesa dei passeggeri (per le stazioni all'aperto).
  • Per le fermate più piccole sul lato della strada, la posizione di una fermata deve essere impostata sulla posizione del palo dell'autobus quando è possibile identificarne uno. Quando non è possibile identificare un palo dell'autobus specifico, la posizione deve essere posizionata sul lato corretto della strada e nelle vicinanze della posizione effettiva lungo la strada (idealmente, entro 10 metri) in cui il veicolo si ferma.

Estensioni GTFS aggiuntive

Obbligatorio solo per i partner che vogliono mostrare informazioni su prezzi/disponibilità implementando le API partner.

Estensione per l'acquisto di biglietti di Google Transit

  • I partner devono implementare la specifica dell'estensione per l'acquisto di biglietti di Google Transit , che è un sottoinsieme dell'estensione per l'acquisto di biglietti GTFS.
  • Imponiamo i seguenti requisiti per gli ID per l'acquisto di biglietti:
    • Gli ID per l'acquisto di biglietti devono essere stabili (ovvero possono essere modificati di rado, per un buon motivo). Nei casi in cui gli ID per l'acquisto di biglietti cambiano, sarà necessaria la compatibilità con le versioni precedenti (per un periodo minimo di almeno una settimana).
    • Per determinare i parametri di SegmentKey nelle richieste API, ticketing_trip_id (in trips.txt) e ticketing_stop_id (in ticketing_identifiers.txt) sono obbligatori. Il fallback su stop_sequence non è supportato perché non è stabile.

GTFS-Fares v1

Il riferimento GTFS statico specifica i file facoltativi fare_attributes.txt e fare_rules.txt. Se un partner esegue l'integrazione con le API partner, questi file non devono essere forniti.