Los datos de transporte contienen errores de partida. Así los corregimos.
Cualquier operador de transporte puede publicar un feed GTFS y nadie lo revisa antes de su publicación. Lo que se entrega es incoherente, incompleto y, en ocasiones, sencillamente incorrecto: paradas duplicadas, calendarios erróneos, coordenadas no válidas y horas de llegada posteriores a las de salida. Un planificador construido directamente sobre esos datos envía a alguien a la esquina equivocada; un agente de IA que repite un horario obsoleto deja esperando en una parada a una persona que confió en él. Procesamos 7.000+ feeds de operadores de todo el mundo mediante un proceso diseñado para resolver ese problema: recopilamos y normalizamos cada feed, consolidamos operadores que se solapan en un conjunto de datos coherente y después ejecutamos 150+ comprobaciones de corrección, enriquecimiento y validación sobre esos datos, perfeccionadas con datos reales de producción.
Mantenimiento continuo, no una corrección puntual
Este tratamiento se mejora continuamente. Se publican nuevas reglas, mejoras de algoritmos y correcciones de calidad cada semana. La búsqueda, los horarios y las respuestas de la API utilizan la última versión validada del tratamiento. La publicación se realiza mediante rotación de servidores Blue-Green: las solicitudes se dirigen a un entorno recién desplegado en lugar de reiniciar el entorno activo. El cálculo de rutas utiliza una infraestructura independiente con su propio ciclo de publicación. Las entregas únicas y periódicas requieren aprobación manual. Utilice el formulario de solicitud de datos para acordar las exportaciones y las condiciones de entrega.
Reglas perfeccionadas con datos de transporte reales
Algunas comprobaciones estructurales solo requieren unos milisegundos. La fusión de paradas duplicadas entre feeds, la detección de expediciones idénticas y la fusión de calendarios han requerido más de un año de pruebas y mejoras con datos de producción.
Cada regla se valida en el ciclo de procesamiento semanal con 7.000+ feeds reales.
Tratamiento de datos GTFS estáticos
Qué corregimos durante el tratamiento
GTFS es un formato abierto de publicación autónoma: cada operador puede proporcionar un feed sin validación previa por una autoridad central. Cubrimos 10.000+ operadores de transporte en 90+ países : desde redes de metro con sus propios equipos de datos hasta pequeñas empresas de autobuses cuyo programa de exportación de horarios no ha cambiado en diez años. 150+ comprobaciones automáticas se ejecutan en cada feed para detectar estos problemas. No se limitan a eliminar datos erróneos: normalizan los nombres, reparan las referencias y asignan a cada parada, línea y expedición una identidad y un orden estables entre actualizaciones semanales. Así la API es más rápida: los resultados ya llegan con nombres, sin duplicados y ordenados. Su aplicación no tiene que limpiarlos en cada solicitud. Esta es una selección de comprobaciones, agrupadas por ámbito:
Nombres e identificadores
Los campos destinados a nombres legibles llegan de las fuentes con valores vacíos, mayúsculas incoherentes o dos campos que repiten la misma información sin indicarlo.
Nombres que parecen escritos por una persona
Sin PARADAS EN MAYÚSCULAS ni caracteres repetidos por error: limpiamos y normalizamos los nombres para que su interfaz no tenga que compensar los errores de las fuentes.
Nombres de líneas adecuados para las listas
Los nombres cortos y largos se ajustan automáticamente entre sí: ninguno queda vacío, duplicado ni tan largo que altere el selector de líneas.
Sin repeticiones en los datos de las paradas
Si una descripción repite el nombre de la parada, la vaciamos en lugar de entregar el mismo texto en dos campos.
Sin entradas sin nombre
Las paradas, los operadores o las expediciones sin nombre reciben una etiqueta de sustitución identificable en lugar de un campo vacío que dificulte su visualización.
Un destino siempre visible para los viajeros
Si falta el destino de una expedición, lo completamos a partir de su última parada para que su aplicación pueda mostrarlo.
El idioma correcto en todos los casos
Si el idioma declarado en el feed no coincide con el del operador, lo corregimos. Su localización puede basarse en este campo.
Calendarios y horarios
Periodos de servicio en los que apenas circulan vehículos, llegadas posteriores a las salidas y horarios que implican velocidades físicamente imposibles: los errores de un programa de exportación de horarios parecen servicios reales para quien confía en el feed original.
Calendarios que reflejan el servicio real, sin restos de planificación
Los periodos sin uso, las entradas contradictorias y los calendarios duplicados se detectan y eliminan antes de proponer un viaje un día sin servicio.
Los viajes en el tiempo no llegan a sus horarios
Cuando la hora de llegada a la parada actual es anterior a la de salida de la parada anterior, un error de exportación real y recurrente, lo corregimos y señalamos los pocos feeds en los que el problema es demasiado frecuente para corregirlo sin revisión.
Cada expedición tiene una hora real de salida y llegada
Los campos de horario vacíos se comprueban y completan para que los sistemas posteriores no tengan que adivinar la hora real de salida.
Sin expediciones que físicamente no puedan realizarse
Una expedición sin su primer o último horario no se puede planificar. La eliminamos antes de que altere un trayecto sin que se detecte.
Representación correcta del servicio nocturno
Las salidas después de medianoche se convierten a un formato horario GTFS válido sin modificar el servicio real. Es un detalle que los analizadores sencillos suelen interpretar mal.
Sin ambigüedad sobre qué horas son exactas
El campo timepoint se establece automáticamente según existan horas de llegada y salida reales. No se deja vacío para que cada usuario lo interprete.
Las expediciones físicamente imposibles no llegan a sus usuarios
Corregimos los intervalos de frecuencia que se solapan y eliminamos las expediciones con velocidades imposibles. Los viajeros no deben ver un autobús circulando a 2000 km/h.
Paradas y coordenadas
Dos operadores publican por separado la misma parada, una expedición hace referencia a un stop_id ausente del feed y los datos de accesibilidad faltan o son erróneos.
Cada parada tiene definido su tipo
El tipo de lugar se establece automáticamente para los puntos de embarque sencillos. Las expediciones que hacen referencia a un tipo de parada inadecuado se detectan antes de alterar su mapa.
Estaciones con accesos reales, no solo un punto en el mapa
Añadimos entradas, salidas y vínculos a la estación principal a partir de una base de intercambiadores mantenida. Las estaciones principales mal situadas se recolocan en su ubicación real.
Sin expediciones invalidadas por una parada ausente
Si una expedición hace referencia a una parada ausente de stops.txt, la reconstruimos. Cuando es posible, su nombre y coordenadas proceden de los datos oficiales británicos NAPTAN. Así la expedición sigue siendo utilizable.
Información de accesibilidad fiable
Una estación se considera accesible si al menos un andén lo es, e inaccesible solo si todos sus andenes lo son expresamente. La información ausente se mantiene como desconocida en lugar de presentarla como una imposibilidad de acceso.
Precisión y tamaño reducido
Las coordenadas se redondean a seis decimales, con una exactitud inferior a un metro, para reducir el tamaño de los archivos sin perder precisión en las posiciones.
Una parada, un registro, aunque la publiquen dos operadores
Las paradas separadas unos 20 metros y con servicio en el mismo sentido se reconocen como un mismo lugar físico y se fusionan en lugar de aparecer duplicadas en el mapa.
Los modos de transporte correctos para cada parada
El modo de transporte de una parada se deduce de las líneas que realmente la sirven. El mapa y los filtros muestran el icono correcto sin una solicitud adicional.
Datos por ciudad sin procesamiento geográfico adicional
Cada parada se vincula a su ciudad para permitir directamente las exportaciones por ciudad y los filtros de la API.
Sin expediciones sin recorrido
Una expedición con una sola parada no representa un servicio real. Se elimina junto con las paradas duplicadas que suelen acompañarla.
Líneas y tarifas
El tipo de vehículo, el color o la información tarifaria de una línea suelen estar mal codificados, vacíos o copiados de otro campo del feed.
Los tipos de vehículo incorrectos no llegan a sus usuarios
Los tipos de vehículo, nombres de líneas y vínculos a operadores erróneos se detectan y corrigen con una tabla mantenida por nuestro equipo de datos.
Sin tipos de línea desconocidos
Los tipos de línea ausentes o no válidos se establecen como autobús para evitar un valor desconocido en su aplicación. Cada corrección genera un aviso interno para revisar manualmente los casos inusuales.
Colores de líneas siempre legibles
Corregimos los códigos de color no válidos. Los colores de texto ausentes se eligen según el fondo para garantizar la legibilidad de las líneas.
Sin enlaces redundantes en los datos de las líneas
Una URL de línea que simplemente repite el sitio del operador se vacía.
También cuidamos los pequeños detalles
En las expediciones de ferri se define correctamente el campo que permite bicicletas. Esto elimina una advertencia de validación presente por defecto en muchos feeds.
Datos tarifarios que superan la validación
Los campos de las reglas tarifarias se comprueban y corrigen conforme a la especificación GTFS antes de la entrega.
Identificadores estables, orden y rapidez
Un proveedor renumera sus expediciones entre actualizaciones, dos fuentes publican la misma línea con distintos identificadores y el feed original no ordena las expediciones del día.
Reconocer la misma línea en varias fuentes
Las líneas reciben una huella calculada a partir de su geografía real. Así se reconoce una misma línea publicada por dos fuentes y se evita que aparezca duplicada.
Identidad estable de las expediciones aunque cambien los identificadores originales
Las expediciones se reconocen por su secuencia de paradas y horarios. Una misma expedición programada conserva su identidad entre actualizaciones semanales aunque el proveedor renumere sus identificadores.
Sin expediciones duplicadas que aumenten sus datos
Las expediciones con la misma huella de línea y horarios se reconocen como idénticas y se fusionan en un registro de referencia.
Los resultados llegan siempre en el orden correcto
Cada expedición recibe un orden diario estable durante el procesamiento. Su aplicación y la nuestra no necesitan reordenar las expediciones en cada solicitud.
Una secuencia continua de paradas
Las numeraciones inusuales se sustituyen por una secuencia continua que comienza en cero, lo que simplifica el tratamiento de las paradas de una expedición.
La identidad de una parada se conserva en cada actualización
Las paradas se reconocen por su nombre, coordenadas y modo de transporte. Así se puede seguir una misma parada física entre fuentes y actualizaciones semanales.
Trazados adecuados y rápidos de mostrar
Eliminamos los puntos de geometría innecesarios y recalculamos las distancias para reducir el volumen de datos. Un trazado muy alejado de la expedición real se desvincula para evitar un mapa engañoso.
Operadores, zonas horarias y solicitudes
Una zona horaria incorrecta o ausente del operador puede desplazar las llegadas una hora para cada viajero, cada día, hasta que se detecte el error.
Datos de contacto utilizables
Las direcciones de correo y las URL no válidas se vacían. Si falta la URL obligatoria del operador, un valor de sustitución permite que los sistemas posteriores sigan funcionando.
Sin adivinar qué idioma utiliza un operador
Si falta el idioma del operador, se completa con el idioma predeterminado del país para proporcionar una base útil a su localización.
Horas de salida correctas, no solo plausibles
Corregimos las zonas horarias no válidas o geográficamente inadecuadas de operadores y paradas. Son una de las principales causas de llegadas desplazadas una hora en los planificadores de rutas.
Reglas de transbordo con destinos válidos
Las reglas de transbordo que hacen referencia a paradas o líneas inexistentes se eliminan antes de que alteren la búsqueda de rutas.
Conocer inmediatamente las líneas de una parada
Cada parada recibe un índice precalculado de las líneas que la sirven. Así, la llamada a la API para consultar las líneas de una parada es una búsqueda en un índice, no una unión de tablas en tiempo real.
Tratamiento de datos en tiempo real
La sincronización GTFS-RT es una de las tareas más difíciles del tratamiento de datos de transporte. Cada proveedor utiliza sus propios identificadores, formatos y convenciones de nombres, que deben relacionarse en tiempo real con los horarios estáticos. Además del tratamiento estático, aplicamos reglas específicas para asociar los datos en tiempo real:
- Comprobación geográfica de las posiciones: se rechazan automáticamente las coordenadas fuera de la zona de servicio. Un caso real fue un feed de Londres que situaba autobuses en Estados Unidos.
- Al fusionar feeds de distintos operadores, un mismo identificador de línea puede aparecer dos veces. En ese caso, la prioridad de asociación entre los duplicados se conserva de forma explícita y no se elige arbitrariamente. Mismo operador y línea, 2 fuentes → prioridad de asociación conservada
- La asociación de expediciones no consiste en adivinar la hora más cercana: cuando una llegada en tiempo real queda entre dos expediciones programadas, se asigna mediante una ventana temporal asimétrica, no mediante el punto medio. Hora entre 2 expediciones programadas → asociación por ventana 75/25
- Un mecanismo alternativo por niveles intenta primero la asociación más específica y solo flexibiliza los criterios cuando falla, en lugar de aplicar una regla de todo o nada. Faltan parada y hora exactas → comprobar primero línea y expedición; después, línea y hora
- Cuando una señal no se puede resolver de forma fiable, porque falta el sentido y no hay una alternativa aplicable, el proceso devuelve el resultado sin asociación en lugar de adivinar. Falta el sentido, sin coincidencia alternativa → sin asociación
- Previsiones de llegada en paradas con datos en tiempo real retrasados o ausentes
Tratamiento específico por país
Además del proceso universal, desarrollamos reglas de tratamiento específicas para cada país que tienen en cuenta los formatos locales, los estándares de codificación y las particularidades de los operadores. Estas reglas se ejecutan como una capa adicional sobre el proceso base y se adaptan a los problemas reales de calidad de los datos de cada proveedor.
Los datos que hacen funcionar BusMaps
Los mismos datos procesados alimentan la búsqueda de rutas, los paneles de salidas y las respuestas de la API de BusMaps. Utilícelos a través de nuestra API o solicite conjuntos corregidos para su infraestructura.
Datos de transporte corregidos para su proyecto
Solicite GTFS corregido, GeoJSON o exportaciones personalizadas, o integre nuestra API. Indique la cobertura, los formatos y la frecuencia de actualización necesarios para acordar la entrega o la integración.