GTFS

GTFS o la Especificación General de Fuentes de Tránsito define un formato de datos común para los horarios de transporte público y la información geográfica asociada. ^[1] GTFS contiene solo información estática o programada sobre los servicios de transporte público y, a veces, se lo conoce como GTFS Estático o GTFS Horario para distinguirlo de la extensión GTFS en Tiempo Real , que define cómo se puede compartir la información sobre el estado en tiempo real de los servicios. ^{[1] [2]}

Lo que luego se convertiría en GTFS comenzó como un proyecto paralelo del empleado de Google Chris Harrelson en 2005, quien "jugó con formas de incorporar datos de tránsito en Google Maps cuando escuchó de Tim y Bibiana McHugh, gerentes de TI casados ​​en TriMet , la agencia de tránsito de Portland , Oregon". ^[3] Se dice que McHugh se sintió frustrado por encontrar direcciones de tránsito en ciudades desconocidas, mientras que los servicios de mapas populares ya ofrecían instrucciones de manejo fáciles de usar en ese momento. ^[4]

Finalmente, Bibiana y Tim McHugh se pusieron en contacto con Google y le proporcionaron a la empresa exportaciones en formato CSV de los datos de horarios de TriMet. En diciembre de 2005, Portland se convirtió en la primera ciudad que apareció en la primera versión del "Planificador de viajes en tránsito" de Google. ^[5] En septiembre de 2006, se añadieron cinco ciudades estadounidenses más al Planificador de viajes en tránsito de Google y el formato de datos se publicó como Especificación de feeds de tránsito de Google . ^[6]

En los Estados Unidos , no había ningún estándar para los horarios de transporte público antes de la llegada de GTFS, ni siquiera un estándar de facto . Según Timothy Moore, administrador del sitio web de BART desde hace mucho tiempo , antes de la llegada de GTFS, BART tenía que proporcionar a diferentes consumidores de datos diferentes formatos, lo que hacía que un formato de transporte estandarizado fuera muy deseable. ^[3] La especificación de formato disponible públicamente y de forma gratuita, así como la disponibilidad de horarios GTFS, rápidamente hicieron que los desarrolladores basaran su software relacionado con el transporte en el formato. Esto dio como resultado "cientos de aplicaciones de transporte útiles y populares" ^[4], así como catálogos que enumeran los feeds GTFS disponibles. Debido al formato de datos común al que se adhieren esas aplicaciones, las soluciones no necesitan ser personalizadas para un operador de transporte, sino que se pueden extender fácilmente a cualquier región donde haya un feed GTFS disponible.

Debido al amplio uso del formato, la parte "Google" del nombre original se consideró un nombre inapropiado "que hace que algunos usuarios potenciales se abstengan de adoptar GTFS". Como consecuencia, se propuso cambiar el nombre de la especificación a Especificación general de feeds de tránsito en 2009. ^[7]

GTFS se utiliza normalmente para proporcionar datos sobre el transporte público para su uso en aplicaciones de planificación de viajes multimodales . En la mayoría de los casos, GTFS se combina con una representación detallada de la red de calles/peatones para permitir que el enrutamiento se realice de un punto a otro en lugar de solo entre paradas. Estos datos se suelen ampliar utilizando GTFS-Realtime para tener en cuenta los retrasos, las cancelaciones y los viajes modificados en las consultas de planificación de viajes en tiempo real. OpenTripPlanner es un software de código abierto que puede realizar la planificación de viajes con una combinación de datos GTFS y OpenStreetMap . ^[8] Existen otras aplicaciones de uso general, como la extensión ArcMap Network Analyst, que puede incorporar GTFS para el enrutamiento del transporte público. ^[9]

GTFS fue diseñado originalmente para su uso en Google Transit , una aplicación de planificación de viajes multimodales en línea.

GTFS se utiliza a menudo en investigaciones sobre accesibilidad al transporte público , donde se utiliza normalmente para estimar los tiempos de viaje en transporte público desde un punto a muchos otros puntos en diferentes momentos del día. ^{[10] [11]} Sin embargo, los estudios han puesto en tela de juicio dichas aplicaciones debido a su dependencia únicamente de los horarios sin tener en cuenta los problemas de fiabilidad y el incumplimiento habitual de los horarios. ^[12]

El GTFS se ha utilizado para medir los cambios en la accesibilidad debido a los cambios en la prestación del servicio de transporte, ya sea actual ^{[13] o propuesto [14]} . El análisis de los cambios en el servicio a lo largo del tiempo se puede lograr simplemente comparando los datos GTFS publicados para la misma agencia en diferentes períodos de tiempo. Para comparar el servicio existente con la infraestructura propuesta o los cambios en el servicio, a menudo se debe construir un futuro GTFS a mano en función de las características del servicio propuesto ^{[14] .}

Los feeds GTFS públicos se han agregado en una variedad de registros de feeds:

• La base de datos de movilidad (2023-presente) se basa en TransitFeeds (2013-2024), que mantenía un directorio de feeds GTFS y GTFS en tiempo real y un sitio web interactivo para explorar el contenido de los feeds.
• Transitland (2014 - presente) mantiene un directorio de feeds GTFS y GTFS Realtime en más de 55 países y ofrece un sitio web interactivo y API para consultar el contenido de los feeds. Transitland fue creado originalmente por Mapzen y ahora lo mantiene Interline Technologies.
• El intercambio de datos GTFS (2008-2016) permitió que las agencias de transporte público de todos los tamaños cargaran copias de sus feeds GTFS. El sitio web ya no está activo.

