Cambios a GTFS en tiempo real

Introducción

La especificación GTFS en tiempo real no es definitiva. Por el contrario, es una especificación abierta, desarrollada y mantenida por la comunidad de empresas de transporte público, programadores y otros interesados que usan GTFS en tiempo real. Se espera que esta comunidad de productores y consumidores de datos de GTFS en tiempo real tenga propuestas para extender la especificación para habilitar nuevas funciones. Para ayudar a administrar ese proceso, se han establecido los siguientes procedimientos y directrices.

El esquema general para cambiar la especificación tiene una serie de pasos:

  1. Proponer un cambio en la lista de foros de debate de GTFS en tiempo real.
  2. Recibir comentarios y sugerencias de la comunidad de GTFS en tiempo real y reiterar el cambio propuesto.
  3. Encontrar al menos un productor y un consumidor de GTFS en tiempo real para implementar y probar el cambio propuesto.
  4. Enviar una solicitud de comentarios final sobre el cambio propuesto a la lista de foros de debate. Si no se identifican problemas pendientes luego del transcurso de una semana, la propuesta se adoptará oficialmente.

El grupo de foros de debate servirá como lugar principal para sugerir cambios a la especificación, de modo tal que los usuarios de GTFS en tiempo real puedan conocer y ofrecer comentarios sobre los cambios propuestos. Si la comunidad acuerda en forma general que la propuesta vale la pena y sigue los principios rectores de GTFS en tiempo real descritos a continuación, la propuesta se agregará oficialmente a la especificación. También solicitamos que cualquier cambio propuesto sea implementado por, al menos, un productor y un consumidor de GTFS en tiempo real, para poder verificar la viabilidad de ese cambio en la práctica.

Principios rectores

Para preservar la visión original de GTFS en tiempo real, se han establecido una serie de principios rectores que se deben tener en cuenta al extender la especificación:

Los feeds deben ser eficientes para producir y consumir en tiempo real

La información en tiempo real es un flujo de datos continuo y dinámico que necesariamente requiere procesamiento eficiente. Elegimos búferes de protocolo como la base para la especificación debido a que ofrecen un buen intercambio en términos de facilidad de uso para los programadores y en términos de eficiencia para transmitir datos. A diferencia de GTFS, no imaginamos que muchas agencias editarán feeds de GTFS en tiempo real de forma manual. La elección de búferes de protocolo refleja la conclusión de que la mayoría de los feeds GTFS en tiempo real se producirá y consumirá programáticamente.

La especificación hace referencia a la información de los pasajeros

Al igual que GTFS, GTFS en tiempo real se ocupa principalmente de la información de los pasajeros. Es decir, la especificación debe incluir, ante todo, información que pueda facilitar herramientas de gran potencia para los operadores. Potencialmente, existe una gran cantidad de información orientada a las operaciones que las empresas de transporte público pueden querer transmitir internamente entre los sistemas. GTFS en tiempo real no tiene ese propósito y potencialmente existen otros estándares de datos orientados a las operaciones que pueden ser más adecuados.

Los cambios a la especificación deben ser compatibles con versiones anteriores

Al agregar funciones a la especificación, queremos evitar realizar cambios que provoquen que los feeds existentes no sean válidos. No queremos crear más trabajo para los editores de feeds existentes hasta que ellos no deseen agregar funciones a sus feeds. Además, siempre que sea posible, queremos que los analizadores existentes puedan continuar leyendo las partes más antiguas de los feeds más nuevos. Las convenciones para extender los búferes de protocolo impondrán la compatibilidad con versiones anteriores hasta un cierto punto. Sin embargo, deseamos evitar cambios semánticos a los campos existentes que también puedan quebrar la compatibilidad con versiones anteriores.

No se recomiendan las funciones especulativas

Cada nueva función agrega complejidad a la creación y la lectura de los feeds. Por lo tanto, queremos ser cuidadosos para solo agregar funciones que sabemos que serán útiles. Idealmente, cualquier propuesta habrá sido probada generando datos para un sistema de transporte público real que utiliza la nueva función y escribiendo software para leerlos y mostrarlos.

Usaremos extensiones, descritas en la siguiente sección, para admitir nuevas funciones. Los productores y consumidores de GTFS en tiempo real primero pueden probar una nueva función en el espacio de la extensión. Cuando la función esté lista para la adopción oficial, agregaremos la función a la propia protodefinición oficial de GTFS en tiempo real.

Extensiones

Para facilitar la prueba de las nuevas funciones y permitir que los programadores agreguen información adicional a un feed GTFS en tiempo real, aprovecharemos la función Extensiones de búferes de protocolo. Las extensiones nos permiten definir un espacio de nombres en un mensaje de búfer de protocolo, donde los programadores externos pueden definir campos adicionales sin la necesidad de modificar la protodefinición original.

Cuando un programador tiene interés en extender la especificación de GTFS en tiempo real, debe ponerse en contacto con el grupo de foros de debate de GTFS en tiempo real y asignaremos el siguiente ID de extensión disponible, tomado progresivamente de una lista de números que comienza en 1000 y va subiendo, y documentado en la sección Registro de extensiones que se encuentra a continuación.

Estos ID de extensión asignados corresponden a los ID de etiqueta disponibles en el espacio de nombres de "extensión" para cada definición de mensaje de GTFS en tiempo real. Ahora que el programador tiene un ID de extensión asignado, usará ese ID cuando extienda todos y cada uno de los mensajes de GTFS en tiempo real. Incluso si el programador solo planea extender un único mensaje, el ID de extensión asignado se reservará para TODOS los mensajes.

Para un programador que extiende la especificación en lugar de agregar un único campo como una "cadena" o "int32" con su ID de extensión, el modelo preferido es definir un nuevo mensaje como "MyTripDescriptorExtension", extender el mensaje subyacente de GTFS en tiempo real con tu nuevo mensaje y luego colocar todos tus campos nuevos ahí. Esto tiene la ventaja de que puedes administrar campos dentro de tu mensaje de extensión de la manera que quieras, sin la necesidad de reservar un nuevo ID de extensión de la lista maestra.

message MyTripDescriptorExtension {
  optional string some_string = 1;
  optional bool some_bool = 2;
  ...
}
extend transit_realtime.TripDescriptor {
  optional MyTripDescriptorExtension my_trip_descriptor = YOUR_EXTENSION_ID;
}
  

Registro de extensiones

ID de extensión Programador Contacto Detalles
1000 OneBusAway onebusaway-developers https://github.com/OneBusAway/onebusaway/wiki/GTFS-Realtime-Resources
1001 New York City MTA mtadeveloperresources http://mta.info/developers/
1002 Google transit-realtime-partner-support@google.com Actualizaciones de transporte público en tiempo real de Google Maps
...

Historial de revisiones

12 de octubre de 2012

  • Se agregó el campo marca de tiempo al mensaje TripUpdate.

30 de mayo de 2012

  • Se agregaron detalles específicos a la especificación acerca de las Extensiones.

30 de noviembre de 2011

  • Se agregó un espacio de nombres de extensión del búfer de protocolo a los mensajes clave de GTFS en tiempo real para facilitar la escritura de las extensiones en la especificación.

25 de octubre de 2011

  • Se actualizó la documentación para aclarar que header_text y description_text de la alerta son valores de texto simple.

20 de agosto de 2011

  • Se actualizó la documentación para aclarar la semántica del mensaje de TimeRange.

22 de agosto de 2011

  • Versión inicial