Faire une analyse avec Osmose-Backend

Osmose permet d'analyser les données d'OpenStreetMap et de les comparer à des données ouvertes pour proposer de les réunir, le tout avec une pile logicielle libre en python, et une base de données PostgreSQL qui se chargera de stocker les données d'OpenStreetMap.

Il existe un paquet d'analyses permettant de définir des règles de conversion et de vérification pour chaque thématique. Des "Plugins", eux, vont se charger de vérifier la validité des données. Imaginons que nous souhaitons intégrer de l'open data concernant les bornes de recharge électrique à partir du fichier de DataGouv. Il existe une analyse de type Merger, qui permet de fusionner des données avec l'existant de deux façons:

proposer l'intégration de données nouvelles
corriger les attributs des données existantes

Exemple de ce que donne l'analyse des station de recharge électrique sur Tours dans Osmose-Frontend: https://osmose.openstreetmap.fr/fr/map/#loc=11/47.3998/0.7302&item=8410%2C8411%2C8412&level=1%2C2%2C3

Choisir une analyse à faire fonctionner

Osmose propose plus de 90 analyses différentes. Pour avoir la liste de leurs noms lancez cette commande:

sudo service docker start

cd osmose-backend/docker

cd docker
docker-compose --project-name essonne run --rm backend ./osmose_run.py --list-analyser

Vous verrez que plusieurs analyses ont des noms très similaires, ils diffèrent par leur zone géographique car on valide différemment des données selon leur production, qui se fait souvent par zones et par des gens dont l'informatique n'est (généralement) pas du tout le métier. C'est pourquoi concernant la catégorie défibrilateurs vous avez ceci:

merge_{defibrillatorsFR} merge_{defibrillatorsFRaedmap} merge_{defibrillatorsFRhautesalpes} merge_{defibrillatorsFRissylesmoulineaux} merge_{defibrillatorsFRlorient} merge_{defibrillatorsFRmontfort} merge_{defibrillatorsFRparis} merge_{defibrillatorsFRsaintmalo} merge_{defibrillatorsFRtoulouse}

Vous pouvez faire une analyse qui incluera toutes les validation des zones à la fois de cette thématique, ou plus précisément en ne demandant qu'une validation spécifique à une zone, mais pas forcément sur cette zone. Sauf que vous risquez de ne pas avoir de données à comparer.

Avant de vous lancer dans un long travail de contribution à un logiciel libre, je ne peux que vous conseiller de causer sur le forum OSM France pour savoir si ce n'est pas déjà prévu, trouver de la documentation à lire, des gens à qui causer en cas de problème, breffe, les besoins de base pour toute contribution. https://forum.openstreetmap.fr

https://www.cipherbliss.com/2025/contribuer-%c3%a0-un-projet-libre/

Avant d'aller vraiment modifier une analyse, on va faire tourner le projet sur son propre ordi et voir ce qui se passe dans une analayse simple.

Analyser une zone localement

Disons que l'on veut modifier le Merger `merge_{chargingstationFR}`, et que l'on veut voir ce que donne nos modifications en lançant une analyse. Pour éviter que cela prenne toute la journée, nous allons restreindre le champ d'analyse au patelin perdu de Monaco. Après une installation locale avec docker-compose du dépot osmose-backend, nous pouvons lancer cette commande qui va demander au point d'entrée principal de faire marcher l'analyse `merge_{chargingstationFR}` sur la zone `monaco`, sans supprimer les données en base si elles existent déjà:

# je vous passe l'installation de docker et docker-compose
git clone https://github.com/osm-fr/osmose-backend 
cd osmose-backend/docker
docker-compose --project-name monaco-irve run --rm backend ./osmose_run.py --country=monaco --no-clean --analyser=merge_charging_station_FR

Sur ma tour cela prend autour de 15 secondes.

