Per garantire un servizio continuo e dati accurati agli utenti di Google Transit, è necessario eseguire la modellazione GTFS (General Transit Feed Specification). Questa operazione si riferisce alla progettazione di feed statici e in tempo reale (RT) che funzionino insieme per indicare la situazione reale.
Nozioni di base sulla modellazione GTFS
- Feed GTFS statici: richiedono un tempo di elaborazione di 24-48 ore dopo l'invio a Google, anche se possono subire ritardi nel caso in cui vengono rilevati problemi.
Il feed GTFS statico è pensato per le programmazioni premeditate e le progettazioni di trasporto pubblico. Il feed statico deve essere fornito a Google con almeno due giorni di anticipo. Tuttavia, un periodo di tempo di una settimana è considerato ideale nel caso in cui Google rilevi conflitti o problemi sospetti nel feed che richiedono una revisione da parte di persone fisiche. - Feed GTFS in tempo reale: gli aggiornamenti forniti a Google vengono applicati immediatamente.
Il feed GTFS in tempo reale è progettato per indicare lo stato in tempo reale rispetto ai dati statici. Comunica i ritardi attraverso le posizioni dei veicoli e gli aggiornamenti delle corse o delle fermate predefinite nel feed statico. Inoltre, fornisce agli utenti avvisi di servizio (ritardi, interruzioni del servizio). - Sebbene esistano soluzioni alternative per attivare e disattivare le corse in GTFS, l'aggiunta di servizi non definiti (forma, sequenza delle fermate, orari delle fermate, percorso) in meno di due giorni (ossia in tempo reale) non è possibile. L'aggiunta di servizi richiede dai due ai sette giorni o più a causa di una procedura di revisione da parte di persone fisiche per la ricerca di conflitti o modifiche "sospette".
- Nel feed statico, puoi utilizzare feed_info.txt per predeterminare (con un anticipo da due a sette giorni o più) quando le modifiche al feed statico saranno pubblicate, in modo da garantire coerenza con i feed in tempo reale. Utilizza i campi feed_start_date e feed_end_date per specificare le date in cui il feed statico deve essere attivo. Se feed_start_date è nel futuro (in base alla data di elaborazione), continueremo a elaborare tale feed, ma conserveremo sia la versione corrente sia quella "futura".
- I feed statici contengono dati fondamentali su percorsi, fermate e programmazioni di corse ma, come indicato sopra, qualsiasi modifica ai feed statici richiede da due a sette giorni. Di seguito sono riportate le best practice per le modifiche della programmazione.
Best practice per l'aggiornamento dei feed statici e in tempo reale
Ai servizi di trasporto pubblico vengono apportate varie modifiche, tra cui durate, livelli di urgenza e tipi di entità diversi. In generale, eventuali modifiche ai dati principali, tra cui aggiunte, modifiche o eliminazioni di fermate, percorsi o corse devono essere eseguite nel feed statico. Tuttavia, per alcune modifiche, in particolare quelle temporanee che devono essere apportate in modo reattivo e veloce, esistono alcuni metodi per raggiungere questo risultato nel feed in tempo reale. Per le best practice per l'aggiornamento dei dati del feed, consulta le seguenti tabelle.
Generale:
| Statico (da due a sette giorni o più) | In tempo reale (circa un minuto) | |
|---|---|---|
| Aggiungi dati al feed | La maggior parte delle modifiche è possibile e immediata. | In generale non è possibile, a meno che non venga aggiunta a una frequenza esistente con schedule_relationship. |
| Elimina i dati dal feed | Le eliminazioni significative vengono contrassegnate come sospette e potrebbero essere soggette a una revisione più lunga. | Il feed in tempo reale non è adatto per le eliminazioni statiche. Tuttavia, si incoraggia l'utilizzo di avvisi per le eliminazioni temporanee. |
| Modifica i dati nel feed | La maggior parte delle modifiche è possibile e immediata. | Non supportato né incoraggiato. |
| Statico (da due a sette giorni o più) | In tempo reale (circa un minuto) | |
|---|---|---|
| Aggiungi | Aggiungi shape_id alla corsa esistente di trips.txt, se necessario. | Impossibile. Il valore di shape_id deve esistere. |
| Elimina | Rimuovi shape_id dalle corse esistenti di trips.txt, se necessario. Alcune forme potrebbero non essere utilizzate. | N/A |
| Modifica | Modifica la forma nel modo più appropriato. Le modifiche vengono pubblicate entro due giorni. | N/A |
| Statico (da due a sette giorni o più) | In tempo reale (circa un minuto) | |
| Aggiungi |
Sì. Potrebbe essere necessario aggiungere stop_times e modifiche alle corse. Suggerimento: a causa della revisione, la risoluzione dei nuovi nomi di fermate in Google Maps potrebbe richiedere un po' di tempo (almeno due giorni). |
N/D |
| Elimina | Possibile. Assicurati che stop_times non sia considerata una fermata indefinita. |
Effetto NO_SERVICE sull'avviso di servizio: la fermata verrà saltata in tutte le corse in cui è presente. In alternativa, la schedule_relationship di StopTimeUpdate potrebbe essere SALTATA. |
| Modifica | La risoluzione della revisione delle fermate potrebbe richiedere più di due giorni a causa di una procedura di revisione complessa. | No. È possibile solo l'eliminazione. |
| Statico (da due a sette giorni o più) | In tempo reale (circa un minuto) | |
| Aggiungi | Aggiungere uno stop_time equivale a inserire una fermata esistente insieme a una corsa definita. Le modifiche saranno pubblicate entro due giorni. | Impossibile. |
| Elimina | Rimuovi gli stop_times dalle corse (per rimuovere le rispettive fermate dalle corse). Le modifiche saranno pubblicate entro due giorni. | La schedule_relationship di StopTimeUpdate può essere SALTATA. |
| Modifica | Modifica il file stop_times nel modo appropriato. Le modifiche vengono pubblicate entro due giorni. |
In pratica, la posizione dei veicoli e l'aggiornamento della corsa sono orari delle fermate modificati in tempo reale. Anche gli avvisi di servizio con effetto SIGNIFICANT_DELAY e MODIFIED_SERVICE possono indicare questo. |
| Statico (da due a sette giorni o più) | In tempo reale (circa un minuto) | |
| Aggiungi |
Per attivare o disattivare in modo esplicito il servizio in base alla data, utilizza calendar_dates.txt. Utilizza calendar_dates.txt insieme a calendar.txt per definire le eccezioni agli schemi di servizio predefiniti specificati in calendar.txt. Se il servizio è in genere regolare, con alcune modifiche in determinate date (ad esempio per adeguarsi a eventi speciali o orari scolastici), questo è un approccio corretto. Sono necessari due giorni per la pubblicazione, ma non occorre apportare modifiche significative a GTFS. Se il servizio già esiste nella corsa, è necessaria una modifica di una riga. Il servizio e la corsa con la granularità più bassa possono essere effettuati per avere una mappatura 1:1. |
Utilizza i valori schedule_relationship per indicare i dati in tempo reale per le corse non pianificate. La forma e stop_time devono essere predefiniti in base a una corsa esistente. Con "ADDED" vengono copiate le corse pianificate con un nuovo valore start_time, a condizione che la corsa principale non preveda il cambio servizio senza discesa dei passeggeri. Un valore start_time coerente è fondamentale per distinguere le varie corse. ADDITIONAL_SERVICE negli avvisi di servizi viene utilizzato per descrivere l'aggiunta di altri autobus a linee esistenti. |
| Elimina |
Elimina la corsa e accertati che tutti i riferimenti siano rimossi (frequenze, stop_times, corse). La pubblicazione avviene entro due giorni. Un altro modo per raggiungere questo risultato consiste nel rimuovere le voci corrispondenti da calendar.txt o nell'aggiungere eccezioni a calendar_dates.txt. |
Un aggiornamento corsa con il campo schedule_relationship impostato su SKIPPED consente di ottenere questo risultato. Anche l'avviso con effetto NO_SERVICE o REDUCED_SERVICE indica questo all'utente. Utilizza un testo descrittivo. |
| Modifica |
Puoi modificare le corse in base alle tue esigenze. Un altro modo per raggiungere questo risultato consiste nell'aggiungere le voci corrispondenti a calendar.txt o eccezioni a calendar_dates.txt. |
La modifica delle fermate delle corse non è consentita, ma i ritardi e gli arrivi anticipati vengono indicati tramite un aggiornamento della corsa o la posizione del veicolo. Le fermate e le parti delle corse possono essere bloccate in tempo reale (vedi sopra) tramite avvisi di servizio. |
| Statico (da due a sette giorni o più) | In tempo reale (circa un minuto) | |
| Aggiungi | Per aggiungere un percorso, inserisci una singola riga a routes.txt. Tuttavia, sarà visibile solo dopo che le corse saranno state create e assegnate al suddetto percorso in trips.txt. | Impossibile né consigliato. |
| Elimina | Rimuovi il percorso e accertati che le corse di riferimento siano rimosse o assegnate ad altri percorsi. La pubblicazione avviene entro due giorni. |
NO_SERVICE arresta tutte le corse associate a questo percorso. Le fermate di questo percorso non sono interessate in caso di condivisione con altri percorsi o altre corse. Nota: l'eliminazione del percorso effettivo è ancora un concetto del feed statico. |
| Modifica |
Puoi modificare le corse in base alle tue esigenze. Suggerimento: gli utenti identificano i percorsi con colori o nomi. Si sconsiglia di effettuare modifiche frequenti. |
Impossibile né consigliato. |
Scopri di più sui feed in tempo reale
Nota: al momento, la modifica in tempo reale di forme o percorsi ed elementi fondamentali dei feed statici non è supportata né consigliata.
L'aggiunta e l'eliminazione in tempo reale sono possibili: per consentire queste operazioni, è necessario che nel feed statico siano presenti un'anteprima del percorso, una stop_sequence e uno stop_time (ossia una corsa da utilizzare come modello).
È incoraggiato un utilizzo creativo di calendar.txt e calendar_dates.txt. Ad esempio, per tenere conto dei giorni di neve, indica le corse che potrebbero non essere "in servizio", ma che potrebbero essere disponibili in altri casi futuri. In altre parole, definisci le corse in anticipo. In questo modo, è possibile "disattivare/attivare rapidamente le corse basate sul feed in tempo reale (impostazione predefinita)" al momento opportuno.
Domande frequenti
D: alla fermata X c'è un piccolo incidente. Vorrei evitarlo utilizzando la fermata Y il prima possibile. Posso farlo?R: la soluzione che possiamo offrire dipende da quando si svolgerà il festival.
Se il festival è tra più di due giorni:
Utilizza calendar_dates.txt per sospendere tutte le corse modificate esistenti per la durata del festival. Puoi anche aggiungere nuove corse per questo periodo. L'aggiunta di nuove fermate è complicata, quindi ci auguriamo che questa operazione sia stata pianificata (almeno con una settimana di anticipo). Puoi utilizzare le fermate esistenti. Per modificare le fermate, completa i seguenti passaggi:
- Crea un nuovo calendario e nuove voci calendar_date (nuovo service_id) per le corse esistenti interessate presenti nel calendario standard e in exclusion calendar_dates.
- Punta le corse interessate al nuovo calendario (service_id).
- Crea voci calendar_dates con un nuovo service_id per le date dell'evento da usare con nuovi percorsi speciali e versioni alternative delle corse interessate.
- Crea corse e forme alternative per le corse interessate. Crea anche percorsi, corse e forme per le linee di servizi speciali. Tutti questi elementi devono puntare al service_id creato al passaggio 3.
- Dopo l'evento, adotta nuovamente il formato di feed precedente.
Se mancano meno di due giorni al festival:
Possiamo annullare le corse esistenti e l'effetto MODIFIED_SERVICE è ideale per una comunicazione in merito. Non c'è abbastanza tempo per introdurre nuove fermate o stop_times nelle programmazioni dei percorsi. Tuttavia, possiamo "aggiungere veicoli" alle linee esistenti (programmate o basate sulla frequenza) per soddisfare una maggiore richiesta del servizio.
R. Il feed statico contiene già una corsa con le stesse stop_sequences? Se non la contiene, non è possibile crearla nell'indice in meno di due giorni.
Tuttavia, è possibile impostare un aggiornamento corsa o una posizione veicolo in riferimento a una corsa con orari di inizio diversi come corsa con campo schedule_relationship impostato su ADDED. Questa programmazione aggiunta utilizzerà le fermate di trip_id fornite, ma darà inizio a una corsa in corrispondenza della nuova start_time indicata.
Nota: start_time, direction, start_date e trip_id non devono essere modificati per mantenere invariato il riferimento alla corsa una volta aggiunta. Ciò non è consentito nelle corse che prevedono il cambio servizio senza discesa dei passeggeri. I feed relativi all'aggiornamento corsa e alla posizione veicolo potrebbero avere il seguente aspetto:
Questo non è un codice in tempo reale valido, ma solo un esempio.
# header information
header {
# version of speed specification. Currently "2.0"
gtfs_realtime_version: "2.0"
# determines whether dataset is incremental or full
incrementality: FULL_DATASET
# the moment where this dataset was generated on server
timestamp: 1284457468
}
# multiple entities can be included in the feed
entity {
# unique identifier for the entity
id: "add-a-trip"
# "type" of the entity
trip_update {
trip {
# selects which GTFS entity (trip) will be affected
Schedule_relationship: ADDED
trip_id: "tripid_of_trip_to_copy" #defined in Static
route_id: “routeid_of_trip_to_copy” # defined in Static.
# Must NOT contain block transfers.
start_time: “10:00:00” #the local time when this ad hoc trip starts
start_date: “20180201” #the local date when this ad hoc trip starts
}
...
}
}