Des fonctionnalités cartographiques d’OpenStreetMap mises en œuvre par vision par ordinateur

 (blog.mozilla.ai)
3 points par GN⁺ 2025-03-24 | 2 commentaires | Partager sur WhatsApp
  • Mozilla.ai a publié OpenStreetMap AI Helper Blueprint, qui relie les données OpenStreetMap à des images satellites pour trouver des objets cartographiques, les faire vérifier par des humains, puis les contribuer à nouveau
  • Cette approche sépare la détection d’objets avec YOLOv11 et la segmentation avec SAM2, au lieu d’utiliser des LLM/VLM, afin de confier respectivement l’identification de la position et la génération des contours de polygones
  • L’exemple de cartographie de piscines montre un flux où les données d’entraînement sont créées avec le tag leisure=swimming_pool et des tuiles Mapbox, puis les résultats sont envoyés sur Hugging Face Hub
  • Lors de l’inférence, les tuiles autour du point d’intérêt sont fusionnées, puis comparées aux objets OpenStreetMap existants afin d’exclure les doublons candidats ; seuls les nouveaux candidats sont vérifiés par une personne
  • Un travail entièrement manuel permet de cartographier environ 2 à 3 piscines par minute, tandis que ce Blueprint en traite 10 à 15 même avec une UX non optimisée, soit environ 5 fois plus vite

Pourquoi utiliser les données OpenStreetMap pour la cartographie par IA

  • Mozilla.ai estime que, dans les communautés collaboratives ouvertes, l’IA peut réduire les tâches répétitives et lentes, et a publié le Blueprint OpenStreetMap AI Helper
  • L’objectif n’est pas que l’IA remplace les cartographes, mais de réduire le temps nécessaire pour trouver les cibles et dessiner les polygones, tout en gardant la validation humaine comme dernière étape
    • La tâche essentielle qui doit rester confiée aux humains est de vérifier que les données cartographiques générées correspondent bien à la réalité
  • OpenStreetMap est une carte ouverte modifiable dont les données — routes, sentiers, cafés, gares ferroviaires, etc. — sont créées et maintenues par une communauté de cartographes
  • OpenStreetMap est l’une des bases de données cartographiques ouvertes les plus complètes et, combinée à d’autres sources comme l’imagerie satellite, elle peut servir de données d’entraînement pour des modèles d’IA

Le choix de modèles légers de vision par ordinateur plutôt que de LLM

  • De nombreuses Map Features d’OpenStreetMap sont représentées sous forme de zones polygonales
  • Trouver des polygones et les dessiner manuellement prend beaucoup de temps, mais avec suffisamment de données, des modèles de vision par ordinateur peuvent être entraînés pour cette tâche
  • Le Blueprint utilise des modèles récents non LLM en deux étapes distinctes
    • Détection d’objets : YOLOv11 d’Ultralytics localise dans l’image les éléments cartographiques pertinents
    • Segmentation : SAM2 de Meta affine la forme exacte de l’objet détecté sous forme de contour
  • YOLOv11 et SAM2 sont légers, rapides et adaptés à une exécution locale
    • Les poids combinés des deux modèles font moins de 250 Mo
    • SmolVLM, cité comme point de comparaison, fait 4,5 Go

