# GTFS

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.

## Historia

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». 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.
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. 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.
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. 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» 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.

### Planificación de viajes

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. Existen otras aplicaciones de propósito general, como la extensión ArcMap Network Analyst, que puede incorporar GTFS para el enrutamiento de tránsito.
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

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. 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.

### Comparación de niveles de servicio

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 o propuestos. 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.

### Registros de feeds

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

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).
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
#### agency

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

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

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

Campos obligatorios:
* stop_id (clave principal)
* trip_id (clave externa)
* arrival_time
* departure_time
* stop_sequence

#### stops

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

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
#### calendar_dates

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.

#### shapes

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

#### frequencies

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

#### transfers

Reglas para realizar conexiones en puntos de transferencia entre rutas.

#### feed_info

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.