La clinique à 15 minutes qui en prend 25 à pied

Un parent à Carson City, au Nevada, entend dire à l'accueil d'une clinique que celle-ci se trouve à environ quinze minutes. Les deux bâtiments occupent le même fond de vallée plat, à un kilomètre environ l'un de l'autre, et rien là-dedans ne sonne faux.

Le doute est structurel, pas personnel. Un temps de trajet annoncé est une affirmation sur un réseau routier à une heure précise, et la manière honnête de la vérifier consiste à interroger le réseau lui-même. Une requête suffit : renvoyer toutes les routes que le réseau permet d'atteindre depuis la clinique en quinze minutes, et envelopper le résultat dans un polygone. Ce polygone est un isochrone, le diagramme le plus utile et le plus silencieusement trompeur du travail géospatial appliqué. Ce billet parcourt ce que le polygone calcule réellement, et les endroits où il vous ment en chemin.

Ce que le polygone calcule réellement

Sous le capot, un moteur de routage tient le réseau routier sous forme de graphe : les intersections sont des nœuds, les segments de route des arêtes. Chaque arête porte un coût, en secondes généralement, ajusté par les données de trafic que le fournisseur détient pour ce segment. Un calcul d'isochrone déborde ce graphe depuis votre origine jusqu'à épuisement du budget de coût cumulé, puis collecte les extrémités atteintes et recoud leur contour en polygone. Tout ce qui est à l'intérieur de la ligne est accessible dans votre budget, selon les règles du réseau lui-même. Tout ce qui est à l'extérieur ne l'est pas.

Un rayon ne peut rien dire de tout cela. Un rayon, c'est un cercle. Un isochrone est un cercle auquel on a soustrait une rivière et des sens uniques, et auquel on a ajouté un couloir d'autoroute dans l'unique direction que les bretelles permettent. Imaginez un magasin à 4 km de votre porte en ligne droite sur la carte, avec le seul franchissement de la rivière 9 km en aval, et vous aurez compris l'écart entre les deux formes.

Deux candidats, une adresse réelle, trois polygones

Voici l'exemple travaillé, avec une adresse réelle comme ancrage : le Capitole de l'État du Nevada, 101 North Carson Street, Carson City. Imaginons qu'un comité hésite entre deux sites de clinique que le quartier du Capitole pourrait vraisemblablement desservir. Le site A se trouve au sud de la ville, avec un accès immédiat au couloir de l'US 395, et le site B est à quelques kilomètres au nord-est, sur des rues ordinaires. Trois polygones par site répondent à l'essentiel de la vraie question du comité :

Question posée à chaque site	Site A, sud de la ville	Site B, nord-est
15 minutes à pied (approx.)	couvre le centre-ville	à peu près la même surface, décalée vers l'est
15 min en voiture, milieu d'après-midi (approx.)	la plus grande partie de la ville et une partie de la vallée	surface similaire, quartiers différents
15 min en voiture, 8 h 30 un jour de semaine (approx.)	se replie vers l'échangeur	conserve la plus grande partie de sa forme

Considérez ces cellules comme des formes illustratives plutôt que des sorties mesurées. Les chiffres viennent du fournisseur que vous appelez, et ils bougent avec l'échantillon de trafic du jour. Ce qui se vérifie d'un fournisseur à l'autre, c'est le schéma. Un polygone autour d'un site desservi par l'autoroute respire avec l'échangeur, tandis qu'un site de rues ordinaires garde sa forme quand la congestion arrive. Le comité qui classe les sites d'après le polygone pris hors des heures de pointe choisit une clinique différente de celle que ses patients vivent à 8 h 30.

Les requêtes elles-mêmes sont petites. Avec everymap, notre client Rust, le même appel isolines tourne contre HERE, TomTom et Mapbox, ce qui est exactement ainsi que nous avons repéré les désaccords propres à chaque fournisseur dès le départ.

# Illustrative shape of the call, not a pasted transcript
# one call per candidate site and per budget:
#   Site A (south side, US 395 corridor) and Site B (northeast, surface streets)
everymap --api-key $KEY isolines \
  --origin "<candidate site, lat,long>" \
  --transport walk --range 900 \
  --provider here

La même requête en HTTP brut, si vous appelez un fournisseur directement :

# Illustrative endpoint shape; parameter names vary by provider
GET {provider}/v2/isolines?origin={site_lat},{site_lng}&profile=walk&range=900

