-- Leo's gemini proxy
-- Connecting to unbon.cafe:1965...
-- Connected
-- Sending request
-- Meta line: 20 text/gemini;
Si la conflation via JOSM[1] est relativement efficace lorsqu'il s'agit d'éléments à faible emprise géométrique[2] – Ou plus généralement d'éléments physique[3] –, la tâche s'avère plus ardue dès lors que les éléments sont de géométrie étendue, complexe, ou sans physicalité comme c'est le cas d'un réseau routier.
Soit deux villages, et sommets, A et B. Une route, et arête, les reliant pourrait être tantôt limitée à 50 km.h⁻¹, tantôt à 80 km.h⁻¹, conduisant à deux arêtes successives. De son côté, OpenStreetMap pourrait avoir divisé cette route en trois arêtes sur la base des aménagements cyclables avec une bande à proximité des villages mais rien entre les deux – Toute ressemblance à des faits réels ne serait pas une coïncidence. Comment faire un mélange des deux graphes avec pour seuls éléments l'emprise des arêtes ?
Cette difficulté prend source directement dans la manière dont le rapprochement est réalisé par l'outil de conflation : par défaut, l'extension JOSM compare les données selon les barycentres. Or cette distance peut être importante, notamment si les sections ne sont pas découpées de manière similaire. OpenStreetMap souffre notamment d'une forte fragmentation de part son modèle où les attributs sont directement appliqué sur le graphe sous-jacent, mais il est possible qu'à l'inverse de larges tronçons soient gardés uniques par manque de détail.
Je vois à priori trois niveaux d'automatisation pour réaliser cela :
la méthode manuelle bête et méchante par comparaison des deux graphes ;
la méthode automatique avec extraction du graphe OSM – Indépendamment de la géométrie –, jonction des attributs de référence par comparaison de graphe, et réinsertion sur OSM via l'identifiant ;
la méthode semi-automatique où une carte des différences est réalisée par superposition des éléments (avec un tampon plus ou moins important sur le linéaire) et une combinaison sur le mode de symbologie des couches. Cela permet de filtrer et uniquement garder les sections (on ne peut pas vraiment parler d'arêtes) différentes à corriger.
Dans l'idéal la méthode automatisée serait géniale, en pratique j'en suis aujourd'hui incapable. À défaut, je pars sur les méthodes manuelle ou semi-automatique ; Avis à l'école de la géomagique de nous montrer des arcanes.
J'ai récemment produit un jeu de données mettant en évidence les limitations de vitesses de certains itinéraires départementaux à partir d'informations de type LRS[4]. C'est un exemple parmi tant d'autres de cas d'usage qui requièrent le développement de solutions pour la maintenance au fil du temps.
La première étape a été la sélection de clés d'intérêt :
`maxspeed`, duh ;
`ref:CDSR`, le retour à 90 km.h⁻¹ a été défini selon des itinéraires par le Commission Départemental de Sécurité Routière ;
`ref`, non essentiel après que j'ai manuellement intégré cette information il y a quelques temps. Appréciable néanmoins pour vérification ;
`source:maxspeed`, ça permet de nuancer l'information si des personnes venaient à trouver des erreurs.
À noter que le récolement préalable des numéros de routes départementales me permet de significativement limiter le nombre de données OSM à télécharger : `ref~"D " and type:way in Doubs`. Je savais bien que ce serait utile !
Le réhaussement étant fait dans une logique d'itinéraire, la méthode semi-automatique ne m'est pas utile : je sais pertinemment que je serai le seul en possession du numéro attribué par le CDSR.
S'en suit une phase longue et ennuyeuse où je superpose et redécoupe les deux graphes ponctués de nœuds-sommets. Quelques 566 arêtes plus tard – En réalité 241, je me suis rendu compte en cours de route de la qualité discutable des données, je me suis restreint à seulement ajouter les sections à 90, et la référence d'itinéraire –, je suis plutôt satisfait de mon travail et rajoute une raison de plus en opposition au retour à 90 km.h⁻¹. Le travail est néanmoins désormais public, par exemple via une carte uMap[5] montrant encore la marge de progression possible en terme de détails – À juste titre, s'il faut à chaque fois y passer plusieurs heures.
Mention spéciale pour l'extension WayDownloader qui m'a grandement simplifié la tâche (et sera sûrement utile à l'avenir si je dois toucher à des itinéraires de bus) avec sa fonction de sélection de tronçons reliant deux chemins.
-- Response ended
-- Page fetched on Mon May 20 08:29:02 2024