4.3 Validar el feed

Antes de publicar el feed o enviarlo a Google Maps, hay que verificar que esté bien formado. Un feed con errores de estructura puede ser rechazado por las plataformas, generar información incorrecta para los usuarios o simplemente no funcionar. La validación es el paso que detecta esos problemas antes de que lleguen a producción.

El validador oficial es el Canonical GTFS Schedule Validator, desarrollado y mantenido por MobilityData — la misma organización que administra el estándar. Es gratuito, de código abierto y produce un reporte detallado de errores y advertencias.

Validador web (la forma más rápida)

La opción más accesible es usar la versión en línea del validador — no requiere instalar nada.

1. Ve a validator.mobilitydata.org. gtfs-validator.mobilitydata.org
2. Sube el archivo gtfs.zip o proporciona la URL donde está alojado.
3. El validador procesa el feed y genera un reporte en pantalla.

Qué significa cada tipo de resultado

El reporte clasifica los hallazgos en tres niveles.

Errores

Son problemas que hacen el feed inválido según el estándar. Deben corregirse todos antes de publicar — las plataformas como Google rechazarán un feed con errores.

Ejemplos comunes:

missing_required_file — Falta un archivo obligatorio. Ocurre cuando se olvidó incluir algún .txt en el ZIP o el nombre está mal escrito (stop.txt en lugar de stops.txt).

missing_required_field — Falta una columna obligatoria en algún archivo. Por ejemplo, stops.txt sin la columna stop_lat.

invalid_date — Fecha en formato incorrecto. Las fechas en GTFS van en formato YYYYMMDD sin guiones — 20240315, no 2024-03-15.

foreign_key_violation — Un identificador referenciado en un archivo no existe en el archivo donde debería estar definido. Por ejemplo, un shape_id en trips.txt que no aparece en shapes.txt. Esto suele ser por errores tipográficos en los IDs.

wrong_parent_location_type — Error en la jerarquía de paradas. Poco común en feeds municipales básicos.

Advertencias

Son problemas que no hacen el feed inválido, pero indican datos de baja calidad o inconsistencias que pueden afectar la experiencia del usuario.

stop_too_far_from_shape — Una parada está a más de cierta distancia del recorrido geográfico que le corresponde. Puede indicar que la parada está mal posicionada, o que el shape tiene un error en esa zona. Vale la pena revisar en QGIS.

fast_travel_between_stops — El tiempo entre dos paradas consecutivas implicaría una velocidad irreal. Suele ocurrir cuando los horarios fueron estimados con un error, o cuando dos paradas están muy cerca y el tiempo asignado es demasiado corto.

stop_too_close_to_shape — Demasiadas paradas en el mismo punto. Puede ser un error de digitalización o paradas duplicadas.

unused_stop — Una parada existe en stops.txt pero ningún viaje pasa por ella en stop_times.txt. Si es una parada real que debería estar en servicio, hay que añadirla a los stop_times correspondientes. Si quedó de una versión anterior, se puede eliminar.

negative_travel_time — El tiempo de llegada a una parada es anterior al de la parada anterior. Un error clásico al construir stop_times.txt manualmente.

Información

Datos estadísticos sobre el contenido del feed — número de rutas, paradas, viajes, rango de fechas del calendario. Útiles para verificar que el feed contiene lo que debería y que no falta nada de forma masiva.

Errores frecuentes en primeros feeds y cómo resolverlos

El ZIP contiene una carpeta en lugar de los archivos directamente. Al descomprimir el ZIP aparece una carpeta con los .txt dentro, en lugar de los archivos directamente. Hay que volver a comprimir seleccionando los archivos, no la carpeta.

Caracteres especiales rotos — acentos que se muestran como símbolos extraños. El feed no está en UTF-8. Desde LibreOffice, al guardar como CSV se puede especificar la codificación. Desde Google Sheets, la descarga en CSV siempre es UTF-8. Desde Excel en Windows, usar “Guardar como → CSV UTF-8 (con BOM)“.

Muchos errores de foreign_key_violation — los IDs en un archivo no coinciden con los del archivo relacionado. Suele ser por inconsistencias en mayúsculas/minúsculas (RUTA-01 vs ruta-01) o espacios invisibles al final del texto. En la hoja de cálculo, revisar que los IDs sean exactamente iguales en todos los archivos donde aparecen.

calendar.txt con fechas ya vencidas. El validador reporta que el servicio no está activo en fechas actuales. Actualizar start_date y end_date en el archivo de calendario.

Paradas con coordenadas invertidas. Latitud y longitud en las columnas equivocadas. La latitud de México está entre 14 y 33 grados norte; la longitud entre -86 y -117 grados oeste. Si los valores no están en esos rangos, las columnas están intercambiadas.

El proceso es iterativo

No es raro que el primer feed tenga docenas de errores. Corregir un error sistemático — como el formato de fechas en todo el archivo — puede eliminar de golpe muchos reportes. El ciclo es:

1. Generar el ZIP
2. Subir al validador
3. Revisar errores (empezar por los rojos)
4. Corregir en la hoja de cálculo
5. Volver al paso 1

Con dos o tres iteraciones, la mayoría de los feeds llegan a cero errores. Las advertencias pueden quedar para una segunda ronda de mejoras — lo importante es que no haya errores antes de publicar.

Verificación visual adicional

La validación técnica detecta errores de formato y lógica, pero no puede saber si una parada está colocada en la calle equivocada o si un recorrido da una vuelta innecesaria. Para eso hace falta revisar el feed visualmente sobre un mapa.

QGIS con el plugin GTFS Go

La forma más completa de hacer esta revisión es usar QGIS con el plugin GTFS Go, que carga el archivo ZIP directamente y genera capas visuales de rutas y paradas sin necesidad de procesar manualmente los CSV.

Para instalarlo: en QGIS, Complementos → Administrar e instalar complementos → buscar “GTFS Go” → Instalar.

Una vez instalado, aparece en el menú Vectorial → GTFS Go → Load GTFS. Al seleccionar el archivo gtfs.zip, el plugin genera automáticamente:

• Una capa de puntos con todas las paradas (stops)
• Una capa de líneas con todos los shapes de rutas

Estas capas se pueden visualizar sobre un fondo de OpenStreetMap o imágenes satelitales usando el plugin QuickMapServices para confirmar que la geometría es correcta.

Lo que hay que revisar:

• Que las rutas sigan las calles correctas y no tengan saltos o desvíos extraños.
• Que las paradas estén sobre o muy cerca de las vías por donde circula el vehículo.
• Que el sentido de los recorridos sea correcto — ida y vuelta en la dirección esperada.
• Que no haya paradas aisladas lejos del resto de la red, lo que puede indicar coordenadas invertidas.

Una vez que el feed pasa la validación sin errores y la revisión visual confirma que los datos son correctos, está listo para publicar.