Funciones de mapas de OpenStreetMap implementadas con visión por computadora

 (blog.mozilla.ai)
3 puntos por GN⁺ 2025-03-24 | 2 comentarios | Compartir por WhatsApp
  • Mozilla.ai presentó el OpenStreetMap AI Helper Blueprint, que conecta datos de OpenStreetMap con imágenes satelitales para encontrar objetos del mapa, hacer que una persona los verifique y luego volver a contribuirlos
  • En lugar de usar LLM/VLM, este enfoque separa la detección de objetos con YOLOv11 y la segmentación con SAM2, asignando a cada uno la identificación de ubicación y la generación del contorno poligonal, respectivamente
  • El ejemplo de mapeo de piscinas muestra un flujo en el que se crean datos de entrenamiento con la etiqueta leisure=swimming_pool y tiles de Mapbox, y luego los resultados se suben a Hugging Face Hub
  • En el proceso de inferencia, se combinan los tiles alrededor del punto de interés, luego se comparan con los objetos existentes de OpenStreetMap para excluir candidatos duplicados, y solo los nuevos son revisados por una persona
  • El trabajo completamente manual permite mapear unas 2 a 3 piscinas por minuto, pero este Blueprint llega a procesar de 10 a 15 incluso con una UX no optimizada, por lo que es cerca de 5 veces más rápido

Por qué usar datos de OpenStreetMap para mapeo con AI

  • Mozilla.ai publicó el Blueprint OpenStreetMap AI Helper al considerar que, en una comunidad abierta y colaborativa, la AI puede reducir tareas repetitivas y lentas
  • El objetivo no es reemplazar a quienes hacen mapas con AI, sino reducir el tiempo que toma encontrar objetivos y dibujar polígonos, manteniendo la verificación humana como paso final
    • La tarea clave que debe seguir en manos humanas es verificar si los datos de mapa generados realmente son correctos
  • OpenStreetMap es un mapa abierto y editable cuyos datos —como carreteras, senderos, cafés y estaciones de tren— son creados y mantenidos por la comunidad de mapeadores
  • OpenStreetMap es una de las bases de datos de mapas abiertos más completas y, al combinarse con otras fuentes como imágenes satelitales, puede usarse como datos de entrenamiento para modelos de AI

Se eligen modelos ligeros de visión por computadora en lugar de LLM

  • Muchas de las Map Features de OpenStreetMap se representan como áreas con forma de polígono
  • Encontrar polígonos y dibujarlos manualmente lleva mucho tiempo, pero si hay suficientes datos, se pueden entrenar modelos de visión por computadora para esta tarea
  • El Blueprint usa modelos modernos no basados en LLM en dos etapas
    • Detección de objetos: YOLOv11 de Ultralytics encuentra la ubicación de las funciones cartográficas relevantes en la imagen
    • Segmentación: SAM2 de Meta refina la forma exacta del objeto detectado como un contorno
  • YOLOv11 y SAM2 son ligeros, rápidos y adecuados para correr de forma local
    • Los pesos combinados de ambos modelos son de menos de 250MB
    • Como comparación, SmolVLM, mencionado como referencia, pesa 4.5GB

Flujo de 3 etapas del Blueprint

  • Etapa 1: crear un dataset de detección de objetos a partir de OpenStreetMap

    • Se obtienen datos de OpenStreetMap, se combinan con imágenes satelitales y se convierten a un formato adecuado para entrenamiento
    • Se ofrece un Create Dataset Colab que puede ejecutarse directamente
    • Para recolectar datos de OpenStreetMap se usan dos APIs
      • Nominatim API: permite que la persona usuaria elija con flexibilidad un área de interés
      • Overpass API: descarga los polígonos que corresponden a ciertas etiquetas dentro del área seleccionada
    • En el ejemplo de piscinas, se usa Galicia para entrenamiento y Viana do Castelo para validación
    • La etiqueta objetivo es leisure=swimming_pool, y se excluyen los objetivos que también tienen location=indoor
    • Después de descargar los polígonos, se elige un zoom level y se identifican los tiles que contienen polígonos en ese nivel de zoom
    • Los tiles se descargan con la Static Tiles API de Mapbox
    • Los polígonos en coordenadas de latitud y longitud se convierten en cajas delimitadoras en coordenadas de píxeles relativas a cada tile y se guardan en formato Ultralytics YOLO
    • El dataset final se sube a Hugging Face Hub; el dataset de ejemplo es mozilla-ai/osm-swimming-pools

  • Etapa 2: fine-tuning del modelo de detección de objetos

  • Etapa 3: contribuir a OpenStreetMap

    • Se ejecuta inferencia sobre varios tiles con el modelo de detección de objetos ajustado
    • Se ofrece un Run Inference Colab que puede ejecutarse directamente
    • El detector de piscinas de ejemplo puede probarse en el HuggingFace Demo
    • El proceso de inferencia requiere cierta interacción humana
      • Primero se selecciona un punto de interés en el mapa
      • Luego se calcula una caja delimitadora alrededor del punto seleccionado según el argumento margin
      • Se descargan de OpenStreetMap los objetos de interés ya existentes
      • Se descargan todos los tiles desde Mapbox, se combinan y se convierten en una imagen apilada
      • La imagen apilada luego se vuelve a dividir en tiles superpuestos
    • En cada tile se ejecuta el modelo de detección de objetos YOLOv11
    • Si se detecta un objeto de interés, como una piscina, la caja delimitadora se pasa a SAM2 para obtener una máscara de segmentación
    • Los polígonos predichos se comparan con los polígonos existentes descargados de OpenStreetMap para evitar subidas duplicadas
    • Los candidatos identificados como objetos nuevos se muestran uno por uno, y la persona usuaria los verifica y filtra manualmente
    • Los objetos que la persona decide conservar se suben a OpenStreetMap como un solo changeset

