Las actualizaciones de viaje ofrecen información sobre los cambios en el horario. Esperamos recibir actualizaciones de viaje para todos los viajes programados cuya duración se pueda ver en tiempo real. Estas actualizaciones brindan un horario de llegada o salida previsto para las paradas a lo largo de la ruta. Las actualizaciones de viaje también pueden brindar información en situaciones más complejas, por ejemplo, cuando se cancelan viajes o se agregan otros al horario, o incluso cuando se modifica la ruta.
Recordatorio: En GTFS, un viaje es una secuencia de dos o más paradas que tienen lugar a una hora específica.
Debe haber como máximo una actualización de viaje para cada viaje programado. En caso de que no haya ninguna actualización de viaje para un viaje programado, se concluirá que no hay datos en tiempo real disponibles para el viaje. El consumidor de datos no debe asumir que el viaje se está realizando a tiempo.
Actualizaciones de horario de paradas
Una actualización de viaje comprende una o más actualizaciones de los horarios de parada del vehículo, que se conocen como mensajes de StopTimeUpdate. Pueden proporcionarse para horarios de paradas pasados y futuros. Tienes permitido brindar horarios de paradas pasados, pero no es obligatorio que lo hagas. Los productores no deben brindar un valor de StopTimeUpdate pasado si se refiere a una parada con una hora de llegada programada en el futuro para un viaje específico (es decir, si el vehículo pasó por la parada antes de lo programado). De lo contrario, se concluirá que no hay una actualización para esa parada.
Por ejemplo, en el caso de que aparezcan los siguientes datos en el feed GTFS-rt:
- Parada 4: Prevista para las 10:18 a.m. (programada para las 10:20 a.m., es decir, 2 minutos más temprano)
- Parada 5: Prevista para las 10:30 a.m. (programada para las 10:30 a.m., es decir, a tiempo)
… no se puede brindar la predicción del feed para la Parada 4 hasta las 10:21 a.m., incluso si el autobús pasó por la parada a las 10:18 a.m. Si se brindara un valor de StopTimeUpdate del feed para la Parada 4 a las 10:18 a.m. o a las 10:19 a.m., y el horario de llegada programado es a las 10:20 a.m., el consumidor supondría que en ese momento no hay información en tiempo real disponible para la Parada 4 y que deberían utilizarse los datos de horarios de la especificación GTFS.
Cada valor de StopTimeUpdate está vinculado a una parada. Normalmente, esto se puede hacer usando un valor de stop_sequence de GTFS o un valor stop_id de GTFS. Sin embargo, en caso de que estés suministrando una actualización para un viaje sin un trip_id de GTFS, debes especificar stop_id, ya que stop_sequence no tiene valor. El valor de stop_id debe hacer referencia a stop_id en GTFS. Si en un viaje se usa el mismo stop_id más de una vez, se debe proporcionar el valor de stop_sequence en todos los mensajes StopTimeUpdate correspondientes a ese stop_id en ese viaje.
La actualización puede proporcionar una hora exacta para arrival o departure en una parada en StopTimeUpdate mediante StopTimeEvent.
Esto debe contener un time absoluto o un delay (es decir, la diferencia respecto del horario programado, expresada en segundos). El campo delay solo se puede utilizar en caso de que la actualización de viaje se refiera a un viaje de GTFS programado, y no a un viaje basado en la frecuencia. En este caso, el horario debe ser igual al horario programado + el retraso. También puedes especificar un valor de uncertainty de la predicción junto con StopTimeEvent. Eso se analiza más detalladamente en la sección Incertidumbre más abajo en la página.
Para cada StopTimeUpdate, la relación de programación predeterminada es scheduled. (Ten en cuenta que es diferente de la relación de programación para el viaje). Puedes cambiarla a skipped si la parada no se va a utilizar o a no data si solo tienes datos en tiempo real para una parte del viaje.
Las actualizaciones deben ordenarse por stop_sequence (o stop_ids en el orden en que ocurren en el viaje).
Si faltan una o más paradas a lo largo del viaje, la actualización se propaga a todas las paradas subsiguientes. Esto significa que, en caso de no haber otra información, al actualizar un horario de parada para una cierta parada, se cambiarán todas las paradas subsiguientes.
Ejemplo 1
Para un viaje con 20 paradas, una StopTimeUpdate con un retraso de llegada y de salida de 0 (StopTimeEvent) para el campo stop_sequence de la parada actual significa que el viaje cumple exactamente con el horario programado.
Ejemplo 2
Para la misma instancia de viaje, se proporcionan tres mensajes StopTimeUpdate:
- retraso de 300 segundos para la
stop_sequence3 - retraso de 60 segundos para la
stop_sequence8 - retraso de duración no especificada para la
stop_sequence10
Esto se interpretará de la siguiente manera:
- Los mensajes
stop_sequence1 y 2 tienen un retraso desconocido. - Los mensajes
stop_sequence3, 4, 5, 6 y 7 tienen un retraso de 300 segundos. - Los mensajes
stop_sequence8 y 9 tienen un retraso de 60 segundos. - Los mensajes
stop_sequencedel 10 al 20 tienen un retraso desconocido.
Descriptor de viajes
La información suministrada por el descriptor de viajes depende de la relación de programación del viaje que estás actualizando. Hay una serie de opciones que puedes configurar:
| Valor | Comentario |
|---|---|
Scheduled |
Este viaje se está realizando de acuerdo con un programa de GTFS o se asemeja lo suficiente como para seguir estando asociado a él. |
Added |
Se agregó este viaje, que no estaba programado. Por ejemplo, para hacer frente a la demanda o reemplazar un vehículo averiado. |
Unscheduled |
Este viaje está en curso y nunca se asocia con un programa. Por ejemplo, si no hay un horario y los autobuses operan en un servicio de traslados. |
Canceled |
Este viaje estaba programado, pero ahora se quitó. |
En la mayoría de los casos, debes proporcionar el trip_id del viaje programado en GTFS con el que se relaciona esta actualización.
Sistemas con valores trip_id repetidos
Los sistemas que usan valores trip_id repetidos, por ejemplo, los viajes modelados con archivos frequencies.txt, que son viajes basados en la frecuencia, el trip_id no es en sí un identificador único para un viaje en particular, ya que no cuenta con un componente de horario específico.
Para identificar de manera exclusiva esos viajes en un TripDescriptor, se debe proporcionar un conjunto de tres identificadores:
trip_idstart_timestart_date
Primero se debe publicar el identificador start_time y, luego, se debe utilizar ese mismo start_time en cada actualización de feed subsiguiente que se refiera al mismo viaje. Para indicar cualquier ajuste, se debe utilizar StopTimeUpdate. No es necesario que el identificador start_time haga referencia al horario exacto de salida desde la primera estación, aunque sí debe indicar un horario lo más cercano posible.
Por ejemplo, supongamos que el 25 de mayo de 2015 a las 10:00 decidimos que un viaje con un trip_id=T comenzará a las start_time=10:10:00; luego, brindamos esta información mediante un feed en tiempo real a las 10:01. A las 10:05, de repente no enteramos que el viaje no va a comenzar a las 10:10, sino a las 10:13. En nuestro nuevo feed en tiempo real, aún podemos identificar este viaje como (T, 2015-05-25, 10:10:00) y brindar una StopTimeUpdate con un horario de salida desde la primera parada a las 10:13:00.
Método alternativo para asociar viajes
Los viajes que no están basados en la frecuencia también se pueden identificar de manera exclusiva mediante un TripDescriptor, el cual incluye la combinación de los siguientes identificadores:
route_iddirection_idstart_timestart_date
donde start_time es la hora de inicio programada, según lo especificado en el horario estático, siempre que la combinación de ID provista se refiera a un único viaje.
Incertidumbre
La incertidumbre se aplica tanto al horario como al valor de retraso de una StopTimeUpdate.
La incertidumbre especifica, en términos generales, el error esperado en un retraso real como un número entero expresado en segundos (pero ten en cuenta que el significado estadístico preciso todavía no está definido). Es posible que la incertidumbre sea 0, por ejemplo, para los trenes conducidos bajo control de horarios por computadora.
Por ejemplo, un autobús de larga distancia que tiene un retraso estimado de 15 minutos y llega a su siguiente parada dentro de una ventana de error de 4 minutos (es decir, +2/-2 minutos) tendrá un valor de uncertainty de 240.