Le flux en 3 étapes du Blueprint

  • Étape 1 : créer un jeu de données de détection d’objets à partir d’OpenStreetMap

    • Les données OpenStreetMap sont récupérées, combinées à des images satellites, puis converties dans un format adapté à l’entraînement
    • Un Create Dataset Colab directement exécutable est fourni
    • Deux API sont utilisées pour collecter les données OpenStreetMap
      • Nominatim API : permet à l’utilisateur de choisir de manière flexible une zone d’intérêt
      • Overpass API : télécharge, dans la zone sélectionnée, les polygones correspondant à un tag donné
    • Dans l’exemple des piscines, Galicia est utilisée pour l’entraînement et Viana do Castelo pour la validation
    • Le tag cible est leisure=swimming_pool, et les objets ayant aussi location=indoor sont exclus
    • Après le téléchargement des polygones, un niveau de zoom est choisi, puis les tuiles contenant des polygones à ce niveau de zoom sont identifiées
    • Les tuiles sont téléchargées via la Static Tiles API de Mapbox
    • Les polygones en coordonnées latitude/longitude sont convertis en boîtes englobantes exprimées en coordonnées de pixels pour chaque tuile, puis enregistrés au format YOLO d’Ultralytics
    • Le jeu de données final est téléversé sur Hugging Face Hub ; le jeu de données d’exemple est mozilla-ai/osm-swimming-pools

  • Étape 2 : fine-tuning du modèle de détection d’objets

  • Étape 3 : contribuer à OpenStreetMap

    • L’inférence est exécutée sur plusieurs tuiles avec le modèle de détection d’objets fine-tuné
    • Un Run Inference Colab directement exécutable est fourni
    • Le détecteur de piscines d’exemple peut être essayé dans la HuggingFace Demo
    • Le processus d’inférence nécessite plusieurs interactions humaines
      • D’abord, un point d’intérêt est sélectionné sur la carte
      • Une boîte englobante est calculée autour du point sélectionné selon l’argument margin
      • Les objets d’intérêt existants sont téléchargés depuis OpenStreetMap
      • Toutes les tuiles sont téléchargées depuis Mapbox, fusionnées, puis transformées en image empilée
      • L’image empilée est ensuite redécoupée en tuiles qui se chevauchent
    • Le modèle de détection d’objets YOLOv11 est exécuté sur chaque tuile
    • Lorsqu’un objet d’intérêt, comme une piscine, est détecté, la boîte englobante est transmise à SAM2 afin d’obtenir un masque de segmentation
    • Les polygones prédits sont comparés aux polygones existants téléchargés depuis OpenStreetMap afin d’éviter les téléversements en double
    • Les candidats identifiés comme nouveaux objets sont affichés un par un, puis l’utilisateur les vérifie et les filtre manuellement
    • Les objets que l’utilisateur choisit de conserver sont téléversés dans OpenStreetMap sous la forme d’un unique changeset

Performances et implications pratiques

  • OpenStreetMap AI Helper Blueprint montre que l’IA peut renforcer les contributions cartographiques humaines tout en gardant la validation humaine au centre du processus
  • Un processus entièrement manuel permet de cartographier 2 à 3 piscines par minute
  • Avec le Blueprint, même sans UX optimisée, il est possible de cartographier 10 à 15 piscines dans le même laps de temps, soit environ 5 fois plus
  • Avec des données OpenStreetMap de qualité, des modèles comme YOLOv11 peuvent être entraînés pour effectuer de la détection d’objets
  • Il n’est pas nécessaire d’appliquer des LLM à tous les problèmes : pour la détection d’éléments cartographiques et la génération de polygones, une combinaison légère de vision par ordinateur peut être un choix plus direct
  • Pour entraîner des modèles sur d’autres éléments cartographiques ou contribuer au dépôt, il est possible d’utiliser OpenStreetMap AI Helper Blueprint
  • D’autres Blueprints publiés sont disponibles sur le Blueprints Hub

À lire aussi

2 commentaires

 
depth221 2025-03-24

Après vérification, il semble que Map Feature se traduise généralement par « objet cartographique ».
 