Rendimiento e implicaciones prácticas

  • El OpenStreetMap AI Helper Blueprint muestra que la AI puede potenciar las contribuciones humanas a los mapas y, al mismo tiempo, mantener la verificación humana en el centro
  • En un proceso totalmente manual, se pueden mapear de 2 a 3 piscinas por minuto
  • Con el Blueprint, incluso con una UX no optimizada, se pueden mapear de 10 a 15 piscinas en el mismo tiempo, cerca de 5 veces más
  • Si se cuenta con datos de alta calidad de OpenStreetMap, se pueden entrenar modelos como YOLOv11 para realizar detección de objetos
  • No es necesario aplicar LLM a todos los problemas, y para detectar funciones cartográficas y generar polígonos puede ser una opción más directa una combinación ligera de visión por computadora
  • Si quieres entrenar modelos para otras funciones del mapa o contribuir al repositorio, puedes usar el OpenStreetMap AI Helper Blueprint
  • Otros Blueprints publicados pueden consultarse en Blueprints Hub

Lecturas relacionadas

2 comentarios

 
depth221 2025-03-24

Por lo que vi, Map Feature normalmente se traduce como elemento geográfico (del mapa).
 
GN⁺ 2025-03-24
Opiniones en Hacker News

  • Desde la perspectiva de la OpenStreetMap Foundation, los elementos detectados por IA no deberían agregarse directamente a la base de datos.
    Los algoritmos tienen problemas de falsos positivos y, como en la penúltima captura de pantalla, pueden mapear objetos rectos o rectangulares con formas temblorosas.
    Son valiosos como herramienta de apoyo para encontrar elementos faltantes, pero sigue siendo necesaria la intervención humana para verificar que los objetos detectados estén dibujados correctamente.
    Referencia: https://wiki.openstreetmap.org/wiki/Import/Guidelines y https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_...

    • La app de demostración y los ejemplos de código provistos incluyen un paso que exige que una persona valide los elementos detectados.
      No se puede hacer una carga automática sin modificar el código fuente, y en toda la documentación, los artículos enlazados y los ejemplos de código se enfatizó repetidamente la validación humana.
      Nunca se han subido elementos automáticamente; incluso antes de entrenar la primera versión, se editaron y etiquetaron manualmente cientos de muestras de piscinas.
      Si hay ideas para mejorar el proceso y evitar cargas automáticas de elementos, me gustaría escucharlas e implementarlas.
      Puede que algunos reaccionen diciendo que no debería publicarse la herramienta en absoluto, pero creo que es posible una mejor forma de adoptar la IA y debatirla abiertamente.
    • Los polígonos temblorosos de la captura se ven así porque son polígonos de visualización dibujados como máscaras para superponerlos sobre la imagen; los polígonos que realmente se suben no tienen ese temblor.
      En la práctica sí hay casos en que los polígonos predichos salen temblorosos, por lo que se recomienda descartar esos resultados.
      Aun así, no publiqué esta demo hasta tener una primera versión del modelo que alcanzara una calidad mínima.
      El código también incluye lógica de simplificación de formas para evitar que los polígonos predichos tengan demasiados nodos.
    • Sería bueno agregar etiquetas a los elementos derivados de machine learning.
      Es muy probable que estas herramientas ya se estén usando de forma semiautomática, y eso podría ayudar a reducir el riesgo de contaminar la base de datos completa.

  • La detección de piscinas está buena, y la detección de paneles solares también está en mi lista de cosas que me gustaría probar.
    Siento que buena parte de la resistencia aquí viene de la premisa de que OSM puede crecer solo con mapeo manual.
    Pero, como alguien que creó 60 mil conjuntos de cambios en 10 años, solo con el entusiasmo de voluntarios no se puede “resolver” el mapeo a una escala que haga que los datos del mapa sean abrumadoramente útiles a nivel mundial.
    Necesitamos un marco escalable para importar y mantener datos: formas de dejar anotaciones sobre calidad, procedencia y dónde reportar bugs de la fuente de datos, además de guías para los consumidores.
    Por ejemplo, si uno quisiera consultar “negocios de tipo X mapeados por una persona en el último año”, con check date se puede hacer hasta cierto punto.
    Pero es difícil saber qué tan exacto es ese atributo, o si el mapeador que lo verificó solo revisó un aspecto, como el nombre o la ubicación.
    Tal vez sería mejor importar y mantener automáticamente cada mes los datos de horarios de atención de alltheplaces.
    Desde el punto de vista de los consumidores de datos, podría ser mejor poder filtrar solo ciertas fuentes en las que confían, o usar datos con limitaciones conocidas, como “puntos de interés inferidos por IA”, aunque los polígonos no sean perfectos.

  • Cuando uno experimenta directamente el mapeo automático, se vuelve extremadamente cauteloso.
    Crucé Sudamérica en moto, y en OSM había muchas ediciones que parecían automáticas, especialmente en Brasil; en algunas zonas era casi inutilizable.
    No solo pasaba en caminos rurales, sino también en ciudades bastante grandes.

    • El mapeo remoto desde el escritorio siempre puede producir malos mapas.
      Cuando viajo normalmente uso mapwithme e intento dejar notas con fotos que expliquen los problemas.
      Yo suelo tomar fotos de cercas y parques infantiles, mientras otros toman fotos de paisajes.
      Podría ser mapeo automático, pero mi propio mapeo remoto también resulta bastante desastroso cuando lo verifico en campo.
    • Me da curiosidad saber en qué región de Brasil fue.

  • Hace unos años trabajé en este campo, y hay una enorme cantidad de modelos, datasets y herramientas existentes.
    https://github.com/satellite-image-deep-learning

    • Es una excelente recopilación de recursos.
      Estuve trasteando con QGIS, registrándome en varias API públicas y privadas de imágenes satelitales para traer datos y experimentar.
      La agencia espacial de la UE tiene muchas buenas fuentes de datos con acceso completamente público incluso sin una cuenta de usuario.
      Tengo ganas de probar este nuevo conjunto de herramientas dedicado a machine learning.

  • Google probablemente no lo permita, pero Mapbox parece permitirlo si es para fines no comerciales o para OSM.
    Eso sí, solo es posible cuando se usan datos satelitales, no los datos vectoriales de Mapbox.
    Los términos dicen que los clientes no deben rastrear, derivar ni extraer contenido, datos o información de las prestaciones del servicio, pero hay una excepción que permite rastrear Mapbox Maps compuestos únicamente por imágenes satelitales con Studio o software de terceros para crear conjuntos de datos vectoriales derivados, siempre que el propósito sea no comercial o OpenStreetMap.
    Se podría decir que Mapbox se portó bastante bien.

  • Hace unos meses trabajé en algo parecido.
    Es para datos geográficos de menor escala, pero: https://github.com/uav4geo/GeoDeep

    • Es un gran trabajo, y me gustaría conversar sobre ideas de colaboración.

  • No hay que mapear lo que se ve en las imágenes satelitales, sino lo que existe como hecho en el terreno.
    Nunca se debería contribuir algo que la IA haya alucinado.

    • En OSM, muchas veces el criterio mismo para trazar son las imágenes satelitales.
      La calidad de ese trazado a veces varía muchísimo, y varias veces tuve que corregir costas extrañamente desalineadas que dejaban carreteras sobre el mar.
      Si esta herramienta es consistente en cierta medida, podría ser mejor que el colaborador promedio de OSM.
      Dicho eso, sería bueno empezar segmentando casas, caminos y cuerpos de agua, compararlos con los datos actuales y resaltar las discrepancias para corregirlas.

  • ¿Mozilla no podría concentrarse en hacer un buen navegador?

  • Me gustaría ver más detalles sobre cómo ajustar finamente SAM/2 para detectar piscinas o arreglos solares.
    Ambos serían muy útiles si estuvieran mapeados para proyectos de resiliencia comunitaria, pero el ajuste fino de SAM2 fue difícil de seguir.
    Encontrar y segmentar paneles solares con modelos Yolov8 funciona bastante bien, pero los bordes quedan tan desordenados que requieren muchísimo trabajo de limpieza.
    Vi resultados de SAM2 entrenado y se veían mucho mejor.
    No los pondría en OSM por problemas de precisión, pero en otros lugares serían perfectamente útiles.

    • Este proyecto no incluye ajuste fino de SAM2.
      Los datos de segmentación de OSM no tienen la calidad suficiente para entrenar correctamente un modelo de segmentación.
      Aquí usamos un modelo YOLO para predecir cajas delimitadoras.
      Las cajas delimitadoras de OSM son suficientes para este propósito, y cada caja delimitadora se pasa a SAM2 como prompt para que segmente el interior.
      También probamos pasar el punto central de la caja como prompt a SAM, pero los resultados fueron peores.

  • Publicamos una nueva versión incorporando varios comentarios, y reemplazamos todo el código que subía directamente a OSM por exportación en formato OsmChange.
    Espero que sea un paso en la dirección correcta, y seguiremos discutiéndolo en el hilo dedicado del foro de OSM.