Les données de transport sont défaillantes par nature. Voici comment nous y remédions.
Tout opérateur peut publier un flux GTFS sans vérification préalable. Les données sont hétérogènes, incomplètes et parfois incorrectes : arrêts en double, calendriers erronés, coordonnées invalides ou arrivées après les départs. Un calculateur d'itinéraires construit directement sur ces données envoie les gens au mauvais coin de rue ; un agent IA qui répète un horaire périmé laisse attendre en vain, à l'arrêt, la personne qui lui a fait confiance. Nous traitons 7 000+ flux d'opérateurs du monde entier avec un processus qui répond à ces problèmes : nous récupérons et harmonisons chaque flux, fusionnons les sources d'opérateurs qui se recoupent, puis appliquons 150+ contrôles de correction, d'enrichissement et de validation affinés à partir de données réelles de production.
Un entretien continu, pas une correction ponctuelle
Ce traitement est amélioré en continu. De nouvelles règles, des algorithmes améliorés et des corrections de qualité sont publiés chaque semaine. La recherche, les horaires et les réponses API utilisent la dernière version validée du traitement. La publication s'effectue par rotation des serveurs Blue-Green: les requêtes sont dirigées vers un environnement fraîchement déployé au lieu de redémarrer l'environnement actif. Le calcul d'itinéraires utilise une infrastructure distincte avec son propre cycle de publication. Les livraisons ponctuelles et régulières nécessitent une approbation manuelle. Utilisez le formulaire de demande de données pour convenir des exports et des conditions de livraison.
Des règles affinées sur des données de transport réelles
Certains contrôles structurels ne prennent que quelques millisecondes. La fusion des arrêts en double entre flux, la détection des courses identiques et la fusion des calendriers ont nécessité plus d'un an de tests et d'améliorations sur des données de production.
Chaque règle est validée dans le cycle de traitement hebdomadaire sur 7 000+ flux réels.
Traitement des données GTFS statiques
Ce que nous corrigeons pendant le traitement
GTFS est un format ouvert de publication autonome : chaque opérateur peut fournir un flux sans validation préalable par une autorité centrale. Nous couvrons 10 000+ opérateurs de transport dans 90+ pays - des réseaux de métro disposant de leurs propres équipes de données aux petites compagnies de bus dont le logiciel d'export des horaires n'a pas changé depuis dix ans. 150+ contrôles automatisés sont exécutés sur chaque flux pour détecter ces problèmes. Ils ne se limitent pas à supprimer les données erronées : ils harmonisent les noms, réparent les références et attribuent à chaque arrêt, ligne et course une identité et un ordre stables au fil des mises à jour hebdomadaires. L'API est ainsi plus rapide : les résultats arrivent déjà nommés, dédupliqués et triés. Votre application n'a pas à les nettoyer à chaque requête. Voici une sélection de contrôles, classés par domaine :
Noms et identifiants
Les champs de noms des sources peuvent être vides, avoir une casse incohérente ou répéter la même information dans deux champs.
Des noms lisibles et cohérents
Finis les ARRÊTS EN MAJUSCULES ou les caractères répétés par erreur : nous nettoyons et harmonisons les noms pour que votre interface n'ait pas à compenser les erreurs des sources.
Des noms de lignes adaptés aux listes
Les noms courts et longs sont harmonisés automatiquement pour éviter les champs vides, les répétitions et les noms trop longs dans votre sélecteur de lignes.
Aucune répétition dans les données des arrêts
Si une description répète simplement le nom de l'arrêt, nous la vidons au lieu de fournir le même texte dans deux champs.
Aucune entrée sans nom
Les arrêts, opérateurs ou courses sans nom reçoivent un libellé de remplacement identifiable plutôt qu'un champ vide qui perturberait votre affichage.
Une destination toujours visible pour les voyageurs
Si la destination d'une course manque, nous la complétons à partir du dernier arrêt pour que votre application puisse l'afficher.
Des indications de langue fiables
Si la langue déclarée dans le flux ne correspond pas à celle de l'opérateur, nous la corrigeons. Votre localisation peut s'appuyer sur ce champ.
Calendriers et horaires
Périodes sans service réel, arrivées après les départs ou vitesses physiquement impossibles : se fier au flux brut peut conduire à traiter des erreurs d'export comme des horaires réels.
Des calendriers qui reflètent le service réel
Les périodes inutilisées, entrées contradictoires et calendriers en double sont détectés et supprimés avant de proposer un trajet un jour sans service.
Des horaires sans chronologie contradictoire
Lorsque l'arrivée à l'arrêt actuel précède le départ de l'arrêt précédent, nous corrigeons cette erreur d'export récurrente et signalons les rares flux où elle est trop fréquente pour être corrigée sans examen.
Des heures de départ et d'arrivée pour chaque course
Les champs horaires vides sont vérifiés et complétés pour que les systèmes en aval n'aient pas à deviner l'heure de départ réelle.
Aucune course impossible à planifier
Une course dont le premier ou le dernier horaire manque ne peut pas être planifiée. Nous la supprimons avant qu'elle ne perturbe silencieusement un trajet.
Une représentation correcte du service de nuit
Les départs après minuit sont convertis dans un format horaire GTFS valide sans modifier le service réel. C'est un détail que les parseurs simples gèrent souvent mal.
Des horaires exacts clairement identifiés
Le champ timepoint est défini automatiquement selon la présence d'heures d'arrivée et de départ réelles. Il n'est pas laissé vide à l'interprétation de chaque utilisateur.
Aucune course physiquement impossible
Les intervalles de fréquence qui se chevauchent sont corrigés et les courses à vitesse impossible supprimées. Les voyageurs ne doivent pas voir un bus roulant à 2 000 km/h.
Arrêts et coordonnées
Deux opérateurs publient séparément le même arrêt, une course référence un stop_id absent du flux et les informations d'accessibilité sont manquantes ou erronées.
Le bon type pour chaque arrêt
Le type de lieu est défini automatiquement pour les simples points d'embarquement. Les courses faisant référence à un type d'arrêt inadapté sont détectées avant de perturber votre carte.
Des gares avec leurs accès réels
Les entrées, sorties et liens vers la gare principale sont ajoutés à partir d'une base de pôles d'échange entretenue. Les gares principales mal placées sont repositionnées à leur emplacement réel.
Aucune course invalidée par un arrêt manquant
Si une course référence un arrêt absent de stops.txt, nous le reconstituons. Lorsque c'est possible, son nom et ses coordonnées proviennent des données officielles britanniques NAPTAN. La course reste ainsi utilisable.
Des informations d'accessibilité fiables
Une gare est considérée comme accessible dès qu'un quai l'est, et inaccessible seulement si tous ses quais le sont explicitement. Les informations manquantes restent inconnues au lieu d'être présentées comme un refus d'accès.
Précision et compacité
Les coordonnées sont arrondies à six décimales, avec une précision inférieure au mètre. Cela réduit la taille des fichiers tout en conservant des positions précises.
Un lieu, une seule entrée d'arrêt
Des arrêts distants d'environ 20 mètres et desservis dans le même sens sont reconnus comme un même lieu physique et fusionnés au lieu d'apparaître en double sur la carte.
Les bons modes de transport pour chaque arrêt
Le mode de transport d'un arrêt est déduit des lignes qui le desservent réellement. La carte et les filtres affichent la bonne icône sans requête supplémentaire.
Des données par ville sans traitement géographique supplémentaire
Chaque arrêt est rattaché à sa ville pour permettre directement les exports par ville et les filtres API.
Aucune course sans parcours
Une course avec un seul arrêt ne représente pas un véritable service. Elle est supprimée avec les doublons d'arrêts qui lui sont souvent associés.
Lignes et tarifs
Le type de véhicule, la couleur ou les informations tarifaires d'une ligne sont souvent mal codés, vides ou copiés d'un autre champ du flux.
Les bons types de véhicules pour vos utilisateurs
Les types de véhicules, noms de lignes et rattachements aux opérateurs erronés sont détectés et corrigés à l'aide d'une table entretenue par notre équipe de données.
Aucun type de ligne inconnu
Les types de lignes manquants ou invalides sont définis sur bus pour éviter une valeur inconnue dans votre application. Chaque correction déclenche un signalement interne pour vérifier manuellement les cas inhabituels.
Des couleurs de lignes toujours lisibles
Les codes couleur invalides sont corrigés. Les couleurs de texte manquantes sont choisies en fonction du fond pour garantir la lisibilité des lignes.
Aucun lien redondant dans les données des lignes
Une URL de ligne qui répète simplement le site de l'opérateur est vidée.
Les petits détails sont aussi pris en compte
Pour les courses en ferry, le champ autorisant les vélos est correctement défini. Cela supprime un avertissement de validation présent par défaut dans de nombreux flux.
Des tarifs conformes à la spécification GTFS
Les champs des règles tarifaires sont vérifiés et corrigés selon la spécification GTFS avant livraison.
Identifiants stables, tri et rapidité
Un fournisseur renumérote ses courses entre deux mises à jour, deux sources publient la même ligne avec des identifiants différents et le flux brut n'ordonne pas les courses de la journée.
Reconnaître la même ligne dans plusieurs sources
Les lignes reçoivent une empreinte calculée à partir de leur géographie réelle. Une même ligne publiée par deux sources est ainsi reconnue et n'apparaît pas en double.
Une identité de course stable malgré les nouveaux identifiants sources
Les courses sont reconnues par leur suite d'arrêts et leurs horaires. Une même course planifiée conserve son identité au fil des mises à jour hebdomadaires, même si le fournisseur renumérote ses identifiants.
Aucune course en double
Les courses ayant la même empreinte de ligne et d'horaires sont reconnues comme identiques et fusionnées en un enregistrement de référence.
Des résultats dans le bon ordre
Chaque course reçoit un ordre quotidien stable pendant le traitement. Votre application et la nôtre n'ont donc pas à retrier les courses à chaque requête.
Une séquence d'arrêts continue
Les numérotations inhabituelles sont remplacées par une séquence continue commençant à zéro, ce qui simplifie le traitement des arrêts d'une course.
Une identité d'arrêt stable entre les mises à jour
Les arrêts sont reconnus par leur nom, leurs coordonnées et leur mode de transport. Un même arrêt physique peut ainsi être suivi entre les sources et les mises à jour hebdomadaires.
Des tracés adaptés et rapides à afficher
Les points de géométrie superflus sont supprimés et les distances recalculées pour réduire le volume des données. Un tracé très éloigné de la course réelle est dissocié au lieu de produire une carte trompeuse.
Opérateurs, fuseaux horaires et requêtes
Un fuseau horaire d'opérateur incorrect ou absent peut décaler les arrivées d'une heure pour chaque voyageur, chaque jour, jusqu'à ce que l'erreur soit remarquée.
Des coordonnées de contact utilisables
Les adresses e-mail et URL invalides sont vidées. Si l'URL obligatoire de l'opérateur manque, une valeur de remplacement permet aux systèmes en aval de continuer à fonctionner.
Des langues d'opérateurs clairement définies
Une langue d'opérateur manquante est complétée à partir de la langue par défaut du pays pour fournir une base exploitable à votre localisation.
Des heures de départ correctes
Les fuseaux horaires invalides ou géographiquement inadaptés des opérateurs et des arrêts sont corrigés. Ils comptent parmi les principales causes d'arrivées décalées d'une heure dans les calculateurs d'itinéraires.
Des règles de correspondance avec des destinations valides
Les règles de correspondance qui font référence à des arrêts ou lignes inexistants sont supprimées avant de perturber la recherche d'itinéraires.
Connaître immédiatement les lignes desservant un arrêt
Chaque arrêt dispose d'un index précalculé de ses lignes. L'API peut le consulter directement au lieu de recalculer les relations à chaque requête.
Traitement des données en temps réel
La synchronisation GTFS-RT est l'une des tâches les plus difficiles du traitement des données de transport. Chaque fournisseur utilise ses propres identifiants, formats et conventions de nommage, à rapprocher en temps réel des horaires statiques. En complément du traitement statique, nous appliquons des règles spécifiques d'association en temps réel :
- Vérification géographique des positions : les coordonnées hors de la zone de service sont automatiquement rejetées. Un cas réel concernait un flux londonien signalant des bus aux États-Unis.
- Lors de la fusion de flux d'opérateurs, un même identifiant de ligne peut apparaître plusieurs fois. La priorité d'association entre ces doublons est alors explicitement conservée. Même opérateur et même ligne, 2 sources → priorité d'association conservée
- L'association des courses ne se limite pas à la proximité horaire : si une arrivée en temps réel tombe entre deux courses planifiées, l'association utilise une fenêtre temporelle asymétrique, et non le point médian. Horaire entre 2 courses planifiées → association par fenêtre 75/25
- Une procédure progressive recherche d'abord l'association la plus précise et n'assouplit les critères qu'en cas d'échec, au lieu d'appliquer une règle du tout ou rien. Arrêt et horaire exacts manquants → vérifier d'abord ligne et course, puis ligne et horaire
- Si une information ne peut pas être associée de façon fiable, par exemple sans direction ni rapprochement alternatif valable, elle reste explicitement sans association : aucune supposition n'est faite. Direction manquante, aucun rapprochement alternatif → aucune association
- Prévisions d'arrivée aux arrêts dont les données en temps réel sont tardives ou manquantes
Traitement propre à chaque pays
En complément du traitement général, nous développons des règles par pays pour prendre en compte les formats locaux, les standards de codage et les particularités des opérateurs. Elles répondent aux problèmes réels des données de chaque fournisseur.
Les données qui font fonctionner BusMaps
Les mêmes données traitées alimentent la recherche d'itinéraires, les tableaux de départs et les réponses API de BusMaps. Utilisez-les via notre API ou demandez des jeux corrigés pour votre infrastructure.
Des données de transport corrigées pour votre projet
Demandez du GTFS corrigé, du GeoJSON ou des exports personnalisés, ou intégrez notre API. Précisez la couverture, les formats et la fréquence d'actualisation nécessaires pour convenir de la livraison ou de l'intégration.