OpenStreetMap

JOSM : Conflation

Posted by Lejun on 19 January 2023 in French (Français).

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.

Principe général

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.

Extension « Conflation »

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.

Prétraitement des données de référence

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 puristes 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 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 :

  • ID Emplacement, qui correspondra à la clé ref selon le modèle BNSC ;
  • Type d’arceau qui correspond directement à bicycle_parking ;
  • Nombre d’arceaux qui me permettra de déduire capacity. Attention cependant, il est indiqué sur le jeu de données que c’est au « sens patrimonial » : cintrés et carrés comptent pour deux places tandis que ranges-vélos et attaches vélo-cargos comptent pour un. Ça devient complexe et je suis plutôt content d’utiliser un tableur plutôt que d’essayer en faire sens sous JOSM ;
  • Abri vélo semble correspondre à l’idée d’un bâtiment building plutôt que simplement la couverture face aux intempéries covered, ce dernier sera logiquement inscrit puisque découle du premier ;
  • Gestionnaire indique si l’emplacement dépend de l’Eurométropole ou non, operator ;
  • Date d’installation correspond à start_date ;
  • Date de dernier remplacement, a un sens abstrait, aussi je conserverai la date initiale d’installation ;
  • Date de levée a également un sens obscur. Il apparaît que cela soit un nouveau format apporté par la suite. Seul 8 cas de chevauchement de l’installation et la levée apparaîssent. Dans le doute on va le mettre dans start_date ;
  • ID sous tronçon indique l’identifiant du tronçon de route le plus proche. Inutile pour nous ;
  • Source de l’information est explicite, cela reste inutile pour nous et on se contentera de citer le jeu de données en commentaire du groupe de modifications comme il est d’usage ;
  • Date de MAJ semble correspondre au suivi de la maintenance, inutile pour nous tant cela reste abstrait ;
  • Date de création semble être celui de la donnée et non de l’installation en elle-même ;
  • Geo Point, donne les coordonnées géographiques de l’élément. C’est probablement ce qui est interprété par JOSM pour le positionner ;
  • Geo Shape. permet de décrire la géométrie de l’élément. Il permet notamment d’indiquer la forme d’une rangée d’arceaux. Bien qu’intéressante, cet usage ne semble pas commun sur OpenStreetMap et on lui préfère un centroïde au milieu de l’installation ou un polygone s’il s’agit d’un bâtiment couvert.

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.

Mise en place du jeu de données « Sujet »

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.

 Traitement JOSM

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.

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.

Location: Centre, Strasbourg, Bas-Rhin, Grand Est, France métropolitaine, France

Discussion

Comment from JIBEC on 31 January 2023 at 20:31

merci pour l’explication ! je ne suis pas sûr de réussir à le faire seul, mais un jour si je trouve un jeu de données qui me motive, peut-être on fera un atelier ensemble !

Tu parles de faire une tâche d’intégration dans Osmose, mais je vois rien dans https://osmose.openstreetmap.fr/fr/map/#zoom=11&lat=48.6156&lon=7.7899&item=xxxx&level=1%2C2%2C3&tags=bicycle tout est déjà terminé ?

Une fois ces données dans Osmose, y a-t-il un moyen simple de les embarquer avec soit sur le terrain ?

j’aimerais bien : * extraire des données d’une ou plusieurs quêtes, * puis aller sur le terrain avec mon vélo * faire des photos * revenir sur mon ordinateur, voir mes données et les photos * contribuer

As-tu une suggestion ou existe-t-il un guide quelque part ?

Comment from Lejun on 1 February 2023 at 06:54

De rien ! Au final c’est pas tant un tutoriel qu’un mémo pour la prochaine fois où j’aurai à bricoler la chose. Si des ateliers sont organisés je passe volontier faire un tour.

Pour ce qui est d’osmose j’avoue ne pas trop comprendre non plus. Le fichier semble avoir été intégré sur Github mais sur l’outil on voit toujours que Bordeaux, Paris, et Madrid. Faut que j’aille en discuter avec eux voir ce qui s’en dit.