Cela va créer un fichier xml dans le dossier "docker/work/results" listant les alertes détectées par notre analyseur. Ce sont ces alertes qui permettent d'afficher les punaises de couleur sur la carte du frontend. Elles contiennent les informations traduites dans plusieurs langues des problèmes rencontrés, les tags à ajouter ou enlever, etc…

Votre terminal vous listera le déroulement de l'analyse, la mise à jour ou non de la base de données sur la zone concernée, les passes de conversion et de vérification.

Exemple d'un Analyser

Voici l'analyse des stations de recharge électrique en France: https://github.com/osm-fr/osmose-backend/blob/dev/analysers/analyser_merge_charging_station_FR.py

Ce Merger va récupérer les données depuis datagouv, puis convertir les données selon un ensemble de règles en liste blanche. On définit la documentation qui apparaîtra dans le frontend, l'url du fichier open data, la façon dont on détermine les positions des objets, et la correspondance entre les définition des propriétés des objets et les tags OSM. Ces correspondances ont été choisies par la communauté avant d'atterir dans une analyse Osmose. Tous les champs du fichier opendata ne sont pas forcément utilisés, certains n'ont pas de tag, certains identifiants n'ont pas de sens en dehors des logiciels persos des producteurs, certains demanderaient de créer des objets séparés, certaines informations doivent être regroupées ou reformatées, certaines sont trop vagues pour être qualifiées correctement, bref c'est festival.

https://wiki.openstreetmap.org/wiki/France/data.gouv.fr/Bornes_de_Recharge_pour_V%C3%A9hicules_%C3%89lectriques#Tableau_de_correspondance

L'analyse de l'open data utilise d'ailleurs un csv qui fait suite à un retraitement des données initiales, mis à jour quotidiennement sur datagouv par JungleBus, et vous trouverez ici le détail de l'opération: https://github.com/Jungle-Bus/ref-EU-EVSE

La conversion que je fais de ce jeu de données dans Wololo est différente et ne regroupe pas les totems en stations.

Mais revenons à l'analyse.

Par exemple dans l'Analyser on a une ligne de mapping qui dit que l'on prend la valeur de "date_{miseenservice}" pour en faire un tag "start_date", c'est la conversion la plus simple:

"start_date": "date_mise_en_service",

Des fonctions lambda sont utilisées pour des conversions un peu plus complexes.

"bicycle": lambda fields: "yes" if fields["station_deux_roues"] == "true" else None,

On a aussi une conversion pour les items wikidata qui dépendent du nom de l'opérateur:

# au début de la classe Analyser
    WIKIDATA_MAP = {
        "ionity": "Q42717773",
        "bouygues": "Q3046208",
        "freshmile": "Q111209120",
        "lidl": "Q115764851",
        "Electra": "Q128592938",
        "TotalEnergies Charging Services": "Q154037",
        "Last Mile Solutions": "Q109733858",
        "Izivia": "Q86671322",
    }
# ......  et plus loin dans la définition des mappings, on utilise ce dictionnaire
           "wikimedia:network": lambda fields: self.WIKIDATA_MAP.get(fields["nom_enseigne"].lower(), None) if fields["nom_enseigne"] != "0" else None,

Ce genre de conversion simple suffit pour la plupart des jeux de données ouverts. Pour des exepples plus complexes vous trouverez des requêtes SQL spatiales dans d'autres analyses, comme par exemple pour les façons de qualifier les attaches des câbles télécom ou électriques sur les pylônes.

N'oubliez pas de faire des tests unitaires sur vos Analysers.

Si vous êtes prêts à passer à une zone plus grande, changez la valeur de "country". Les noms des countries sont un enchaînement de zones séparées par des soulignés.

docker-compose --project-name essonne run --rm backend ./osmose_run.py --country=france_ile_de_france_essonne --no-clean --analyser=merge_charging_station_FR

Pour bricoler vos analyses je ne peux que vous conseiller de lire la documentation dans le dossier "doc" du dépot osmose-backend. Le wiki d'OSM est un complément mais beaucoup moins exhaustif.

Bon amusement!