Exécutez chaque site à chaque budget et superposez les polygones. Comptez ensuite quelle part de votre population réelle de patients, quel que soit votre modèle, tombe à l'intérieur de chaque ligne. Ce compte-là est la réponse que le rayon prétendait vous donner.

La vitesse de marche par défaut est une affirmation que votre bambin conteste

Les isochrones piétons méritent leur propre avertissement. Les profils de marche par défaut des fournisseurs supposent communément un adulte qui avance à environ 5 km/h sur terrain plat. Vérifiez la doc de votre fournisseur, le chiffre exact varie un peu. La marche réelle inclut des traversées calées sur les feux, de la neige sur les trottoirs, une poussette, et un bambin qui a des opinions bien tranchées sur le rythme. Poussez ces réalités en pente, dans une ville qui se tient à environ 1 470 m d'altitude avec des pentes qui montent vers la Sierra, et le polygone des quinze minutes décrit une personne qui n'existe pas. La ligne est une réponse correcte à la mauvaise question.

Faites l'arithmétique pour le parent qui attend à la clinique : à 5 km/h, la vitesse par défaut du moteur, quinze minutes achètent 1,25 km. À la vitesse de 3 km/h que délivrent réellement une poussette, une rampe de trottoir et un feu, ce même cercle prend 25 minutes. Le polygone sur la carte est le premier cercle, et il ne quitte jamais le cabinet.

La correction est bon marché et sans sentimentalité : abaissez la vitesse et réduisez le budget. Acceptez que la distance de marche honnête pour la personne que vous servez soit peut-être le tiers de celle du moteur. Un polygone piéton calculé à la vitesse par défaut est le polygone d'un athlète. Votre parent avec la poussette a besoin d'un polygone plus strict.

Obstacles et bord de l'échantillon de réseau

Trois sources de défaillance vivent en dehors des maths du polygone. D'abord, les obstacles, des plus tangibles aux plus bureaucratiques : une route barrée ici, un chantier qui ferme une rue là. C'est la variante saisonnière qui compte le plus. Certaines routes à l'ouest de Carson City vers la Sierra ferment pour l'hiver, typiquement pour des mois entiers, et un isochrone calculé en juillet ne dit rien de février. Ensuite, l'échantillon de réseau du fournisseur lui-même : les fournisseurs ingèrent et échantillonnent les réseaux routiers à des densités différentes, si bien que le graphe d'un fournisseur peut tout simplement ne pas contenir la route privée qui relie votre origine à l'artère. Enfin, les effets de bord : près de la frontière du polygone, une seule route incluse ou exclue fait basculer des quartiers entiers au-dedans ou au-dehors, et c'est pourquoi les lignes de la quinzième minute de deux fournisseurs divergent bien davantage que leurs lignes de la dixième minute.

Nous avons rencontré ce problème par l'autre bout en construisant everymap. La première conception exposait une table de paramètres unique que tous les fournisseurs acceptaient, et la table rétrécissait à chaque ajout jusqu'à n'exprimer presque plus rien de réel. La correction a consisté à modéliser les isolignes par fournisseur derrière un seul trait, et à laisser les combinaisons non supportées échouer bruyamment. C'est une leçon de conception qui dépasse Rust : une conception silencieuse assise sur le plus petit dénominateur commun est un mensonge avec un code de réponse 200.

Là où le modèle finit et où la personne commence

La limite à dire à voix haute : un isochrone est un modèle d'un réseau routier, tel qu'échantillonné par un fournisseur un jour donné, et ce n'est pas un modèle du trajet d'une personne. Il n'inclut pas les quatre minutes à tourner en rond pour trouver une place, la marche depuis le coin le plus lointain du parking, ni les dix minutes dans la salle d'attente avant que quelqu'un ne regarde le bambin. La précision en heure de pointe comme hors pointe n'est pas meilleure que les données de sonde qui la soutiennent, et celles-ci s'éclaircissent vite loin des grandes villes.

Utilisez les isochrones pour tuer des candidats, jamais pour en couronner un. Les polygones qui manquent la population sont des éliminations. Les survivants méritent une vraie requête de routage, exécutée aux heures exactes où vos utilisateurs se déplacent, avec les véritables adresses d'origine que les gens tapent. Les quinze minutes de la réceptionniste méritent d'être vérifiées. Le réseau garde les reçus.