Ir al contenido

GTFS

De Wikipedia, la enciclopedia libre
GTFS
Transit information display from Digitransit Ulm derived from GTFS data

Visualización creada a partir de los datos GTFS con las rutas de transporte público en Ulm, Germany
Desarrollador
Google
gtfs.org
Información general
Extensión de archivo .zip
Lanzamiento inicial 2006 de septiembre del 27
Extendido de CVS
Estándar(es) De facto standard
Formato abierto Sí 

GTFS o Especificación General de Fuentes de Tránsito es un formato de datos estandarizado que proporciona una estructura para que los operadores de transporte público puedan definir sus servicios (rutas, paradas, horarios, tarifas, etc.). El GTFS contiene únicamente información estática o programada sobre los servicios de transporte público y a veces se lo conoce como GTFS estático para distinguirlo de la extensión GTFS en tiempo real, que incorpora información en tiempo real de los servicios.[1][2]

Historia

[editar]

Lo que luego se convertiría en GTFS comenzó como un proyecto paralelo del empleado de Google Chris Harrelson en 2005, el cual «jugaba con formas de incorporar datos de tránsito en Google Maps cuando escuchó hablar de Tim y Bibiana McHugh, un matrimonio que trabajaba en TriMet, la agencia de tránsito de Portland, Oregón».[3]​ Se cuenta que McHugh se sentía frustrado cuando intentaba encontrar cómo moverse en transporte público en ciudades desconocidas, mientras que los servicios de mapas populares ya ofrecían cómo hacerlo en coche.[4]

Finalmente, Bibiana y Tim McHugh 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 en aparecer en la primera versión del «Planificador de viajes en tránsito» 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 feed de Google Transit.[6]

En Estados Unidos, no existía ningún estándar para los horarios del 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 tránsito estandarizado fuera muy deseable.[3]​ La especificación de formato disponible pública y gratuitamente, así como la disponibilidad de los cronogramas GTFS, rápidamente hicieron 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 feeds GTFS disponibles. Debido al formato de datos común al que se adhieren estas aplicaciones, no es necesario personalizar las soluciones para cada operador de transporte público, sino que pueden ampliarse fácilmente a cualquier región donde haya un GTFS disponible.

Debido al amplio uso del formato, la parte «Google» del nombre original fue vista como un nombre inapropiado «que hace que algunos usuarios potenciales eviten adoptar GTFS». Como consecuencia de ello, en 2009 se propuso cambiar el nombre de la especificación a Especificación general de alimentación en tránsito. [7]

Captura de pantalla que muestra OpenTripPlanner con la ruta de los datos GTFS resaltada.
Análisis de accesibilidad basado en GTFS a través de Mapnificent

Planificación de viajes

[editar]

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 a menudo se complementan utilizando GTFS-RT para tener en cuenta retrasos, cancelaciones y otras situaciones puntuales no recogidas en el GTFS. 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 fue diseñado originalmente para su uso en Google Transit, una aplicación de planificación de viajes multimodales en línea, pero actualmente es el estándar para este tipo de mapas incluyendo otros como Bing Maps.

Investigación de accesibilidad

[editar]

Los GTFS se utilizan a menudo para evaluar la accesibilidad del transporte público, usándolos para estimar los tiempos de viaje desde un punto a otros en diferentes momentos del día.[10][11]​ Sin embargo, algunos estudios han puesto en tela de juicio dichas aplicaciones debido a que dependen únicamente de horarios sin tener en cuenta cuestiones de confiabilidad o incluso en incumplimiento de dichos horarios.[12]

Comparación de niveles de servicio

[editar]

Los GTFS se han utilizado para medir los cambios en la accesibilidad debido a cambios en la prestación del servicio del transporte público, ya sean reales [13]​ o propuestos.[14]​ El análisis de los cambios en el servicio a lo largo del tiempo se puede realizar simplemente comparando los datos GTFS publicados del mismo operador en diferentes períodos de tiempo. Para comparar el servicio existente con la infraestructura propuesta o los cambios de servicio, a menudo es necesario construir un GTFS futuro a mano basándose en las características del servicio propuesto.[14]

Registros de feeds

[editar]

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 proporciona un sitio web interactivo y API para consultar el contenido de los feeds. Transitland fue creado originalmente por Mapzen y ahora es mantenido por Interline Technologies .
  • El intercambio de datos GTFS (2008-2016) permitió a los operadores de transporte público de todos los tamaños cargar copias de sus feeds GTFS. El sitio web ya no está activo.
  • El Gobierno de España mantiene una página Listadocon los GTFS publicados en España.

Estructura

[editar]
Class diagram of GTFS
Diagrama de clases de GTFS

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 transporte público tal como son 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 niveles de servicio y algunas medidas generales de rendimiento. A diferencia de los estándares de intercambio de la industria de tránsito europea, 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 información programada y no incluye información en tiempo real. Sin embargo, dicha información en tiempo real se puede añadir utilizando los GTFS Realtime (GTFS-RT).[1][2]

A continuación se presentan descripciones de las tablas necesarias para una fuente de datos GTFS válida. Cada tabla es un archivo CSV de texto cuyo nombre de archivo es el nombre de la tabla, con el sufijo «.txt». Por ejemplo, para la tabla «agency», se incluiría un archivo CSV llamado «agency.txt» en una fuente GTFS válida.

Tablas obligatorias

[editar]

agency

[editar]

La tabla agency proporciona información sobre el operador de transporte público, incluido el nombre, el sitio web y la información de contacto.