Pour avoir les données Osmoses tu peux effectivement faire un export – c’est proposé dans la barre supérieure – que tu ouvriras dans l’éditeur de ton choix (je recommande OsmAnd pour la navigation, ou Vespucci si t’as besoin d’éditer sur place). Pas – encore – de guide à ma connaissance, mais si je le fais (une fois que la météo se réchauffe) alors j’en ferai également un petit guide.

Comment from Gonéo on 2 February 2023 at 21:50

Je viens de faire la même chose sur la métropole de Lyon. Environ 5.400 parkings dans l’open-data. Les noms des champs étaient différents mais le principe est le même.

Pour faciliter le rapprochement par le module Conflation j’ai utilisé le champ ref et/ou ref:FR:GrandLyon qui correspond à l’identifiant dans l’open-data et qui est déjà présent dans de nombreux parkings lyonnais. Ceci est utile quand 2 parkings sont très proches.

Je ne sais pas si c’est une limite de Conflation (je n’ai pas creusé) mais le rapprochement ne se fait pas si le parking existant dans OSM est une ligne ou une surface. J’ai rencontré ce cas de temps à autre.

Pour vérifier l’emplacement j’ai utilisé l’ortho IGN, avec en transparence le fond de carte OSM. La combinaison des 2 permet de bien comprendre le terrain. Suite à la nouvelle loi qui interdit le stationnement à moins de 5 mètres d’un passage piéton, la métropole a entrepris de placer de nombreux parkings à vélo juste en amont des passages piétons. Dans de nombreux cas, la cohérence de l’emplacement devient très simple à vérifier même si les arceaux ne sont pas visibles en imagerie aérienne.

Dans une première étape j’ai commencé par ajouter tous les parkings présents dans la référence (open-data) mais pas dans le sujet (osm).

Il me reste encore 2 points à traiter.

L’une des étapes concerne tous les arceaux présents dans OSM mais pas dans l’open-data. Plusieurs causes sont possibles:

  • Je sais que l’open-data a du retard. S’il y a un arceau récent dans OSM, sans le champ ref c’est qu’il a été ajouté sur le terrain, et qu’il faut patienter pour l’open-data.
  • Il y a aussi des arceaux perdus qui sont présents sur le terrain depuis des années mais qui ne sont pas connus de l’open-data. J’ajoute un noref=yes et je renseigne le champ note pour préciser l’info histoire ne de pas se poser la question la prochaine fois.
  • Il y a des arceaux avec un champ ref mais qui n’existent pas dans l’open-data. Certains ont été physiquement retirés suite à des aménagements de voirie. Dans ce cas je laisse un FIXME et une note OSM qui demande à vérifier si les arceaux existent encore.
  • J’ai laissé beaucoup de notes/fixme et petit à petit il y a des retours positifs ou négatifs sur leur existence.

L’autre étape concerne tous les arceaux qui ont un écart de position significatif. Cet écart peut aller jusqu’à 20 mètres (4 places de parking en longitudinal).

  • J’ai aussi laissé des notes/fixme en demandant de vérifier la position. Je vais extraire un GPX avec ces cas et les vérifier avec l’asso vélo.
  • Dans certains cas, c’est OSM qui a raison. Je renseigne alors les champs
    • note=position corrigée par rapport à l’open-data
    • source:geometry=survey
    • source:geometry:date=2022-11
  • Noter que certains arceaux ont été déplacés de quelques mètres suite à des réaménagements.

Comment from Lejun on 3 February 2023 at 06:11

Je ne sais pas si c’est une limite de Conflation (je n’ai pas creusé) mais le rapprochement ne se fait pas si le parking existant dans OSM est une ligne ou une surface. J’ai rencontré ce cas de temps à autre.

C’est étrange, sur Strasbourg j’ai eu aucun soucis avec du linéaire ou du surfacique. Je pense que l’erreur doit pas venir de Conflation.

Login to leave a comment