4.1 Qué es GTFS y cómo se estructura

Un feed GTFS es un archivo ZIP que contiene varios archivos de texto con extensión .txt. Cada archivo es una tabla — igual que una hoja de cálculo — donde cada columna es un campo de datos y cada fila es un registro. Los archivos se relacionan entre sí mediante identificadores, de la misma forma que funciona una base de datos.

El formato es abierto y está mantenido por MobilityData, una organización sin fines de lucro. Su documentación oficial está disponible en español. gtfs.org — Referencia

Los archivos del feed

Un feed completo puede tener más de veinte archivos, pero para publicar datos funcionales de un sistema de transporte municipal alcanza con siete. Cuatro son técnicamente obligatorios por el estándar, y tres adicionales son necesarios en la práctica para que los datos sean útiles en aplicaciones de navegación.

agency.txt — La agencia operadora

Describe quién opera el servicio de transporte. En la mayoría de los casos municipales mexicanos, la agencia es el municipio mismo, la secretaría de movilidad o la empresa concesionaria principal.

Campo	Descripción	Ejemplo
agency_id	Identificador único	MOVILIDAD_ZMR
agency_name	Nombre oficial	Dirección de Movilidad de Zamora
agency_url	Sitio web	https://zamora.gob.mx
agency_timezone	Zona horaria	America/Mexico_City

Un feed puede tener varias agencias si coexisten distintos operadores en el sistema. Para la mayoría de los municipios, bastará con una sola fila en este archivo.

stops.txt — Las paradas

Cada fila es una parada donde los pasajeros suben o bajan. La posición geográfica de cada parada se expresa en coordenadas de latitud y longitud en el sistema WGS 84 — el mismo que usan GPS y OpenStreetMap.

Campo	Descripción	Ejemplo
stop_id	Identificador único	PAR-001
stop_name	Nombre de la parada	Mercado Hidalgo
stop_lat	Latitud	19.9834
stop_lon	Longitud	-102.2833

El nombre de la parada debe ser algo que un usuario pueda reconocer — una calle, un punto de referencia, un edificio conocido. Si no existe nombre oficial, la esquina más cercana es una buena referencia: “Juárez y Morelos”.

routes.txt — Las rutas

Cada fila es una ruta del sistema — lo que los usuarios conocen como “la Ruta 5” o “el camión al mercado”. No se confunde con los recorridos físicos: una ruta puede tener múltiples variantes (ida, vuelta, ramal), que se modelan en el archivo de viajes.

Campo	Descripción	Ejemplo
route_id	Identificador único	RUTA-05
route_short_name	Número o código corto	5
route_long_name	Nombre descriptivo	Centro - Hospital General
route_type	Tipo de vehículo	3
route_color	Color de la ruta en hex	FF6600

El valor 3 en route_type corresponde a autobús — el modo más común en municipios mexicanos. Si la ruta tiene un color oficial con el que los usuarios la identifican, se puede incluir en route_color.

trips.txt — Los viajes

Un viaje es un recorrido específico de un vehículo a lo largo de una ruta, en una dirección y en un momento del día. Una ruta puede tener muchos viajes — uno por cada salida programada. Este archivo conecta las rutas con sus recorridos geográficos y con los calendarios de servicio.

Campo	Descripción	Ejemplo
trip_id	Identificador único	R5-IDA-0700
route_id	Ruta a la que pertenece	RUTA-05
service_id	Días en que opera	LUN-VIE
trip_headsign	Letrero del destino	Hospital General
shape_id	Forma geográfica asociada	SHAPE-R5-IDA

El trip_headsign es el texto que aparecería en el letrero frontal del autobús — “Hospital General”, “Centro”, “Terminal Norte”. Ayuda a los usuarios a saber si el camión va en la dirección correcta.

stop_times.txt — Los horarios

Es el archivo más grande. Cada fila define el paso de un viaje por una parada — a qué hora llega y a qué hora sale. Para un viaje con 30 paradas hay 30 filas en este archivo.

Campo	Descripción	Ejemplo
trip_id	Viaje al que pertenece	R5-IDA-0700
stop_id	Parada visitada	PAR-001
arrival_time	Hora de llegada	07:00:00
departure_time	Hora de salida	07:00:30
stop_sequence	Orden en el recorrido	1

Una dificultad práctica habitual en México: el transporte concesionado no tiene horarios fijos por parada. La solución es usar tiempos interpolados — estimar el tiempo en cada parada en función de la distancia total del recorrido y la velocidad promedio observada. No es exacto, pero es suficiente para que las aplicaciones calculen tiempos de viaje aproximados. El módulo de creación explica cómo hacerlo.

calendar.txt — El calendario de servicio

Define en qué días opera cada tipo de servicio. Permite especificar patrones semanales y fechas de vigencia.

Campo	Descripción	Ejemplo
service_id	Identificador	LUN-VIE
monday a sunday	Opera ese día (1=sí, 0=no)	1,1,1,1,1,0,0
start_date	Inicio de vigencia	20240101
end_date	Fin de vigencia	20241231

Con dos o tres entradas en este archivo — “días de semana”, “sábados” y “domingos” — se puede modelar la operación de la mayoría de los sistemas municipales. Las fechas de vigencia son importantes: un feed con fechas vencidas deja de mostrarse en algunas aplicaciones.

shapes.txt — El recorrido geográfico

Define la geometría del recorrido de cada viaje como una secuencia ordenada de puntos con coordenadas. Es técnicamente opcional en el estándar, pero sin él las aplicaciones no pueden mostrar el trazado de la ruta en el mapa — solo las paradas.

Campo	Descripción	Ejemplo
shape_id	Identificador de la forma	SHAPE-R5-IDA
shape_pt_lat	Latitud del punto	19.9834
shape_pt_lon	Longitud del punto	-102.2834
shape_pt_sequence	Orden del punto	1

Los shapes se generan a partir de las trazas GPS del trabajo de campo, procesadas en QGIS o JOSM. Una ruta de ida y vuelta requiere dos shapes distintos — los recorridos suelen diferir en algunas calles.

Cómo se relacionan los archivos

La lógica del formato funciona así:

• Una agencia opera varias rutas.
• Cada ruta tiene varios viajes — uno por cada salida del día.
• Cada viaje sigue un recorrido geográfico (shape) y opera en ciertos días según el calendario.
• Cada viaje pasa por una secuencia de paradas en horarios específicos.

Con esta estructura, una consulta como “¿cómo llego del mercado al hospital usando la Ruta 5 a las 7 de la mañana un martes?” puede responderse cruzando los datos de los siete archivos.

Una nota sobre la precisión

Un feed GTFS no tiene que ser perfecto para ser útil. Un feed con horarios aproximados, paradas estimadas y recorridos basados en trazas GPS ya permite que los usuarios vean sus opciones de transporte en aplicaciones de navegación. La precisión se puede mejorar en versiones sucesivas del feed conforme se disponga de mejor información.

Lo importante al empezar es que el feed sea técnicamente válido — que siga el formato correcto, que no tenga errores de estructura — aunque los datos sean aproximados. El módulo de validación describe cómo verificar eso.