Campos obligatorios:

  • agency_name
  • agency_url
  • agency_timezone

routes

[editar]

La tabla routes identifica las distintas rutas. Cada ruta puede contener varios caminos.

Campos obligatorios:

  • route_id (clave principal)
  • route_short_name
  • route_long_name
  • route_type
  • background_color
  • foreground_color

trips

[editar]

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.

stop_times

[editar]

Campos obligatorios:

  • stop_id (clave principal)
  • trip_id (clave externa)
  • arrival_time
  • departure_time
  • stop_sequence

stops

[editar]

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

Campos obligatorios:

  • stop_id (clave principal)
  • stop_name
  • stop_lon
  • stop_lat

calendar

[editar]

La tabla calendar 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 por ejemplo para un evento especial único, se definirán en la tabla calendar_dates.

Campos obligatorios:

  • service_id (clave principal)
  • Monday
  • Tuesday
  • Wednesday
  • Thursday
  • Friday
  • Saturday
  • Sunday
  • start_date
  • end_date

Tablas opcionales

[editar]

calendar_dates

[editar]

Calendar_dates es una tabla opcional que añade excepciones al archivo calendar.txt. Esto puede implicar agregar días adicionales o eliminar días, como por ejemplo servicios en días festivos. El archivo solo contiene tres columnas: el ID del servicio, la fecha y el tipo de excepción (agregada o eliminada). No es necesario que un ID de servicio esté dentro del archivo calendar.txt para agregarlo a esta tabla.

fare_attributes

[editar]

fare_rules

[editar]

shapes

[editar]

Reglas para dibujar líneas en un mapa para representar las rutas.

frequencies

[editar]

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

transfers

[editar]

Reglas para realizar conexiones en puntos de transferencia entre rutas.

feed_info

[editar]

Opcionalmente, se puede establecer una fecha de inicio del feed y una fecha de vencimiento. Los operadores pueden publicar feeds con fechas previstas para varios días en el futuro. De esta forma, 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.

translations

La tabla translations consta de las columnas table_name, field_name, field_value,record_id,record_sub_id,language,translation. Las traducciones se desglosan 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 key-value. Record_id usa ID para el campo 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 la salida.

Véase también

[editar]

Referencias

[editar]
  1. a b «GTFS Static Overview». GoogleDevelopers. Archivado desde el original el 29 de septiembre de 2022. Consultado el 29 de septiembre de 2022. 
  2. a b «GTFS Realtime Overview». GoogleDevelopers. Archivado desde el original el 29 de septiembre de 2022. Consultado el 29 de septiembre de 2022. 
  3. a b Roush, Wade (2012). «Welcome to Google transit: How (and why) the search giant is remapping public transportation». Community Transportation: 3. Consultado el 14 de marzo de 2016. 
  4. a b Dyson, Lauren; Goldstein, Brett; Nemani, Abhi (2013). Beyond Transparency. Code for America Press. pp. 125-135. 
  5. Garg, Avichal. «Public Transit via Google». Official Google Blog. Archivado desde el original el 24 de marzo de 2016. Consultado el 14 de marzo de 2016. 
  6. Harrelson, Chris. «Happy Trails with Google Transit». Official Google Blog. Archivado desde el original el 24 de marzo de 2016. Consultado el 14 de marzo de 2016. 
  7. Hughes, Joe. «proposal: remove "Google" from the name of GTFS». General Transit Feed Spec Changes. Google Groups. Archivado desde el original el 29 de septiembre de 2022. Consultado el 14 de marzo de 2016. 
  8. «Home | OpenTripPlanner». www.opentripplanner.org. Archivado desde el original el 8 de mayo de 2017. Consultado el 12 de mayo de 2017. 
  9. «Yay, transit! - Using GTFS Data in ArcGIS Network Analyst». transit.melindamorang.com. Archivado desde el original el 19 de mayo de 2017. Consultado el 12 de mayo de 2017. 
  10. Farber, Steven; Morang, Melinda Z.; Widener, Michael J. (1 de septiembre de 2014). «Temporal variability in transit-based accessibility to supermarkets». Applied Geography 53: 149-159. doi:10.1016/j.apgeog.2014.06.012. 
  11. Fransen, Koos; Neutens, Tijs; Farber, Steven; De Maeyer, Philippe; Deruyter, Greet; Witlox, Frank (1 de octubre de 2015). «Identifying public transport gaps using time-dependent accessibility levels». Journal of Transport Geography 48: 176-187. doi:10.1016/j.jtrangeo.2015.09.008. 
  12. Wessel, Nate; Allen, Jeff; Farber, Steven (1 de junio de 2017). «Constructing a routable retrospective transit timetable from a real-time vehicle location feed and GTFS». Journal of Transport Geography 62: 92-97. ISSN 0966-6923. doi:10.1016/j.jtrangeo.2017.04.012. 
  13. Farber, Steven; Fu, Liwei (1 de marzo de 2017). «Dynamic public transit accessibility using travel time cubes: Comparing the effects of infrastructure (dis)investments over time». Computers, Environment and Urban Systems 62: 30-40. doi:10.1016/j.compenvurbsys.2016.10.005. 
  14. a b Farber, Steven; Grandez, Maria (2017). «Transit Accessibility, Land Development and Socioeconomic Priority: A Typology of Planned Station Catchment Areas in the Greater Toronto and Hamilton Area». Journal of Transport and Land Use 10 (1). doi:10.5198/jtlu.2017.980. (note: forthcoming edition). 

Enlaces externos

[editar]