Requisiti GTFS

Il partner deve fornire un feed GTFS che soddisfi tutte le specifiche standard, oltre a quelle elencate di seguito. Questo feed deve includere tutti gli itinerari che il partner vuole mostrare. Fornendo queste informazioni consentirai la visualizzazione su Google delle informazioni su programmi e percorsi. Tieni presente che un partner potrebbe 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 di feed GTFS: segui questa procedura per caricare il feed GTFS.

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

Requisiti aggiuntivi

Ambito

• Un singolo feed GTFS deve coprire un solo paese o una parte di un paese. I viaggi che attraversano i confini nazionali devono essere forniti in feed separati in tutto il continente. Se un feed GTFS copre più di un paese, contatta il team per il trasporto dei viaggi.
  • I file all'interno del file ZIP GTFS devono avere dimensioni inferiori a 4 GB. I file di dimensioni superiori di solito sono un segnale di prassi scorrette, ad esempio sono state ignorate le opzioni di compressione offerte da frequencies.txt o da funzionalità simili. Ciò potrebbe causare problemi durante l'elaborazione. Se pensi di aver bisogno di file di dimensioni superiori a 4 GB, contatta il team di Travel Transport all'indirizzo [e-mail].
  • I dati per l'intero periodo futuro di funzionamento dei servizi all'interno di un feed GTFS devono essere forniti con ogni aggiornamento dei dati GTFS. La segmentazione dei servizi in base a periodi di tempo diversi non è accettabile.
• Tutte le date di un determinato operatore devono essere contenute in un unico feed.

Translations

• Le traduzioni possono essere fornite tramite translations.txt e saranno obbligatorie nei paesi in cui:
  • Le informazioni agli utenti possono essere fornite in scritture diverse dal latino o in scritture diverse
  • Le informazioni agli utenti possono essere fornite in più lingue o nel caso in cui le persone possano utilizzare nomi diversi in tali lingue (ad es. Bruxelles/Bruxelles/Bruxelles)
• Entità da tradurre
  • nomi di agenzie/fermate/percorsi
  • indicatori della corsa/fermata

Nomi di percorsi, nomi brevi delle corse e indicazioni delle destinazioni

• Devono essere forniti indicatori della destinazione per tutte le corse in trips.txt (se rimane costante per tutta la durata della corsa) o in stop_times.txt (se cambia durante le diverse fasi della corsa).
• Gli indicatori della destinazione devono corrispondere alle informazioni che gli utenti potrebbero trovare a terra. Ad esempio, gli indicatori delle destinazioni esposti sul veicolo o sui cartelli.
• Quando una route ha un nome, deve essere fornito come long_name in routes.txt.
• Quando un percorso ha un numero specifico o un identificatore alfanumerico valido per tutte le corse del percorso e in entrambe le direzioni, deve essere fornito come short_name in routes.txt.
• Quando le corse all'interno del percorso hanno identificatori individuali (ad esempio, i numeri di treno), tali identificatori devono essere forniti come nomi brevi delle corse.
• Per i servizi a lunga distanza che non hanno numeri o nomi di route, scegliere un nome di route diventa problematico. La linea guida generale in questi casi è che una combinazione del nome del percorso e dell'indicatore della destinazione aiuti l'utente a identificare il veicolo in modo inequivocabile. Ad esempio, il nome dell'azienda operativa può essere utilizzato come nome del percorso, mentre la destinazione della corsa (se visualizzata sul veicolo) dovrebbe essere utilizzata come indicatore della destinazione della corsa.

Esempi

• Treno Indian Railways Kamayani Express 11071 da Mumbai a Varanasi. Nota: il numero 11071 indica un viaggio specifico in treno da Mumbai a Varanasi, non il percorso stesso.
  • routes.txt:
    • short_name: <vuoto>
    • long_name: "Kamayani Express"
  • trips.txt:
    • trip_short_name: 11071
    • Segnale della destinazione: Varanasi
• Un autobus da Buenos Aires a Córdoba effettuato da Chevallier Bus. Nota: sull'autobus che gestiva questo servizio non è visualizzato un nome di percorso particolare. Mostra invece il nome dell'agenzia operativa e la destinazione. Questa corsa specifica non ha un numero/identificatore individuale che la distingue dalle altre corse della stessa azienda o che offrono lo stesso percorso. In tal caso è accettabile utilizzare "Chevallier" sia come nome dell'azienda (in agencies.txt) sia come route long_name (in routes.txt). La destinazione deve essere utilizzata per l'indicatore della destinazione. La trip_short_name deve rimanere vuota.
  • routes.txt:
    • short_name: <vuoto>
    • long_name: "Chevallier"
  • trips.txt:
    • trip_short_name: <vuoto>
    • indicatore della destinazione: Córdoba

Orari delle fermate

Gli orari di arrivo e di partenza devono essere entrambi specificati in stop_times.txt.

Struttura del viaggio

• Le corse a lunga percorrenza che servono più città/aree devono essere fornite end-to-end senza segmentazione (ad es. A->B->C e non [A->B,A->C,B->C]), dove A, B, C sono aree cittadine. 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 viaggio 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 sia in grado di ottenere informazioni sulla struttura di corsa corretta, è possibile che vengano fornite corse segmentate da città a città caso per caso. Se queste corse da città a città hanno più punti di prelievo o di discesa all'interno di una città (area urbana), la segmentazione da fermata a fermata non è consentita: tutti i punti di partenza e di discesa devono essere elencati in una singola corsa.

Strutture di stazioni

Per le stazioni di grandi dimensioni con più piattaforme/baie, è necessario specificare nel feed le relazioni stazione-piattaforma e baie/piattaforme specifici tramite il campo platform_code in stops.txt. I veicoli che partono/arrivano regolarmente da una baia o piattaforma specifica devono essere collegati a tale baia o piattaforma nel feed GTFS. Se il binario di partenza/arrivo o la baia cambiano in giorni/orari di partenza diversi, queste informazioni possono essere fornite in GTFS in tempo reale.

Posizioni delle stazioni e delle fermate

• Per le stazioni di grandi dimensioni con più binari o baie, la posizione della stazione deve essere impostata in base alla posizione dell'ingresso pedonale più importante (se la stazione ha un edificio o una struttura) o alla posizione della zona di attesa dei passeggeri (per le stazioni esterne).
• Per le fermate più piccole sul lato della strada, la posizione di una fermata deve essere impostata sulla posizione del polo dell'autobus quando può essere identificata. Quando non è possibile identificare un polo specifico dell'autobus, la posizione deve essere posizionata sul lato corretto della strada e nelle vicinanze della posizione effettiva lungo la strada (preferibilmente entro 10 metri) in cui si ferma il veicolo.

Estensioni GTFS aggiuntive

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

Estensione Google Transit Ticketing

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

GTFS - Tariffe 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 del partner, questi file non devono essere forniti.