GN⁺ 2025-03-24
Avis sur Hacker News

  • Du point de vue de l’OpenStreetMap Foundation, il ne faut pas ajouter directement à la base de données des objets géographiques détectés par l’IA
    Les algorithmes ont des problèmes de faux positifs, et comme sur l’avant-dernière capture d’écran, ils peuvent cartographier des objets droits ou rectangulaires sous une forme tremblotante
    C’est un outil précieux pour repérer les objets géographiques manquants, mais il faut toujours une intervention humaine pour vérifier que les objets détectés ont bien été dessinés correctement
    Références : https://wiki.openstreetmap.org/wiki/Import/Guidelines et https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_...

    • L’application de démo et les exemples de code fournis incluent une étape imposant une vérification humaine des objets détectés
      Sans modifier le code source, il est impossible de faire un envoi automatique, et la documentation, les articles liés et les exemples de code insistent tous à plusieurs reprises sur cette validation humaine
      Je n’ai jamais envoyé d’objets automatiquement, et avant même d’entraîner la première version, j’ai moi-même édité et annoté manuellement des centaines d’exemples de piscines
      S’il y a des idées pour améliorer la procédure afin d’empêcher l’envoi automatique d’objets, je veux bien les entendre et les mettre en œuvre
      Certains réagiront peut-être en disant qu’il ne faut tout simplement pas publier l’outil, mais je pense qu’il existe une meilleure approche : discuter ouvertement tout en intégrant l’IA
    • Si les polygones tremblotants sur les captures d’écran ont cet aspect, c’est parce qu’il s’agit de polygones d’affichage dessinés à partir de masques pour être superposés à l’image ; les polygones réellement envoyés n’ont pas cette oscillation
      Il arrive bien que les polygones prédits soient tremblotants, et dans ce cas il est recommandé d’écarter ces résultats
      Malgré cela, cette démo n’a pas été rendue publique avant qu’une première version du modèle n’atteigne un niveau de qualité minimal
      Le code inclut aussi une logique de simplification de géométrie pour éviter que les nœuds des polygones prédits ne deviennent trop nombreux
    • Il serait bon d’ajouter des tags aux objets issus du machine learning
      Ce type d’outil est probablement déjà utilisé de manière semi-automatique, et cela pourrait aider à réduire le risque de contamination de l’ensemble de la base de données

  • La détection de piscines est intéressante, et la détection de panneaux solaires fait aussi partie de la liste des choses que j’aimerais essayer
    Une bonne partie des réactions négatives ici semble venir de l’idée qu’OSM peut continuer à se développer uniquement par cartographie manuelle
    Mais après 10 ans et 60 000 changesets à mon actif, je pense qu’on ne peut pas “résoudre” la cartographie à l’échelle mondiale uniquement avec l’enthousiasme des bénévoles, au point de rendre les données cartographiques massivement utiles
    Il nous faut un framework scalable pour l’import et la maintenance des données : un moyen d’annoter la qualité, la provenance, l’endroit où signaler les bugs de la source de données, ainsi que des directives pour les consommateurs
    Par exemple, si l’on veut interroger “des commerces de type X cartographiés par des humains au cours de l’année écoulée”, on peut dans une certaine mesure s’en sortir avec check date
    Mais il est difficile de savoir à quel point cet attribut est exact, ou si le mapper qui l’a vérifié n’a regardé qu’un seul aspect, comme le nom ou l’emplacement
    Il pourrait être préférable d’importer et de maintenir automatiquement chaque mois les horaires d’ouverture provenant de alltheplaces
    Du point de vue des consommateurs de données, il pourrait être préférable de pouvoir filtrer uniquement certaines sources de confiance, ou d’utiliser des données ayant des limites connues, comme des “points d’intérêt déduits par IA”, même si les polygones ne sont pas parfaits

  • Dès qu’on a fait l’expérience de la cartographie automatique, on devient extrêmement prudent
    J’ai traversé l’Amérique du Sud à moto, et sur OSM il y avait beaucoup d’éditions qui semblaient automatiques, surtout au Brésil ; dans certaines zones, c’était presque inutilisable
    Et pas seulement sur des routes de campagne, mais aussi dans des villes assez grandes

    • La cartographie à distance depuis un bureau peut toujours produire de mauvaises cartes
      En voyage, j’utilise généralement mapwithme et j’essaie de laisser des notes photo pour expliquer les problèmes
      J’ai tendance à prendre des photos de clôtures et d’aires de jeux pendant que d’autres prennent des photos de paysage
      C’était peut-être de la cartographie automatique, mais même ma propre cartographie à distance peut se révéler assez mauvaise une fois vérifiée sur place
    • Je me demande dans quelle région du Brésil c’était

  • J’ai travaillé dans ce domaine il y a quelques années, et il existe déjà énormément de modèles, jeux de données et outils
    https://github.com/satellite-image-deep-learning

    • Excellente collection de ressources
      Je bricolais avec QGIS, en m’inscrivant à plusieurs API d’images satellites publiques et privées pour récupérer des données et faire des essais
      L’agence spatiale de l’UE propose aussi beaucoup de bonnes sources de données en accès totalement ouvert, même sans compte utilisateur
      J’ai hâte de travailler avec cette nouvelle boîte à outils dédiée au machine learning

  • Google ne l’autoriserait sans doute pas, mais Mapbox semble l’autoriser pour des usages non commerciaux ou liés à OSM
    Cela n’est toutefois possible que lorsqu’on utilise des données satellite, et non les données vectorielles de Mapbox
    Les conditions d’utilisation indiquent que les clients ne doivent pas tracer, dériver ni extraire de contenu, de données ou d’informations à partir des livrables du service, mais qu’il existe une exception permettant de tracer des cartes Mapbox composées uniquement d’images satellite avec Studio ou un logiciel tiers afin de créer des jeux de données vectorielles dérivés, à condition que ce soit pour un usage non commercial ou pour OpenStreetMap
    On peut dire que Mapbox a été plutôt correct là-dessus

  • J’ai travaillé sur quelque chose de similaire il y a quelques mois
    mais pour des données géographiques à plus petite échelle : https://github.com/uav4geo/GeoDeep

    • Beau travail, j’aimerais bien parler d’idées de collaboration

  • Il ne faut pas cartographier ce qui apparaît sur les images satellite, mais ce qui correspond à la réalité du terrain
    Il ne faut absolument pas contribuer avec des hallucinations de l’IA

    • Dans OSM, le critère de traçage lui-même repose souvent sur les images satellite
      La qualité de ce traçage est parfois extrêmement irrégulière, et j’ai dû corriger à plusieurs reprises des littoraux bizarrement décalés avec des routes qui se retrouvaient au milieu de la mer
      Si cet outil est un tant soit peu cohérent, il pourrait être meilleur que le contributeur OSM moyen
      Cela dit, il vaudrait mieux commencer par segmenter les maisons, les routes et les plans d’eau, puis comparer avec les données actuelles pour repérer les incohérences et les mettre en évidence pour correction

  • Mozilla ne pourrait pas simplement se concentrer sur la création d’un bon navigateur ?

  • J’aimerais voir plus de détails sur le fine-tuning de SAM/2 pour détecter les piscines ou les champs de panneaux solaires
    Les deux seraient très utiles s’ils étaient cartographiés pour des projets de résilience communautaire, mais le fine-tuning de SAM2 était difficile à suivre
    Trouver et segmenter des installations solaires avec un modèle Yolov8 fonctionne plutôt bien, mais les contours sont tellement mauvais qu’il faut énormément de travail de nettoyage
    J’ai vu des résultats de SAM2 entraîné et cela paraissait bien meilleur
    Je ne les intégrerais pas à OSM à cause des problèmes de précision, mais cela reste tout à fait exploitable ailleurs

    • Ce projet n’inclut pas de fine-tuning de SAM2
      Les données de segmentation d’OSM ne sont pas d’une qualité suffisante pour entraîner correctement un modèle de segmentation
      Ici, on utilise un modèle YOLO pour la prédiction des boîtes englobantes
      Les boîtes englobantes d’OSM sont suffisantes pour cet usage, et chaque boîte est transmise à SAM2 comme prompt afin qu’il segmente l’intérieur
      J’ai aussi essayé de passer le point central de la boîte à SAM comme prompt, mais les résultats étaient moins bons

  • Une nouvelle release a été publiée après prise en compte de plusieurs retours, et tout le code d’upload direct vers OSM a été remplacé par une exportation au format OsmChange
    J’espère que c’est un pas dans la bonne direction, et la discussion va se poursuivre dans le fil dédié sur le forum OSM