Para ofrecer a los usuarios de Google Transit un servicio sin interrupciones y datos precisos, se debe usar el modelo de especificación de feeds general para el transporte público (GTFS). Este modelo consiste en usar conjuntamente los feeds estáticos y en tiempo real para informar de la situación real del transporte público.
Conceptos básicos sobre el modelo de GTFS
- Feeds GTFS estáticos: después de que se envíe un feed a Google, el procesamiento tarda entre 24 y 48 horas, aunque el plazo puede ser más largo si Google detecta algún problema en el feed.
Los feeds GTFS estáticos sirven para informar de los horarios y las rutas de transporte público según se han planificado. Debes proporcionar el feed estático a Google con un mínimo de 2 días de antelación. Sin embargo, lo ideal sería que lo enviaras con una semana de antelación para tener cierto margen si Google detecta conflictos o cambios sospechosos en el feed que requieren una revisión humana. - Feeds GTFS en tiempo real: las actualizaciones proporcionadas a Google se reflejan de inmediato.
Los feeds GTFS en tiempo real sirven para informar en tiempo real del estado de los datos estáticos. Los datos en tiempo real permiten comunicar retrasos relativos a trayectos y paradas predefinidos en los datos estáticos teniendo en cuenta las posiciones de los vehículos y las actualizaciones de los trayectos. También permiten informar a los usuarios sobre alertas de servicio, como retrasos o interrupciones. - Aunque en el modelo de GTFS hay soluciones alternativas para activar y desactivar trayectos, también hay limitaciones porque no es posible añadir en menos de 2 días (en tiempo real) servicios que no estén definidos (como formas, rutas, o secuencias y horarios de paradas). El proceso para añadir servicios puede tardar en completarse entre 2 y 7 o más días, ya que los cambios se someten a una revisión humana para comprobar que no haya modificaciones sospechosas ni conflictivas.
- En un feed estático, puedes usar el archivo feed_info.txt para determinar previamente (con una antelación de entre 2 y 7 o más días) cuándo se deben publicar los cambios en los datos estáticos y asegurarte de que concuerden con los feeds en tiempo real. Para especificar las fechas entre las que el feed estático debe estar activo, utiliza los campos "feed_start_date" y "feed_end_date". Si la fecha del campo "feed_start_date" es posterior al día en que procesemos el feed, procesaremos el feed de todos modos y conservaremos la versión actual y una versión futura.
- Los feeds estáticos contienen los datos principales sobre las rutas, las paradas y la programación de los trayectos. Sin embargo, como se ha señalado más arriba, para modificarlos, hacen falta entre 2 y 7 días. A continuación, se indican las prácticas recomendadas para hacer cambios de programación.
Prácticas recomendadas para actualizar feeds estáticos y en tiempo real
En los servicios de transporte público terrestre pueden producirse alteraciones con diferentes duraciones, niveles de urgencia y tipos de entidad. En general, cualquier cambio en los datos principales, como las inclusiones, modificaciones o eliminaciones de paradas, rutas o trayectos, se debe llevar a cabo en el feed estático. No obstante, en algunos casos, especialmente si se trata de cambios temporales que se deben hacer de forma reactiva y rápida, hay métodos para aplicar cambios en el feed en tiempo real. En las tablas siguientes se indican las prácticas recomendadas para actualizar los datos del feed.
General:
| Estático (entre 2 y 7 o más días) | En tiempo real (aproximadamente 1 minuto) | |
|---|---|---|
| Añadir datos al feed | La mayoría de los cambios se pueden aplicar fácilmente. | En general, no es posible a menos que se añada mediante el campo "schedule_relationship" a una frecuencia existente. |
| Eliminar datos del feed | Las eliminaciones significativas se marcan como sospechosas y puede que el proceso de revisión tarde más. | El feed en tiempo real no es adecuado para las eliminaciones estáticas. Sin embargo, se recomienda configurar alertas para las eliminaciones temporales. |
| Modificar los datos del feed | La mayoría de los cambios se pueden aplicar fácilmente. | No se admite ni se recomienda. |
| Estático (entre 2 y 7 o más días) | En tiempo real (aproximadamente 1 minuto) | |
|---|---|---|
| Añadir | Añade el campo "shape_id" al trayecto del archivo "trips.txt" según tus preferencias. | No es posible. El campo "shape_id" es obligatorio. |
| Eliminar | Quita el campo "shape_id" de los trayectos del archivo "trips.txt" según tus preferencias. Puede que haya formas sin utilizar. | N/A |
| Modificar | Cambia la forma según tus preferencias. Los cambios se publican en 2 días. | N/A |
| Estático (entre 2 y 7 o más días) | En tiempo real (aproximadamente 1 minuto) | |
| Añadir |
Sí. Puede que se deban hacer los cambios adecuados en los archivos "stop_times.txt" y "trips.txt". Nota: Debido al proceso de revisión, los nombres de las paradas nuevas tardan cierto tiempo en mostrarse en Google Maps (más de 2 días). |
N/A |
| Eliminar | Posible. Asegúrate de que ningún archivo "stop_times" siga haciendo referencia a las paradas sin definir. |
Efecto de "NO_SERVICE" en alertas de servicio: la parada se evitará en cada trayecto que la incluya. También puede asignarse el valor "SKIPPED" al nombre del campo "schedule_relationship" del mensaje "StopTimeUpdate". |
| Modificar | Debido al exhaustivo proceso de revisión, las revisiones de paradas pueden tardar más de 2 días en mostrarse. | No. Solo se permite la eliminación. |
| Estático (entre 2 y 7 o más días) | En tiempo real (aproximadamente 1 minuto) | |
| Añadir | Añadir un archivo "stop_times" equivale a insertar una parada junto con un trayecto definido. Espera al menos 2 días para que se implementen los cambios. | No es posible. |
| Eliminar | Quita el archivo "stop_times" de los trayectos que quieras para eliminar las respectivas paradas de los trayectos. Espera al menos 2 días para que se implementen los cambios. | El campo "schedule_relationship" del mensaje "StopTimeUpdate" puede tener el valor "SKIPPED". |
| Modificar | Modifica el archivo "stop_times" como quieras. Los cambios se publican en 2 días. |
Básicamente, la posición del vehículo y la actualización del trayecto son el resultado de la modificación de los horarios de las paradas en tiempo real. Esto también se puede indicar mediante alertas de servicio, asignando al campo "effect" los valores "SIGNIFICANT_DELAY" y "MODIFIED_SERVICE". |
| Estático (entre 2 y 7 o más días) | En tiempo real (aproximadamente 1 minuto) | |
| Añadir |
Usa el archivo calendar_dates.txt para activar o desactivar el servicio explícitamente por fecha. Para definir excepciones a los patrones de servicio predeterminados que se han definido en el archivo calendar.txt, utiliza el archivo calendar_dates.txt junto con el archivo calendar.txt. Este es un buen método si el servicio suele ser regular y se le deben aplicar pocos cambios en fechas concretas (por ejemplo, para adaptarse a los servicios de eventos especiales o al horario escolar). Tarda 2 días en publicarse, pero no hace falta modificar demasiado el feed GTFS. Si el servicio ya existe en los trayectos, se requieren modificaciones de una sola línea. Se puede cambiar el servicio y el trayecto a la asignación 1:1 en la granularidad más baja. |
Usa los valores del campo "schedule_relationship" en el feed en tiempo real para añadir información sobre trayectos no planificados. La forma y la hora de parada se deben definir previamente partiendo de un trayecto presente en los archivos "shapes.txt" y "stop_times.txt". Si se usa el valor "ADDED", se copian los trayectos planificados con un campo "start_time" nuevo, siempre que el trayecto principal no tenga bloqueos de transferencia. Para que se puedan diferenciar los trayectos, es fundamental que el campo "start_time" sea coherente. El valor "ADDITIONAL_SERVICE" de las alertas de servicio se utiliza para indicar autobuses adicionales añadidos a líneas de servicio existentes. |
| Eliminar |
Elimina el trayecto y comprueba que has retirado todas las referencias a él de los archivos "frequencies.txt", "stop_times.txt", "trips.txt". Se publica en 2 días. También tienes la opción de eliminar las entradas correspondientes del archivo "calendar.txt" o añadir excepciones a "calendar_dates.txt". |
Para hacerlo, actualiza el trayecto asignando el valor "SKIPPED" al campo "schedule_relationship". También se puede indicar lo mismo al usuario asignando el valor "NO_SERVICE" o "REDUCED_SERVICE" al campo "effect" de una alerta. Utiliza un texto descriptivo. |
| Modificar |
Puedes cambiar los trayectos según sea necesario. También puedes optar por tener las entradas correspondientes en el archivo "calendar.txt" o añadir excepciones a "calendar_dates.txt". |
No se permite la modificación de las paradas de un trayecto. Sin embargo, los retrasos y las llegadas anticipadas se indican mediante actualizaciones de trayecto o de posición de vehículo. Se pueden bloquear paradas y tramos de un trayecto en tiempo real mediante alertas de servicio (consulta la información mencionada anteriormente). |
| Estático (entre 2 y 7 o más días) | En tiempo real (aproximadamente 1 minuto) | |
| Añadir | Para añadir una ruta, incluye una sola línea en el archivo "routes.txt". Sin embargo, esto no será visible hasta que se creen y se asignen los trayectos a la ruta mencionada, en el archivo "trips.txt". | No es posible ni se recomienda. |
| Eliminar | Elimina la ruta y comprueba que también has retirado los trayectos que hagan referencia a ella o que los has asignado a otra ruta. Se publica en 2 días. |
El valor "NO_SERVICE" detendría todos los trayectos relacionados con esta ruta. Las paradas que coinciden con otras rutas o trayectos no se ven afectadas. Nota: La eliminación de rutas en sí sigue siendo un concepto estático. |
| Modificar |
Puedes cambiar los trayectos según sea necesario. Nota: Los usuarios identifican las rutas con colores o nombres. No es recomendable cambiarlas con frecuencia. |
No es posible ni se recomienda. |
Más información sobre los feeds en tiempo real
Importante: No se admite ni se recomienda la modificación en tiempo real de las formas, las rutas ni los elementos principales de los feeds estáticos.
Se puede eliminar y añadir información en tiempo real. Para que esto sea posible, el feed estático debe incluir un esbozo de la ruta, el campo "stop_sequence" y una entrada en el archivo "stop_times.txt" (es decir, un trayecto que se pueda usar como modelo).
Se recomienda usar los archivos "calendar.txt" y "calendar_dates.txt" con imaginación. Por ejemplo, para estar preparado para días en los que puede nevar, especifica trayectos que no se muestren como activos, pero que puedan usarse en caso de contingencia. Dicho de otro modo, define los trayectos con antelación. Llegado el momento, se activará una opción de inhabilitación o habilitación basada en el feed en tiempo real (predeterminada).
Preguntas frecuentes
P: Ha habido un pequeño accidente en la parada X. Quiero cambiar las rutas cuanto antes para que pasen por la parada Y y eviten el accidente. ¿Es posible?R: Lo que podamos hacer dependerá de la fecha en que empiece el festival.
Si el festival empieza dentro de más de 2 días:
Usa el archivo "calendar_dates.txt" para quitar del servicio todos los trayectos actuales que se vayan a modificar durante el festival. También puedes añadir trayectos nuevos durante el mismo periodo. Como es difícil añadir paradas nuevas, esperamos que lo hayas planificado con tiempo suficiente (si es posible, con más de una semana de antelación). Puedes utilizar paradas que ya existan. Para modificar las paradas, sigue estos pasos:
- Crea entradas "calendar" y "calendar_date" (un nuevo campo "service_id") para los trayectos afectados que contengan las fechas habituales y las fechas excluidas.
- Indica los trayectos afectados en este nuevo calendario (campo "service_id").
- Crea las entradas de la tabla "calendar_dates" con un nuevo campo "service_id" para las fechas del evento en las que deben usarse las nuevas rutas especiales y versiones modificadas de los trayectos afectados.
- Crea trayectos y formas para las versiones modificadas de los trayectos afectados, además de rutas, trayectos y formas para las líneas de servicio especiales. Todos estos elementos deberían hacer referencia al campo "service_id" creado en el paso 3.
- Después del evento, restaura el formato de feed anterior.
Si el festival empieza dentro de menos de 2 días:
Podemos cancelar los trayectos que ya tengas; para comunicárnoslo, asigna el valor "MODIFIED_SERVICE" al campo "effect". Aunque no hay tiempo suficiente para introducir ficheros "stops.txt" ni "stop_times.txt" a los horarios de las rutas, podemos "añadir vehículos" a otras líneas para reflejar el servicio ampliado (incrementando la frecuencia o mediante un horario establecido).
R: ¿El feed estático ya tiene algún trayecto con los mismos campos "stop_sequence" que este trayecto? Si no es así, no podremos incorporarlo al índice en menos de 2 días.
Sin embargo, se puede actualizar un trayecto o definir una posición de vehículo en trayectos que tienen horas de inicio diferentes. Para hacerlo, añade el trayecto nuevo asignando el valor "ADDED" al campo "schedule_relationship". Este horario añadido usará las paradas del campo "trip_id" proporcionado, pero iniciará un trayecto a la nueva hora proporcionada en el campo "start_time".
Importante: Una vez que se han añadido los campos "start_time", "direction", "start_date" y "trip_id", no deben cambiar para mantener la referencia al trayecto. Esto no se permite en los trayectos con bloqueos de transferencia. El feed de actualización de trayecto o de posición de vehículo puede ser parecido al siguiente:
Este código de feed en tiempo real no es válido. Es solo un ejemplo.
# Información del encabezado
header {
# Especificación de la velocidad de la versión; actualmente "2.0"
gtfs_realtime_version: "2.0"
# Determina si el conjunto de datos es incremental o completo
incrementality: FULL_DATASET
# El momento en que este conjunto de datos se generó en el servidor
timestamp: 1284457468
}
# Se pueden incluir varias entidades en el feed
entity {
# Identificador único de la entidad
id: "add-a-trip"
# Tipo de entidad
trip_update {
trip {
# Selecciona qué entidad GTFS (trayecto) se verá afectada
Schedule_relationship: ADDED
trip_id: "tripid_of_trip_to_copy" # Definido en el modo estático
route_id: “routeid_of_trip_to_copy” # Definido en el modo estático.
# No debe contener transbordos en bloque.
start_time: “10:00:00” # Hora local en la que empieza este trayecto ad hoc
start_date: “20180201” # Fecha local en la que empieza este trayecto ad hoc
}
...
}
}