Comment on a construit un moteur d'accessibilité et de temps de déplacement à l'échelle du Canada

Quand un chercheur en santé publique en Nouvelle-Écosse veut cartographier les déserts alimentaires, il doit répondre à des questions comme : quels ménages peuvent atteindre une épicerie en 15 minutes de marche? Quand un planificateur de transport à Calgary évalue un nouveau trajet d'autobus, il doit comprendre comment ça change l'accès aux centres d'emploi. Quand un militant pour le logement à Toronto argumente qu'un quartier est mal desservi, il a besoin de données qui montrent combien de temps ça prend aux résidents pour se rendre aux écoles, cliniques et parcs.

Ce sont des questions d'équité. Quand on cartographie les déserts alimentaires, on identifie des communautés à risque. Quand on analyse l'accès au transport vers l'emploi, on mesure les opportunités économiques. Quand on calcule le temps requis pour atteindre les écoles et les cliniques, on quantifie des barrières qui affectent de manière disproportionnée les quartiers à faible revenu.

Toutes ces questions dépendent de la même information de base : des temps de déplacement réalistes. Pas des distances à vol d'oiseau, mais des trajets réels qui suivent de vraies rues, respectent les sens uniques, et tiennent compte si quelqu'un marche, fait du vélo, ou conduit.

Chez Curbcut, on a construit ça pour servir plusieurs intervenants et besoins de recherche à partir d'une seule fondation. Plutôt que de calculer les temps de déplacement des domiciles vers les épiceries, puis recalculer pour les cliniques, puis encore pour les parcs, on a construit une infrastructure réutilisable : les temps de déplacement entre chaque îlot de diffusion (la plus petite unité géographique que Statistique Canada publie, l'équivalent d'un pâté de maisons). Dès que la matrice des temps de déplacement entre îlots est construite, l’accessibilité à toute destination se résume à une simple consultation de cette matrice. On assigne l'épicerie à son îlot, et les temps de déplacement sont déjà là. Le chercheur sur les déserts alimentaires et le planificateur de transport puisent dans la même fondation sans déclencher de nouveaux calculs ou dupliquer les efforts.

Cette approche implique de travailler à l'échelle nationale. Et bien que cette conception soit simple conceptuellement, son ampleur ne l'est pas. Avec environ un demi-million d'îlots de diffusion au pays, le nombre de combinaisons origine-destination croît de façon quadratique.

Pourquoi cette infrastructure est importante pour l'analyse d'équité

Avant de plonger dans le défi technique, il vaut la peine de comprendre pourquoi résoudre ce problème compte. Les études d'accessibilité traditionnelles sont souvent limitées à des villes individuelles ou des cas d'usage spécifiques parce que calculer les temps de déplacement à grande échelle est prohibitif sur le plan informatique. Ça veut dire :

• Les communautés rurales et plus petites sont souvent exclues de l'analyse

• Les comparaisons interrégionales sont impossibles

• Les chercheurs et militants manquent de données pour faire des arguments basés sur des preuves

• Les décisions politiques sont prises sans comprendre leurs impacts sur l'accessibilité

En construisant une infrastructure à l'échelle nationale, on permet au chercheur en Nouvelle-Écosse, au planificateur de Calgary et au défenseur de Toronto de poser leurs questions sans avoir besoin de leur propre infrastructure technique. C'est ça, la démocratisation des données en action.

Pourquoi c'est difficile : La malédiction des nombres au carré

Une matrice de temps de déplacement jumelait chaque origine avec chaque destination. Pour 500 000 îlots de diffusion, ça fait 500 000 multiplié par lui-même : 250 milliards de paires.

Pour mettre ça en perspective : si vous stockiez chaque temps de déplacement comme un seul nombre, le fichier résultant dépasserait un téraoctet. Aucun ordinateur ordinaire peut garder ça en mémoire, encore moins le calculer dans un temps raisonnable. La plupart des logiciels de routage présument que vous calculez une poignée de trajets, peut-être quelques milliers. On avait besoin de quelque chose de complètement différent.

L'intuition clé : Jeter ce dont on n’a pas besoin

La percée, c'était de reconnaître que la plupart de ces 250 milliards de paires n'ont aucun sens. Le militant de Toronto n'a pas besoin de savoir combien de temps ça prend pour marcher d'un quartier de Scarborough à une école à Vancouver. Personne ne marche 200 kilomètres pour aller faire les emplettes. Un trajet de 4 heures en auto n'est pas pertinent pour l'accessibilité quotidienne.

