Selezionare una corsa con TripDescriptor

Importante: per la durata della corsa, non modificare TripDescriptor che viene utilizzato per la selezione di una singola corsa.

Per collegare una corsa in tempo reale al relativo prototipo General Transit Feed Specification (GTFS), viene utilizzato il messaggio secondario TripDescriptor. Questo articolo spiega in che modo selezionare una corsa per schedule_relationship come "SCHEDULED" o "CANCELED".

Aggiungere o associare una corsa

Per aggiungere una corsa in tempo reale con schedule_relationship come "ADDED", consulta Aggiungere una corsa in tempo reale.

Per creare una corrispondenza tra una corsa in tempo reale a un set di dati statico, includi una tupla in TripDescriptor:

• trip_id
• start_time
• start_date

Se non hai il trip_id, puoi sostituirlo con route_id e direction_id. Per creare corrispondenze corrette, i campi start_time e start_date sono obbligatori.

Specificare TripDescriptor per gli orari basati o meno sulla frequenza

TripDescriptor non basati sulla frequenza

• Entrambi i campi trip_id e start_date sono obbligatori per identificare una corsa dall'orario statico. Il campo start_time è facoltativo. Se fornito, deve corrispondere a uno degli orari di inizio della corsa nella data di inizio indicata nell'orario statico.
• Se non puoi fornire trip_id, devi specificare <route_id, direction_id e start_date>.
  • Affinché il metodo di corrispondenza di route_id e direction_id funzioni, il feed statico GTFS deve includere valori direction_id. Questo metodo non è supportato correttamente perché viene applicato al meglio delle possibilità nel singolo caso ed è soggetto a modifiche.

Codice di esempio

trip_update {

    trip {

      trip_id: "non_frequency-expanded-trip"

      start_date: "20160203"

    }

  }

trip_update {

    trip {

      route_id: "route1"

      direction_id: 0

      start_time: "10:10:00"

      start_date: "20160203"

    }

}

TripDescriptor basati sulla frequenza

Le corse basate sulla frequenza vengono definite utilizzando il file frequencies.txt. Per questi tipi di corse, il campo start_time è obbligatorio perché per identificare una singola corsa è richiesto un componente temporale specifico.

• Per identificare una corsa da un orario statico, è necessaria una tupla costituita da trip_id, start_date e start_time. Se una o più informazioni sono assenti, faremo del nostro meglio per trovare una corrispondenza con una corsa.
• Se non puoi fornire trip_id, devi specificare route_id, direction_id, start_date e start_time. Affinché il metodo di corrispondenza di route_id e direction_id funzioni, il feed statico GTFS deve includere valori direction_id. Questo metodo di corrispondenza non è supportato correttamente.

Quando specifichi un valore start_time, tieni presente quanto segue:

• Il campo start_time deve corrispondere all'ora di inizio programmata del set di dati statico.
• Il campo start_time deve essere identico in tutti i TripDescriptor che rappresentano la stessa corsa in tutti i gruppi di feed.
• Non modificare il campo start_time per indicare aggiustamenti all'orario della prima partenza per la prima fermata. Utilizza invece StopTimeUpdates.
• Il valore di start_time dovrebbe essere vicino all'ora di partenza dalla prima stazione, ma non necessariamente uguale.

Suggerimento: quando trip_id e start_time rientrano in un intervallo exact_time=1, il valore di start_time deve essere successivo all'inizio dell'intervallo di un multiplo esatto di headway_secs.

Esempio

Alle 10:00 del 25 maggio 2015 definiamo che una corsa con trip_id=T avrà inizio alle start_time=10:10:00. Forniamo queste informazioni tramite feed in tempo reale alle 10:01. Alle 10:05 ci rendiamo conto che la corsa inizierà alle 10:13 anziché alle 10:10. Nel nostro nuovo feed in tempo reale, possiamo comunque identificare questa corsa come (T, 2015-05-25, 10:10:00), ma dobbiamo fornire uno StopTimeUpdate con partenza dalla prima fermata alle 10:13:00.

Se start_time viene modificato, potrebbe determinare la dichiarazione di una seconda partenza dell'autobus. In questo scenario, una partenza è alle 10:10, mentre l'altra è dichiarata alle 10:13.

Codice di esempio:

trip_update {

    trip {

         trip_id: “T”

         start_date: "20150525"

         start_time: "10:10:00"

    }

    stop_time_update {

      stop_sequence: 1

      departure {

        delay: 180

      }

    }

}