TODS Validate: hallazgos que el personal de programación puede usar
Rol: Ingeniería independiente · 2026
Desarrollo tods-validate, un validador beta para el Transit Operational Data Standard, el estándar abierto para turnos de personal, viajes en vacío y asignaciones de vehículos que funciona como una capa sobre el feed GTFS de una agencia. Comprueba un paquete frente a TODS v2.1.0 e informa qué está mal, dónde y cómo se ve lo correcto, con la sección de la especificación citada detrás de cada hallazgo. No se afirma adopción por agencias ni uso en producción.
Límite de evidencia
- Construido
- Un validador de TODS distribuido como CLI, GitHub Action, imagen de contenedor, hook de pre-commit, entorno en el navegador y servidor de lenguaje
- Observado
- Los hallazgos citan TODS v2.1.0 sección por sección; el entorno en el navegador valida localmente y no sube datos del feed
- No demostrado
- Adopción por agencias, uso en producción o cualquier respaldo de quienes mantienen el estándar
Medidas seleccionadas
- versión vigente de la especificación TODS contra la que valida
- v2.1.0
- formas de distribución nombradas en el README, de una CLI en PyPI a un cliente de VS Code
- 7
- archivos de feed subidos por el entorno en el navegador; la validación es local
- 0
- estado, declarado en la primera línea del README
- Beta
El Transit Operational Data Standard (se abre en una pestaña nueva) describe el lado del transporte que GTFS no cubre: turnos de personal, viajes en vacío, asignaciones de vehículos, el servicio no público que hace funcionar el horario público. Nació como el Operational Data Standard de Cal-ITP y hoy se mantiene junto con MobilityData. tods-validate (se abre en una pestaña nueva) comprueba un paquete TODS frente a la especificación vigente, v2.1.0, e informa hallazgos en un lenguaje que el personal de programación puede usar.
Un estándar que va montado sobre otro
TODS funciona como una capa superpuesta: sus archivos apuntan por referencia al feed GTFS de la agencia. Esa costura es donde los feeds se pudren. Una edición de GTFS perfectamente válida por sí sola puede dejar huérfanas, sin aviso, las referencias TODS construidas encima, así que el validador comprueba la costura, no solo el paquete, e informa referencias TODS rotas por cambios en GTFS.
Qué está mal, dónde y cómo se ve lo correcto
Un hallazgo se escribe para la persona que tiene que corregir el archivo, no para quien escribió la especificación. Cada uno dice qué está mal, dónde está y cómo se ve lo correcto, y cita la sección de la especificación de la que proviene. Cuando una corrección es mecánica y segura, la herramienta la aplica, y las correcciones automáticas son deliberadamente conservadoras.
Se ejecuta donde está quien posee los datos
- Una CLI y un hook de pre-commit, para el repositorio donde vive el feed.
- Una GitHub Action, para que la validación ocurra antes de publicar un feed y no después.
- Una imagen de contenedor, para los pipelines que la quieren fijada.
- Un entorno en el navegador (se abre en una pestaña nueva) que valida por completo en el navegador. Los archivos del feed no se suben a ningún lado.
- Un servidor de lenguaje. El cliente de VS Code existe y no está en un marketplace, y el README lo dice.
Lo que no afirma
- No es un validador oficial, y quienes mantienen el estándar no lo han respaldado.
- No se afirma adopción por agencias ni uso en producción.
- Su estado es beta, y la primera línea del README lo dice.
La pieza que lo acompaña es GTFS Scorecard, que lee la capa pública de los mismos datos igual que esta herramienta revisa la operativa: contra el documento que la define, con la cita adjunta.