Conflation d'arêtes

2024-04-19

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.

Automatisation

Je vois à priori trois niveaux d'automatisation pour réaliser cela :

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.

Étude de cas

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 :

À 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.

Références

=> [1] JOSM : Conflation, LeJun 2023 | [2] Conflation : Points de repère, LeJun 2024 | [3] Benchmark of existing open source solutions for conflating structured, geographical and transit data, JungleBus 2020 | [4] QGIS LRS : Vitesses maximales autorisées, LeJun 2024 | [5] Carte des vitesses maximales autorisées dans le département du Doubs, LeJun 2023

Proxy Information
Original URL
gemini://unbon.cafe/lejun/posts/20240419_conflationAretes.gmi
Status Code
Success (20)
Meta
text/gemini;
Capsule Response Time
319.924698 milliseconds
Gemini-to-HTML Time
2.065446 milliseconds

This content has been proxied by September (3851b).