Partner che forniscono feed in tempo reale: carica una pianificazione di fine anno 2021 prima della modifica del servizio. Scopri come caricare una pianificazione futura.

Nozioni di base su Google Transit

Modellazione GTFS: utilizzare i feed statici con i feed in tempo reale

Per garantire un servizio continuo e dati accurati agli utenti di Google Transit, è necessario modellare feed GTFS (General Transit Feed Specification). La modellazione GTFS si riferisce alla progettazione di feed statici e in tempo reale (RT) che funzionino insieme per trasmettere 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 vengano 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 si riflettono immediatamente.
    Il feed GTFS in tempo reale (RT)
    è progettato per indicare lo stato in tempo reale rispetto ai dati statici. Il feed RT 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, per 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 2 a 7 giorni o più)

In tempo reale (circa 1 minuto)

Aggiungi dati del 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 dati del feed

Le eliminazioni significative vengono contrassegnate come sospette e potrebbero essere soggette a una revisione più lunga.

Il feed RT non è adatto per le eliminazioni statiche. Tuttavia, si incoraggia l'utilizzo di avvisi per le eliminazioni temporanee.

Modifica dati del feed

La maggior parte delle modifiche è possibile e immediata.

Non supportato né incoraggiato.

ESPANDI TUTTO COMPRIMI TUTTO

Forme

 

Statico (da 2 a 7 giorni o più)

In tempo reale (circa 1 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/D

Modifica

Modifica la forma nel modo più appropriato. Le modifiche vengono pubblicate entro due giorni.

N/D

Fermate

 

Statico (da 2 a 7 giorni o più)

In tempo reale (circa 1 minuto)

Aggiungi

Sì. Potrebbe essere necessario aggiungere stop_times e modifiche alle corse.

Suggerimento: a causa della revisione, potrebbe essere necessario un certo periodo di tempo (almeno due giorni) affinché i nuovi nomi di fermate vengano risolti in Google Maps.

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.

Orari delle fermate

 

Statico (da 2 a 7 giorni o più)

In tempo reale (circa 1 minuto)

Aggiungi

Aggiungere 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 RT.

Anche gli avvisi di servizio con effetto

SIGNIFICANT_DELAY e 

MODIFIED_SERVICE possono indicare questo.

Corse

 

Statico (da 2 a 7 giorni o più)

In tempo reale (circa 1 minuto)

Aggiungi

calendar_dates.txt consente di attivare o disattivare in modo esplicito il servizio in base alla data.

 

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 RT 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 necessità.

 

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.

Percorsi

 

Statico (da 2 a 7 giorni o più)

In tempo reale (circa 1 minuto)

Aggiungi

L'aggiunta di un percorso richiede l'aggiunta di una riga singola in routes.txt. Tuttavia, la visibilità si ottiene solo dopo che le corse saranno state create e assegnate al percorso in trips.txt.

Non possibile né incoraggiato.

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 necessità. Suggerimento: gli utenti identificano i percorsi con colori o nomi. Si sconsiglia di effettuare modifiche frequenti.

Non possibile né incoraggiato.

Ulteriori informazioni sui feed in tempo reale

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 esempio).

È 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 RT (impostazione predefinita)" al momento opportuno.

Nota: al momento, la modifica in tempo reale di forme o percorsi ed elementi fondamentali dei feed statici non è supportata né consigliata.

Domande frequenti

ESPANDI TUTTO COMPRIMI TUTTO

D. Alla fermata X c'è un piccolo incidente. Vorrei evitarlo utilizzando la fermata Y il prima possibile. Posso farlo?

R. Possiamo sopprimere la fermata X (avvisi di servizio). Le corse salteranno questa fermata. L'aggiunta di Y alla programmazione non è possibile, ma si può utilizzare l'avviso sopra riportato per indicare la possibilità di usare una fermata intermedia.

D. Ci sarà il festival Y. Ci sono X nuove linee e alcuni cambiamenti importanti. Potete aiutarmi?

R. La soluzione che possiamo offrire dipende da quando si svolgerà il festival.

Se il festival è tra più di 2 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:

  1. 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.
  2. Punta le corse interessate al nuovo calendario (service_id).
  3. 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.
  4. 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.
  5. 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.

D. Vorrei aggiungere ora un nuovo percorso.

R. Siamo spiacenti, non è possibile.

D. Vorrei aggiungere ora una nuova corsa.

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 alla nuova ora start_time indicata.

Nota: start_time, direction, start_date e trip_id non devono essere alterati 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 RT 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
    }
    ...
  }
}

È stato utile?
Come possiamo migliorare l'articolo?

Hai bisogno di ulteriore assistenza?

Prova i passaggi successivi indicati di seguito:

Is there something we can help you with?

Chat with a member of Transit team

Ricerca
Cancella ricerca
Chiudi ricerca
App Google
Menu principale
Cerca nel Centro assistenza
true
82656
false