Un feed GTFS es una colección de al menos seis y hasta 13 archivos CSV (con extensión .txt ) contenidos dentro de un archivo .zip . La codificación de caracteres preferida es UTF-8 . En conjunto, las tablas CSV relacionadas describen las operaciones programadas de un sistema de tránsito como visibles para los pasajeros. La especificación está diseñada para ser suficiente para proporcionar la funcionalidad de planificación de viajes, pero también es útil para otras aplicaciones, como el análisis de los niveles de servicio y algunas medidas de rendimiento general. A diferencia de los estándares de intercambio de la industria del tránsito europeo, como Transmodel o VDV -45X, GTFS solo incluye operaciones programadas que están destinadas a ser distribuidas a los pasajeros. También se limita a la información programada y no incluye información en tiempo real. Sin embargo, la información en tiempo real se puede relacionar con los cronogramas GTFS de acuerdo con la especificación GTFS Realtime relacionada . ^{[1] [2]}

A continuación se describen las tablas necesarias para una fuente de datos GTFS válida. Cada tabla es literalmente un archivo CSV de texto cuyo nombre de archivo es el nombre de la tabla, con el sufijo ".txt". Por lo tanto, para la tabla "agency" que aparece a continuación, se incluiría un archivo CSV llamado "agency.txt" en una fuente GTFS válida.

La tabla de agencias proporciona información sobre la agencia de tránsito como tal, incluido el nombre, el sitio web y la información de contacto.

Campos obligatorios:

• nombre_de_la_agencia
• URL de la agencia
• zona horaria de la agencia

La tabla de rutas identifica rutas distintas. Esto se debe distinguir de las rutas (o caminos) distintas, varias de las cuales pueden pertenecer a una sola ruta.

Campos obligatorios:

• route_id ( clave principal )
• nombre_corto_de_ruta
• nombre_largo_de_la_ruta
• tipo_ruta
• color de fondo
• color de primer plano

Campos obligatorios:

• trip_id (clave principal)
• route_id ( clave externa )
• service_id (clave externa)

Campos opcionales:

• block_id: el ID del bloque indica el bloque de programación al que pertenece un viaje.

Campos obligatorios:

• stop_id (clave principal)
• trip_id (clave externa)
• hora de llegada
• hora de salida
• secuencia de parada

Tenga en cuenta que el tiempo de permanencia puede modelarse mediante la diferencia entre los horarios de llegada y salida. Sin embargo, muchas agencias no parecen modelar el tiempo de permanencia para la mayoría de las paradas. ^{[ ¿ Investigación original? ]}

La tabla de paradas define las ubicaciones geográficas de todas y cada una de las paradas o estaciones reales del sistema de tránsito, así como, de manera opcional, algunos de los servicios asociados con esas paradas.

Campos obligatorios:

• stop_id (clave principal)
• nombre_de_parada
• detener_lon
• parada_lat

La tabla de calendario define patrones de servicio que funcionan de forma recurrente, como, por ejemplo, todos los días de la semana. Los patrones de servicio que no se repiten, como por ejemplo para un evento especial único, se definirán en la tabla calendar_dates.

Campos obligatorios:

• service_id (clave principal)
• Lunes
• Martes
• Miércoles
• Jueves
• Viernes
• Sábado
• Domingo
• fecha de inicio
• fecha de finalización

Las fechas del calendario son una tabla opcional que agrega excepciones al archivo calendar.txt. Esto puede incluir agregar días adicionales o eliminar días, como por ejemplo para el servicio de feriados. El archivo solo contiene tres columnas: el ID del servicio, la fecha y el tipo de excepción (ya sea agregada o eliminada). No es necesario que el ID del servicio esté dentro del archivo calendar.txt para que se agregue a esta tabla.

Reglas para dibujar líneas en un mapa para representar las rutas de una organización de tránsito.

Esta tabla especifica el intervalo de tiempo entre viajes para rutas con frecuencia de servicio variable.

Reglas para realizar conexiones en puntos de transferencia entre rutas.

Se puede establecer una fecha de inicio y una fecha de vencimiento opcionales para el feed. Las agencias pueden publicar feeds con varios días de antelación. Por lo tanto, las aplicaciones de software de planificación de viajes mantienen varias versiones del feed y el feed correcto para un día o una hora en particular.

traducciones

La tabla de traducciones consta de las columnas table_name, field_name, field_value,record_id,record_sub_id,language,translation. Las traducciones se dividen en sus respectivas tablas y se puede traducir cualquier campo de texto o URL. Las traducciones en GTFS utilizan dos tipos de claves en la tabla de clave-valor. Record_id utiliza el ID del campo, como stop_id o trip_id, mientras que field_value es un valor coincidente con el contenido original de field_name. Las tablas que utilizan una tupla de dos valores , como stop_times, utilizan record_id y record_sub_id para representar la tupla. La columna de traducción es el resultado.

• Mapas de Bing
• Tránsito de Google
• Planificador de viajes
• Estándar abierto

Este artículo contiene extractos de "Apertura de datos de transporte público en Alemania" de Stefan Kaufmann, que está disponible bajo una licencia Creative Commons Atribución 3.0 unported.

• Documentación de Google sobre la especificación GTFS
• Historia de GTFS
• Herramientas GTFS
• Centro de recursos GTFS administrado por MobilityData
• Artículo sobre la especificación general de feeds de tránsito en TransitWiki, con historia, usos y aplicaciones, métodos de producción y mejores prácticas