Pour des raisons de license, il n’est pas envisagé, pour le moment, d’intégrer au RNB des modifications du parc bâti provenant d’OSM. Il est par contre tout à fait possible de diffuser les ID-RNB dans OSM. Pour ce faire, c’est la communauté OSM qui doit y ajouter les ID-RNB correspondant à chaque objet bâtiment.
Comment l’y aider ? En proposant un fichier de rapprochement OSM<>RNB, qui pourra être librement réutilisé. Pour chaque bâtiment rapproché, nous pourrions indiquer un intervalle de confiance, permettant à chaque utilisateur OSM de faire un choix éclairé lors de l’ajout d’un ID-RNB dans OSM.
Compte-rendu du hackathon de mai 2025 pendant lequel une petite équipe a défriché le sujet :
Objectif
Fournir des données utiles pour faciliter l’intégration éclairée des ID RNB dans OpenStreetMap.
Tâches réalisées et envisagées :
produire un jeu de données sur la commune test de Saint-Martin d’Hères proposant avec un ID RNB pour chaque bâtiment OSM, avec un taux de confiance extrêmement élevé.
Voici le fichier des bâtiments OSM avec les 3903 ID RNB rajoutés : smdh.josm.xml - Nextcloud Une comparaison très prudente a été réalisée : seuls les bâtiments avec un recouvrement du périmètre >60% sont concernés : cela permet minimiser les faux positifs. Il reste donc un gros travail d’intégration manuel des ID sur cette commune au delà de cette intégration initiale.
publier le code source de cette conflation GitHub - fab-geocommuns/RNB-OSM-hackathon: Hackathon pour rapprocher les ID-RNBs de OSM
documenter la conflation pour faciliter sa reproductibilité
Intégrer ces données dans OSM Groupe de modifications : 166528144 | OpenStreetMap
améliorer cette première conflation basée sur la comparaison des surfaces en prenant en compte le décalage des centroïdes (notamment pour les données dont le taux de confiance est >0,6 et <0,7)
réaliser la même conflation que sur la commune test sur la France entière
publier le jeu de données national sur data.gouv.fr (cf. descriptif ci-dessous) en réintégrant tous les résultats et en précisant le taux de confiance
produire un fichier XML directement ouvrable dans JOSM pour chacune des 34 935 communes de France ne contenant que les données pour un taux de confiance >70%
publier ces fichiers sur https://rnb.openstreetmap.fr
automatiser la production de ces fichiers pour minimiser le risque de conflit d’édition
au-delà de ces cas identifiés comme ayant un taux de confiance très élevé, produire de la documentation / tutoriel pour permettre à la communauté OSM une intégration éclairée des ID RNB pour les autres cas plus complexes / corriger/améliorer les bâtiments dans OSM
créer un éditeur simplifié (type Pifomètre) pour simplifier encore l’intégration des ID RNB dans OSM
Descriptif du jeu de données à publier sur data.gouv.fr
Titre : Identifiants RnB recommandés à l’intégration dans OpenStreetMap
Description :
Ce jeu de données propose pour chacun des bâtiments OpenStreetMap un ou plusieurs identifiant du Référentiel National du Bâtiment (ID-RNB) (voir https://rnb.beta.gouv.fr) sur le territoire de la France.
Ce jeu de données a été produit durant le hackathon de la Fabrique des géocommuns le 19 et 20 mai 2025 à l’IGN. Par soucis de simplification, il ne contient que les données dont le taux de confiance est >70%.
Discussion concernant le projet sur le forum des géocommuns : Hackathon : Sujet RNB & OSM (n’hésitez pas à continuer la discussion).
Exploitation des données
osm_id : identifiant OpenStreetMap (documentation wiki).
Il peut s’appliquer à une way ou une relation.
Par exemple, le bâtiment identifié sous 11EB66VJ7FRH dans le RNB correspond à l’identifiant OSM way/159880167. Pour le retrouver dans OpenStreetMap, il faut se rendre à l’adresse Chemin : 159880167 | OpenStreetMap
Par exemple, le bâtiment identifié sous 28BJ8ER13CX1 dans le RNB correspond à l’identifiant OSM relation/2142218. Pour le retrouver dans OpenStreetMap, il faut se rendre à l’adresse Relation : Résidence les Taillées (2142218) | OpenStreetMap Cet identifiant est unique : il existe une ligne par objet. Il ne doit pas être considéré comme stable dans le temps.
rnb_ids : identifiant(s) RNB suggéré(s) à l’intégration dans OpenStreetMap. Il est possible de disposer de valeurs multiples, séparées par des ; pour un seul bâtiment OSM. L’identifiant RnB est pérenne pour chaque bâtiment. N.B. : si un bâtiment est détruit et un nouveau est reconstruit au même emplacement, alors un nouvel ID est créé ; l’ancien ID continue d’exister mais prend le statut “détruit”. Cette information ne fait pas partie du présent jeu de données : elle est à retrouver dans les données du RNB.
confidence : taux de confiance. Valeur comprise entre 0 et 1 avec deux décimales. 0 est la valeur minimale (confiance nulle) et 1 la valeur maximale (confiance totale).
C’est le résultat d’une analyse comparative : ce taux représente le pourcentage de recouvrement des surfaces des bâtiments entre le référentiel du RNB et OSM. Le détail de ce calcul est publié à l’adresse GitHub - fab-geocommuns/RNB-OSM-hackathon: Hackathon pour rapprocher les ID-RNBs de OSM Par exemple, un taux de confiance de 0,9 est très élevé : il y a de fortes chance que le le bâtiment identifié dans OpenStreetMap soit bien celui identifié par la valeur RNB indiquée.
diff : précision de différence de modélisation entre les données RNB et OSM.
Prend la valeur splited si un objet RNB correspond à plusieurs objets OSM, prend la valeur multiple si plusieurs objets RNB correspondent à un seul objet OSM.
Par exemple, les deux bâtiments identifiés sous les références S3HFGTCH14VF;C5NW96R48RQE dans le RNB correspond à l’identifiant OSM way/190591890. Le diff prend la valeur multiple (dans OpenStreetMap, la tag associé est diff:ref:FR:RNB=multiple).
Pour le retrouver dans OpenStreetMap, il faut se rendre à l’adresse Chemin : 190591890 | OpenStreetMap
Hello,
Lors de l’envoi des données sur la seule commune de Saint-Martin-dHères, on a eu 22 conflits dans OSM : ce sont toutes les modifications qui ont été réalisées entre hier matin et hier fin d’après midi dans OSM sur les bâtiments de cette commune qui posent problème lors de l’envoi des données.
Il a fallu résoudre manuellement ces conflits avant envoi, ce qui rajoute du temps, de la complexité et des risques d’erreurs.
Pour palier à ce problème qui sera, à n’en pas douter, récurrent dans le futur, on pourrait générer les fichiers pour chaque commune à la volée, sur demande de l’utilisateur, sans les produire tous par avance.
Cela prendrait certes quelques instants, et cela nécessite également de développer un outil spécifique, mais je pense que c’est la seule manière de régler ce soucis majeur.
export-cadastre ne me semble pas être une bonne une base à forker:
c’est très vieux (12 ans)
les commit récents avaient surtout pour but d’indiquer que c’était un outil “historique”
le besoin à l’époque était de simplifier l’extraction de géométries depuis les plan du cadastre (en PDF)… depuis les données du cadastre sont dispo en opendata
Quel est le temps pour générer un rapprochement sur une commune “moyenne” et une grosse ?
Je vois dans le repo github ceci:
import OSM dans une base osm2pgsql
croisement avec RNB fait dans postgres sur les intersections de polygones
Une base osm2pgsql peut être maintenue à jour en quasi temps réel (avec les diff minute), cela minimise les conflits d’édition dans OSM.
Si le croisement RNB est rapide pour une commune (et en principe ça devrait être le cas), il pourrait se faire à la demande.
Les exports sur data.gouv semblent quotidiens pour le fichier national.
On peut faire un petit test avec une approche un peu différente:
overpass pour récupérer les données sur une commune
croisement avec calcul d’IoU (intersection over union)
génération du XML OSM
Tout cela doit pouvoir se faire en python, sans postgres (avec shapely), ce qui serait encore plus léger.
J’ai gardé Postgres pour récupérer directement la logique existante et éviter le portage de cette partie, mais je me suis effectivement basé sur Overpass pour récupérer les données OSM et générer l’XML initial avant de le modifier.
J’ai l’impression que la logique est cependant un peu boguée (splitted pas vraiment splitted notamment), il faudrait investiguer pourquoi cette différence qui ne me semblait pas là au hackathon ? Soit j’avais commit une ancienne version de la requête, soit c’est dans l’adaptation et peut-être la logique de transformation d’objets OSM en polygones que j’ai refaite un peu hâtivement.
Pour des raisons de license, il n’est pas envisagé, pour le moment, d’intégrer au RNB des modifications du parc bâti provenant d’OSM. Il est par contre tout à fait possible de diffuser les ID-RNB dans OSM. Pour ce faire, c’est la communauté OSM qui doit y ajouter les ID-RNB correspondant à chaque objet bâtiment.