GTFS o la Especificación General de Alimentación de Transporte Público define un formato de datos común para los horarios del transporte público y la información geográfica asociada. [1] GTFS contiene solo información estática o programada sobre servicios de transporte público y, a veces, se lo conoce como GTFS Static o GTFS Schedule para distinguirlo de la extensión GTFS Realtime , que define cómo se puede compartir información sobre el estado de los servicios en tiempo real. [1] [2]
Lo que se convertiría en GTFS comenzó como un proyecto paralelo del empleado de Google Chris Harrelson en 2005, quien "bromeó 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. para Portland , Oregón". [3] Se cita a McHugh por estar frustrado por encontrar direcciones de tránsito en ciudades desconocidas, mientras que los servicios de mapas populares ya ofrecían direcciones de manejo fáciles de usar en ese momento. [4]
Bibiana y Tim McHugh finalmente se pusieron en contacto con Google y proporcionaron a la empresa exportaciones CSV de los datos de programación de TriMet. En diciembre de 2005, Portland se convirtió en la primera ciudad que apareció en la primera versión del "Transit Trip Planner" de Google. [5] En septiembre de 2006, se agregaron cinco ciudades más de EE. UU. al Planificador de viajes de Google Transit y el formato de datos se publicó como Especificación de feeds de Google Transit . [6]
En Estados Unidos , no había ningún estándar para los horarios del transporte público antes de la llegada del 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 diferentes formatos a diferentes consumidores de datos, lo que hacía que un formato de tránsito estandarizado fuera muy deseable. [3] La especificación de formato disponible pública y gratuitamente, así como la disponibilidad de horarios GTFS, rápidamente hizo que los desarrolladores basaran su software relacionado con el tránsito en el formato. Esto dio como resultado "cientos de aplicaciones de tránsito útiles y populares" [4], así como catálogos que enumeran los canales GTFS disponibles. Debido al formato de datos común al que se adhieren esas aplicaciones, no es necesario adaptar las soluciones a un operador de tránsito, sino que se pueden extender fácilmente a cualquier región donde esté disponible un feed GTFS.
Debido al amplio uso del formato, la parte "Google" del nombre original se consideró un nombre inapropiado "que hace que algunos usuarios potenciales eviten adoptar GTFS". Como consecuencia, se propuso cambiar el nombre de la especificación a Especificación general de piensos en 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 suelen ampliarse utilizando GTFS-Realtime para tener en cuenta retrasos, cancelaciones y viajes modificados en consultas de planificación de viajes en tiempo real. OpenTripPlanner es un software de código abierto que puede planificar viajes con una combinación de datos GTFS y OpenStreetMap . [8] Existen otras aplicaciones de propósito general, como la extensión ArcMap Network Analyst, que puede incorporar GTFS para el enrutamiento de tránsito. [9]
GTFS se diseñó originalmente para su uso en Google Transit , una aplicación de planificación de viajes multimodal en línea.
GTFS se utiliza a menudo en investigaciones sobre accesibilidad al transporte público , donde normalmente se utiliza 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 cuestionado tales aplicaciones debido a su dependencia únicamente de horarios sin tener en cuenta problemas de confiabilidad y el incumplimiento del horario regular. [12]
GTFS se ha utilizado para medir cambios en la accesibilidad debido a cambios en la prestación del servicio de transporte, ya sea real [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 de servicio, a menudo se debe construir a mano un futuro GTFS basado en las características del servicio propuesto. [14]
Los feeds GTFS públicos se han agregado en una variedad de registros de feeds:
Un feed GTFS es una colección de al menos seis y hasta 13 archivos CSV (con extensión .txt ) contenidos en 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 funcionalidad de planificación de viajes, pero también es útil para otras aplicaciones como el análisis de niveles de servicio y algunas medidas generales de rendimiento. 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 deben distribuirse a los pasajeros. También se limita a 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 un feed de datos GTFS válido. Cada tabla es literalmente un archivo CSV de texto cuyo nombre de archivo es el nombre de la tabla, con el sufijo '.txt'. Entonces, para la tabla "agencia" a continuación, se incluiría un archivo CSV llamado "agency.txt" en un feed GTFS válido.
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 requeridos:
La tabla de rutas identifica rutas distintas. Esto debe distinguirse de rutas (o caminos) distintas, varias de las cuales pueden pertenecer a una única ruta.
Campos requeridos:
Campos requeridos:
Campos opcionales:
Campos requeridos:
Tenga en cuenta que el tiempo de permanencia puede modelarse según la diferencia entre las horas de llegada y salida. Sin embargo, muchas agencias no parecen modelar el tiempo de permanencia para la mayoría de las paradas.
La tabla de paradas define las ubicaciones geográficas de todas y cada una de las paradas o estaciones reales del sistema de transporte así como, y opcionalmente, algunos de los servicios asociados con esas paradas.
Campos requeridos:
La tabla de calendario define patrones de servicio que operan de forma recurrente como, por ejemplo, todos los días de la semana. Los patrones de servicio que no se repiten, como los de un evento especial único, se definirán en la tabla calendar_dates.
Campos requeridos:
Las fechas del calendario son una tabla opcional que agrega excepciones al archivo calendar.txt. Esto puede ser agregar días adicionales o eliminar días, como para el servicio de días festivos. El archivo solo contiene tres columnas: la identificación del servicio, la fecha y el tipo de excepción (ya sea agregada o eliminada). No es necesario que una identificación de servicio esté dentro del archivo calendar.txt para agregarla 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 (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 de alimentación opcional y una fecha de vencimiento de alimentación opcional. Las agencias pueden publicar feeds que se publicarán varios días después. Por lo tanto, las aplicaciones de software de planificación de viajes mantienen múltiples versiones de feeds y el feed correcto para un día u hora en particular.
traducciones
La tabla de traducciones consta de las columnas nombre_tabla, nombre_campo, valor_campo, id_registro, id_sub_registro, idioma, traducción. 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 clave-valor. Record_id usa ID para el 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.
Este artículo contiene extractos de "Abriendo datos de transporte público en Alemania" de Stefan Kaufmann, que está disponible bajo una licencia Creative Commons Attribution 3.0 no portada.