Actualizaciones de viaje

Las actualizaciones de viaje ofrecen información sobre los cambios en el horario. Esperamos recibir actualizaciones de viaje para todos los viajes que has programado, que sean aptos para tiempo real. Estas actualizaciones brindarían un horario de llegada o salida previsto para las paradas a lo largo de la ruta. Las actualizaciones de viaje también pueden prever escenarios más complejos en los cuales se cancelen o agreguen viajes al programa, o incluso se modifique su recorrido.

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 suponer 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 StopTimeUpdates. 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 brindase un valor de StopTimeUpdate del feed para la Parada 4 a las 10:18 a.m. o a las 10:19 a.m. y la hora de llegada programada es a las 10:20 a.m., el consumidor supondría que en ese no 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 GTSF.

Cada actualización de StopTimeUpdate está vinculada a una parada. Normalmente, esto se puede hacer usando un GTFS stop_sequence o un GTFS stop_id. Sin embargo, en caso de que estés suministrando una actualización para un viaje sin un trip_id de GTFS, debes especificar el stop_id ya que stop_sequence no tiene valor. El stop_id todavía debe hacer referencia a un 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 todas las actualizaciones de StopTimeUpdates correspondientes a ese stop_id en ese viaje.

La actualización puede proporcionar una hora exacta de llegada o de salida en una parada en StopTimeUpdates mediante StopTimeEvent. Esto debe contener un horario absoluto o un retraso (es decir, la diferencia respecto del horario programado, expresada en segundos). El retraso solo se puede utilizar en caso de que la actualización de viaje se refiera a un viaje de GTFS programado, en contraposición con un viaje basado en la frecuencia. En este caso, el horario debe ser igual al horario programado + el retraso. También puedes especificar la incertidumbre 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 parte del viaje.

Las actualizaciones se deben clasificar por stop_sequence (o stop_id, en el orden en que tienen lugar 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 (StopTimeEvents) en el campo stop_sequence de la parada actual significa que el viaje cumple exactamente con el horario esperado.

Ejemplo 2

Para la misma instancia de viaje, se proporcionan tres StopTimeUpdates:

  • retraso de 300 segundos para la stop_sequence 3
  • retraso de 60 segundos para la stop_sequence 8
  • retraso de duración no especificada para la stop_sequence 10

Esto se interpretará de la siguiente manera:

  • Las stop_sequences 1, 2 tienen un retraso desconocido.
  • Las stop_sequences 3, 4, 5, 6, 7 tienen un retraso de 300 segundos.
  • Las stop_sequences 8,9 tienen un retraso de 60 segundos.
  • Las stop_sequences 10,..,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á ejecutando de acuerdo con un programa de GTFS o se asemeja lo suficiente como para seguir estando asociado a él.
Added Este viaje no estaba programado y se ha agregado. Por ejemplo, para hacer frente a la demanda o reemplazar un vehículo averiado.
Unscheduled Este viaje se está ejecutando y nunca se asocia con un programa. Por ejemplo, si no hay programa 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 trip_id repetidos

Los sistemas que utilizan trip_id repetidos, por ejemplo, los viajes armados con archivos frequencies.txt (es decir, los viajes basados en frecuencias), 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 dichos viajes en un TripDescriptor, se debe proporcionar un conjunto de tres identificadores:

  • trip_id
  • start_time
  • start_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 StopTimeUpdates. El identificador start_time no debe indicar el horario de partida exacto 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 feed en tiempo real nuevo aún podemos identificar este viaje como (T, 25/05/2015, 10:10:00) y brindar una StopTimeUpdate con un horario de salida de la primera parada a las 10:13:00.

Coincidencia de viaje alternativa

Los viajes que no están basados en frecuencias también se pueden identificar de manera exclusiva mediante un TripDescriptor, el cual incluye la combinación de los siguientes identificadores:

  • route_id
  • direction_id
  • start_time
  • start_date

donde start_time es el horario de comienzo programado, 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 retraso verdadero como un entero 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 incertidumbre de 240.