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.