💾 Archived View for unbon.cafe › lejun › posts › 20230117_josmConflation.gmi captured on 2024-02-05 at 09:56:19. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-03-20)
➡️ Next capture (2024-05-10)
-=-=-=-=-=-=-
La conflation, également appelée appariement ou fusion de cartes, permet d’obtenir un jeu de données à partir de plusieurs. Cela vise en autres à une meilleure qualité, et à limiter la redondance des données. Différents outils et méthodes permettent cela sous OpenStreetMap, dont une extension JOSM.
L’idée générale est simple, il suffit de prendre les deux jeux de données et comparer un à un chacun des éléments de part leur géométrie (position spatiale et forme) et caractéristiques. Manuellement, comparer des données spatiales revient à avoir chaque jeu de données sur un calque et superposer les deux pour mettre en évidence les différences géométriques avant de comparer les caractéristiques de chacun d’eux et voir si une version est plus précise que l’autre, ou si des données concurrentes apparaissent. Numériquement, le même principe est utilisé, seulement il est grandement facilité via des scripts automatisés qui apparient les données selon différent critères. Mais bien sûr, rien n’empêche de le faire manuellement avec les données sur deux calques, ce sera juste très long et répétitif.
L’extension repose sur la fonction « Remplacer la géométrie » de l’extension « UtilsPlugin2 » qu’il faut également installer. Cette fonction permet de fusionner les caractéristiques de deux éléments en ne conservant qu’une seule des deux géométries.
Les deux jeux de données auront un rôle de « Référence » et de « Sujet ». Le premier correspondant usuellement aux données à importer et le second aux données OpenStreetMap.
Par simplicité, je préfère travailler les données en dehors de JOSM via un tableur ou des commandes de remplacement. Il s’agit alors de transformer les données de manière à coller aux attributs OpenStreetMap en perdant le moins possible de détails. Les vrais le feront sous format GeoJson, Shapefile ou que sais-je encore, je suis un homme simple, j’aime les csv.
Pour l’exemple, je vais chercher à traiter les quelques 7819 emplacements de stationnement vélo recensés par l’Eurométropole de Strasbourg. Une version conforme à la Base Nationale de Stationnement Cyclable permettrait une transformation quasiment à 1 pour 1 des attributs mais j’ai préféré en faire une tâche d’intégration sur Osmose[1] et réaliser cette harmonisation manuellement. Cette version disposant également de plus de détails concernant le type de stationnement – La conflation sert à gagner en qualité.
Le fichier dispose de 14 champs :
Ainsi, le seul pré-traitement réel à effectuer est d’effectuer la correspondance des types d’arceaux ainsi que d’en calculer la capacité. Il semble dans les fait que `cintré` et `carré` soient utilisés pour distinguer deux modèles d’installation qui rentrent sous la catégorie des `stands`, il y a ici une perte de données qui pourrait être compensée à l’aide de la clé `model` si la référence venait à être trouvée. Dans le jeu, 478 emplacements sont indiqués comme abri-vélos, des opérations sont à prévoir dans l’étape suivante.
Dernière étape avant de réellement voir le jeu de données à importer, il faut trouver les données sur OpenStreetMap. En théorie il serait possible de simplement télécharger toute la zone couverte par les données « Référence » mais à moins d’avoir un ordinateur boosté aux hormones on va préférer faire une requête sur les éléments qui nous intéressent uniquement. C’est l’heure de dégainer Overpass. Rien de folichon ici,
Loin de moi la prétention de maîtriser l’art des requêtes, je vais plutôt tabler sur l’assistant pour qu’il me donne tous les `amenity=bicycle_parking` de Strasbourg… Ou plutôt de l’EuroMétropole de Strasbourg… 3421 éléments trouvés contre un jeu de données de 8000, la journée s’annonce longue.
/* This has been generated by the overpass-turbo wizard. The original search was: “amenity=bicycle_parking in Strasbourg”
Une fois la scène mise en place, ne reste qu’à fusionner. Ouvrez la fenêtre de Conflation et cliquez sur « Configurer ». Sélectionnez et figez – Aucune idée du sens – les données de la couche « Référence », puis la couche « Sujet » et générez les appariements. Veillez à bien, rendre le calque actif, sélectionner toutes les données (Ctrl+A) et de figer. Différentes méthodes d’appariement sont proposées, sans idée je pars avec les paramètres par défaut.
Une particularité à ne pas oublier est que la requête Overpass sélectionne tous les lieux de stationnement peu importe leur géométrie. Or dans la pratique, il est autorisé de les renseigner aussi bien en tant que nœud central, chemin, ou polygone fermé. Ces deux derniers cas sont rares mais possibles, en quel cas il est utile de refaire une sélection par requête directement sur JOSM avant de figer le sujet, ici `bicycle_parking`. Cela permet entre autres d’éliminer les faux positifs avec des nœuds constituant les chemins, ouverts ou fermés, lorsque plusieurs éléments de références sont à proximité – que ce soit réel ou par découpage en lots.
L’onglet de Conflation se remplit de lignes d’appariements. Une colonne colorée de façon criarde indique si la fusion peut se faire automatiquement où si des données sont en conflit. Pour chaque ligne, il suffira alors de valider ou non l’appariement – Toujours dans le sens « Sujet » vers « Référence » pour ce qui est de la géométrie – et de gérer les conflits au cas par cas. Les imprécisions des deux jeux seront mises en évidences.
Des éléments n’ont pas d’apparié et n’existent que sur OpenStreetMap ou dans les données communales. Ici encore, pas de traitement automatique, il faudra se dégourdir et analyser au cas par cas si l’intégration est justifiée ou non, et si nécessaire prévoir des sorties sur le terrain pour l’appuyer. Par défaut, je considère les données OpenStreetMap comme ayant plus de valeur, partant de cela, j’ai précisé lors de l’appariement dans le champ prévu à cet effet d’exclure la valeur `capacity` du jeu de référence. Les conflits ne demanderont pas de résolution mais seront tout de même mis en évidence en couleur jaune.
Sans surprise, une part importate des appariements est correcte : l’élément indiqué dans les données correspondent à ce qui est sur OpenStreetMap. Je peux sélectionner une suite d’éléments sans conflits et de score élevé dans ma liste pour les combiner. Des erreurs surviennent parfois, en particulier lorsque le nœud sur OpenStreetMap fait partie d’un polygône. À priori cela n’a pas lieu d’être et ce sont souvent une limite venant de l’appariement, mais également des données OpenStreetMap où un élément a été relié par erreur à un `bicycle_parking`. L’appariement peut ainsi être supprimé de la liste. Cela aurait pu être évité en filtrant de nouveau les données OpenStreetMap sous JOSM via un filtre ne conservant que les `bicycle_parking`.
Parmi les conflits pouvant survenir, on retrouvera où des erreurs de `capacity` ou de `bicycle_parking`. Le premier cas est plutôt courant selon la manière de diviser les stationnements. Là où il sera facile de ne voir qu’un lot de 60 places, celui-ci peut officiellement être divisé en plusieurs lots. Dans le second c’est plus complexe et il faudra déterminer au cas par cas. Ce que je considère comme étant une erreur de cartographie, bien qu’approuvé, est l’attribut `bicycle_parking=building`. Il ne permet pas de déterminer le type de mobilier à disposition pour attacher son vélo, et pourrait être remplacé par `covered=yes`, `indoor=yes` (répandu pour les défibrillateurs), ou encore `building=yes`.
Faute de raccourcis à l’extension, ma méthode est globalement de naviguer entre les éléments avec les flèches directionnelles (la touche Entrée permet de zoomer sur la sélection) et d’alterner entre appariements à supprimer et appariement valides. Cela permet de rendre le processus plus agréable – dans une certaine mesure – que la machine à clics que cela serait autrement.