Anatomía de un GTFS

La Especificación General de Feeds de Transporte Público (GTFS) es el estándar mundial para publicar horarios e información geográfica de transporte público. Permite que aplicaciones como Google Maps, Citymapper, Transit y muchas otras consuman y muestren información de rutas a millones de usuarios.

Un “feed” GTFS no es más que una serie de archivos de texto (CSV) comprimidos en un archivo ZIP. Cada archivo describe un aspecto particular del sistema de transporte: agencias, paradas, rutas, viajes y horarios.

Estructura de Archivos

Aunque un GTFS puede contener muchos archivos, hay un núcleo de 6 archivos obligatorios que definen la estructura básica.

1. agency.txt (La Agencia)

Define quién opera el servicio. Es la entidad responsable de los datos y, a menudo, la cara pública del servicio de transporte.

• agency_name: Nombre de la empresa u organismo (ej. “Metrobús CDMX”). Debe ser el nombre oficial reconocido por los usuarios.
• agency_url: Sitio web oficial donde los usuarios pueden encontrar más información.
• agency_timezone: Zona horaria de operación (ej. “America/Mexico_City”). Crucial para que los horarios se muestren correctamente.
• agency_lang: Código de idioma ISO (ej. “es”).
• agency_phone: (Opcional) Número de atención al cliente.

2. stops.txt (Las Paradas)

Define los lugares físicos donde suben y bajan los pasajeros.

• stop_id: Identificador único interno.
• stop_name: Nombre público (ej. “Estación Chilpancingo”). Debe ser conciso y claro.
• stop_lat, stop_lon: Coordenadas geográficas precisas (WGS 84).
• location_type: (Opcional) Define si es una parada simple (0) o una estación grande (1) que contiene otras paradas.
• parent_station: (Opcional) Si la parada está dentro de una estación más grande.

3. routes.txt (Las Rutas)

Define las líneas comerciales, lo que el usuario identifica como “la ruta” en un mapa o letrero.

• route_id: Identificador único.
• route_short_name: Número o código corto (ej. “L1”, “701”).
• route_long_name: Nombre descriptivo completo (ej. “Indios Verdes - El Caminero”).
• route_type: Tipo de vehículo. Los más comunes son:
  • 0: Tranvía / Tren Ligero
  • 1: Metro / Subterráneo
  • 2: Tren de cercanías
  • 3: Autobús
• route_color y route_text_color: (Opcional) Hexadecimales para representar la marca visual de la ruta.

4. trips.txt (Los Viajes)

Representa un viaje específico de un vehículo a través de una ruta. Un “viaje” ocurre en un momento específico del día.

• trip_id: Identificador único del viaje.
• route_id: A qué ruta pertenece este viaje.
• service_id: Referencia al calendario (qué días opera este viaje específico).
• trip_headsign: (Opcional) Texto que aparece en el letrero frontal del vehículo (ej. “A Indios Verdes”). Ayuda al usuario a distinguir la dirección.
• shape_id: (Opcional) Enlace al trazado geográfico exacto en shapes.txt.

5. stop_times.txt (Los Horarios)

Es el archivo más grande y complejo. Define a qué hora llega y sale cada viaje de cada parada.

• trip_id: El viaje al que pertenece este horario.
• stop_id: La parada visitada.
• arrival_time: Hora de llegada (HH:MM:SS). Puede exceder 24:00:00 para viajes que terminan después de medianoche (ej. 25:30:00 es 1:30 AM del día siguiente).
• departure_time: Hora de salida.
• stop_sequence: El orden de la parada en la secuencia del viaje (1, 2, 3…). Debe ser creciente.

6. calendar.txt (El Calendario)

Define los patrones de servicio semanales.

• service_id: Identificador (ej. “Lunes-Viernes”, “FinDeSemana”).
• monday…sunday: 1 si el servicio opera ese día, 0 si no.
• start_date, end_date: Periodo de validez del horario (YYYYMMDD).

Horarios vs. Frecuencias

GTFS permite modelar el servicio de dos maneras principales, dependiendo de cómo opera el transporte en la realidad.

1. Basado en Horarios (Schedule-based)

Es el método tradicional. Se usa cuando el vehículo tiene una hora fija de paso por cada parada.

• Uso: Trenes, metros, autobuses interurbanos o rutas de baja frecuencia.
• Implementación: Se definen todos los tiempos exactos en stop_times.txt.
• Ventaja: El usuario sabe exactamente a qué hora esperar.

2. Basado en Frecuencias (Frequency-based)

Se usa cuando el servicio es tan frecuente que los usuarios no consultan un horario fijo, sino que simplemente llegan a la parada sabiendo que “pasa uno cada X minutos”.

• Uso: Metros de alta densidad, BRT (Metrobús) en horas pico.
• Implementación: Se usa el archivo frequencies.txt.
  • Se define un viaje plantilla en trips.txt y stop_times.txt (con tiempos relativos desde 00:00:00).
  • En frequencies.txt se especifica: “El viaje X opera de 07:00 a 09:00 cada 300 segundos (5 min)“.
• Ventaja: Simplifica enormemente la creación de datos para servicios intensivos y refleja mejor la experiencia del usuario (“Pasa cada 5 min” vs “Pasa a las 7:03, 7:08, 7:13…”).

Mejores Prácticas de Modelado

Para crear un GTFS de alta calidad que sea útil para los usuarios, sigue estas recomendaciones:

1. IDs Estables: Los identificadores (stop_id, route_id) no deberían cambiar entre actualizaciones del feed a menos que la entidad real cambie. Esto permite que aplicaciones externas guarden favoritos o historial.
2. Nombres Claros:
   • Evita abreviaturas crípticas en stop_name (Mal: “Av. Insurg. Esq. Reforma”, Bien: “Avenida Insurgentes y Reforma”).
   • Usa trip_headsign para indicar claramente la dirección del viaje.
3. Ubicación Precisa: Las coordenadas de las paradas deben ser donde el usuario espera el transporte, no el centro de la calle o el edificio de enfrente.
4. Colores: Usa los colores oficiales del sistema en routes.txt. Ayuda mucho a la legibilidad en mapas.
5. Validación: Siempre pasa tu feed por un validador (como el de Google o MobilityData) antes de publicarlo para detectar errores de lógica o formato.