Donc au lieu de tout calculer, on filtre d'abord. Pour chaque origine, on identifie seulement les destinations dans un rayon de déplacement réaliste :

• Marche : 10 kilomètres (environ une heure à un bon rythme)

• Vélo : 30 kilomètres

• Auto : 120 kilomètres

On utilise une technique d'indexation spatiale qui trouve rapidement tous les îlots de diffusion à l'intérieur de ces distances. Un îlot au centre-ville de Montréal pourrait avoir quelques milliers de voisins dans un rayon de 30 kilomètres ; un dans le nord du Québec pourrait en avoir une douzaine. De toute façon, on a réduit le problème de centaines de milliards de paires à environ 150 millions, une réduction de 99,94%.

On calcule des temps de déplacement exacts pour chaque paire qui pourrait raisonnablement compter pour l'analyse d'accessibilité.

Calcul d’itinéraire à grande échelle

Pour calculer des temps de déplacement réalistes, on s'appuie sur l'Open Source Routing Machine (OSRM), le même moteur de calcul d’itinéraire à code source ouvert utilisé dans plusieurs outils de navigation. Il calcule des trajets le long de vrais réseaux routiers en utilisant les données d'OpenStreetMap, en tenant compte des sens uniques, restrictions de virage, et différences entre la marche, le vélo et l'auto.

On héberge OSRM nous-mêmes sur nos propres serveurs en utilisant des conteneurs Docker. Ça nous donne un contrôle complet sur la capacité, la configuration et l'optimisation, ce qui est crucial quand on traite des millions de requêtes. Contrairement à appeler une API externe avec des limites de taux, on peut ajuster notre infrastructure aux besoins spécifiques de l'analyse d'accessibilité à grande échelle.

OSRM est conçu pour répondre à des questions comme : combien de temps ça prend pour aller d'ici à là? Pour un petit nombre de trajets, ça marche extrêmement bien.

Le défi apparaît à grande échelle. OSRM est construit comme une conversation : vous posez une question, il répond avec une réponse. Quand vous avez besoin de réponses pour des millions de trajets, le temps passé juste à poser et recevoir ces questions dépasse de beaucoup le calcul réel du trajet. Le calcul de l’itinéraire lui-même est rapide ; c'est la communication aller-retour d’une machine au serveur OSRM qui devient le facteur limitant.

Le problème HTTP (et comment on l'a résolu)

Chaque fois que vous demandez à OSRM un temps de déplacement, votre ordinateur ouvre une connexion, envoie des coordonnées, attend une réponse, et ferme la connexion. Ces échanges prennent du temps, souvent plus de temps que le calcul réel du trajet.

Si on envoyait les requêtes une à la fois, on passerait la plupart de notre temps à attendre les allers-retours réseau, pas à calculer des trajets. OSRM serait inactif pendant que notre code traite chaque réponse.

La solution, c'est le traitement par lots et le parallélisme. Au lieu de demander un trajet à la fois, OSRM accepte plusieurs coordonnées et retourne une matrice de temps de déplacement entre elles. Et au lieu d'attendre chaque réponse avant d'envoyer la prochaine requête, on lance plusieurs requêtes simultanément.

À travers des tests extensifs, on a trouvé les points optimaux :

• Les connexions simultanées devraient être proportionnelles à la capacité de votre serveur. Trop peu, et le moteur de routage reste inactif entre les requêtes. Trop, environ au-delà de trois fois vos threads CPU disponibles, et vous créez juste une file d'attente. Les requêtes s'accumulent en attendant d'être traitées, et certaines commencent à expirer.

• La taille des lots implique un compromis. Des lots plus petits signifient plus de requêtes, ce qui signifie plus de surcharge de connexion. Mais des lots plus grands font que chaque calcul individuel prend plus de temps, la complexité croît avec le carré du nombre de coordonnées, et des requêtes surdimensionnées risquent d'échouer complètement. On a trouvé un juste milieu : assez gros pour minimiser la surcharge, assez petit pour des réponses fiables en moins d'une seconde.

Avec la bonne configuration, le pays au complet se complète en heures plutôt qu'en semaines.

Stocker les résultats : des listes, pas des matrices

Les données de temps de déplacement traditionnelles viennent sous forme de grille géante : des rangées pour les origines, des colonnes pour les destinations, des cellules pour les temps de déplacement. Ce format présume que vous avez besoin de chaque cellule, ce qui n'est pas notre cas.

À la place, on stocke les résultats comme une collection de listes. Chaque origine a sa propre table compacte contenant seulement ses destinations atteignables et les temps de déplacement correspondants. Un îlot de diffusion en banlieue d'Ottawa pourrait avoir 800 entrées ; un en zone rurale du Manitoba pourrait en avoir 40. On stocke exactement ce qui a du sens de calculer et garder, rien de plus.

Ce format épars signifie que notre ensemble de données national tient confortablement en mémoire sur un poste de travail standard. Les requêtes sont rapides parce qu'on ne cherche pas à travers des cellules vides.

Ce que cette infrastructure permet

La Ville de Laval utilise ces temps de déplacement dans Curbcut Laval pour évaluer les emplacements proposés pour de nouvelles installations communautaires. Quand ils planifient où installer une nouvelle bibliothèque ou un centre communautaire, les planificateurs urbains peuvent instantanément voir quels quartiers ont actuellement les temps de déplacement les plus longs vers les installations existantes, garantissant que les nouveaux investissements atteignent les secteurs qui en ont le plus besoin.

Cette même infrastructure rend maintenant possible une analyse similaire partout au Canada :

• Les chercheurs en santé publique peuvent cartographier les déserts alimentaires à travers des provinces entières, identifiant quelles communautés rurales sont au-delà de 15 minutes de route de n'importe quelle épicerie.

• Les planificateurs de transport peuvent comparer l'accès cyclable aux centres d'emploi à travers les quartiers, identifiant où les investissements en infrastructure feraient la plus grande différence.

• Les défenseurs du logement peuvent montrer précisément quels quartiers font face aux marches les plus longues vers les écoles, cliniques et parcs, et comment ces patterns se décomposent selon le revenu.

Le Pont de données : connecter les temps de déplacement à tout le reste

La matrice de temps de déplacement est puissante en elle-même, mais sa vraie valeur émerge à travers le Pont de données de Curbcut, notre innovation technique centrale qui démocratise l'accès à l'analyse spatiale sophistiquée en intégrant les temps de déplacement avec des milliers d'autres variables de données.

Ça veut dire que les utilisateurs peuvent instantanément explorer des questions comme :

• Comment l'accessibilité au transport en commun se corrèle-t-elle avec le revenu des ménages?

• Quels quartiers avec un mauvais accès aux soins de santé ont aussi de hautes proportions de résidents âgés?

• Où est-ce que les nouveaux développements résidentiels sont construits par rapport aux centres d'emploi?

L'infrastructure qu'on a décrite ici est la fondation, mais le Pont de données la rend actionnable pour les utilisateurs non techniques à travers les plateformes de Curbcut.

De l'infrastructure à l'impact

Calculer les temps de déplacement à l'échelle nationale, ce n’est pas une question de puissance de calcul brute, mais d'être stratégique avec ce que vous calculez et comment vous le calculez. En filtrant vers les paires pertinentes, optimisant le traitement par lots et le parallélisme, et stockant les résultats efficacement, on a transformé un problème impossible en un problème gérable.

Mais la vraie réalisation n'est pas technique, c'est que cette infrastructure peut maintenant alimenter la prise de décision équitable et basée sur les données partout au Canada. Le chercheur en santé publique n'a pas besoin d'engager un ingénieur de données, le planificateur de transport n'a pas besoin d'apprendre Python, et le militant du logement n'a pas besoin d'un budget de recherche.

C'est ça, la démocratisation des données : une analyse sophistiquée, rendue accessible. Et parce que le pays au complet se traite en heures plutôt qu'en semaines, on peut la garder à jour au fur et à mesure que les communautés évoluent.

Prêt à explorer les dynamiques d’accessibilité dans votre communauté? Curbcut offre accès à ces temps de déplacement aux côtés de plus de 2 000 autres indicateurs. Les partenaires municipaux peuvent déployer des plateformes Curbcut pour leurs communautés avec intégration des données locales. Contactez-nous pour discuter comment l'analyse d'accessibilité peut informer votre prochaine décision politique! 

‍