- A Mozilla.ai revelou o OpenStreetMap AI Helper Blueprint, que conecta dados do OpenStreetMap e imagens de satélite para encontrar objetos no mapa, fazer a validação humana e depois contribuir de volta
- Em vez de usar LLM/VLM, essa abordagem separa a detecção de objetos com YOLOv11 e a segmentação com SAM2, atribuindo a cada uma a identificação de localização e a geração do contorno poligonal
- O exemplo de mapeamento de piscinas mostra o fluxo de criar dados de treinamento com a tag
leisure=swimming_poole tiles do Mapbox, e publicar os resultados no Hugging Face Hub - No processo de inferência, os tiles ao redor do ponto de interesse são combinados, comparados com os objetos já existentes no OpenStreetMap, e os candidatos duplicados são excluídos para que só os novos sejam verificados por humanos
- O trabalho totalmente manual fica em torno de 2 a 3 piscinas por minuto, mas esse Blueprint, mesmo com UX ainda não otimizada, processa de 10 a 15, sendo cerca de 5x mais rápido
Por que usar dados do OpenStreetMap em mapeamento com AI
- A Mozilla.ai publicou o Blueprint OpenStreetMap AI Helper por entender que, em comunidades abertas e colaborativas, a AI pode reduzir trabalhos repetitivos e lentos
- O objetivo não é substituir quem faz o mapeamento, mas reduzir o tempo gasto para encontrar alvos e desenhar polígonos, mantendo a validação humana como etapa final
- A tarefa central que deve continuar com pessoas é confirmar se os dados de mapa gerados correspondem de fato à realidade
- O OpenStreetMap é um mapa aberto e editável em que a comunidade de mapeadores cria e mantém dados como estradas, trilhas, cafés e estações ferroviárias
- O OpenStreetMap é um dos bancos de dados de mapas abertos mais completos e, quando combinado com outras fontes como imagens de satélite, pode ser usado como dado de treinamento para modelos de AI
Escolha de modelos leves de visão computacional em vez de LLM
- Muitas Map Features do OpenStreetMap são representadas como áreas em forma de polígono
- Encontrar esses polígonos e desenhá-los manualmente consome muito tempo, mas, com dados suficientes, é possível treinar modelos de visão computacional para essa tarefa
- O Blueprint usa modelos modernos não baseados em LLM em duas etapas
- YOLOv11 e SAM2 são leves, rápidos e adequados para execução local
- Os pesos combinados dos dois modelos ficam abaixo de 250MB
- Como comparação, o SmolVLM citado tem 4.5GB
Fluxo de 3 etapas do Blueprint
-
Etapa 1: criar um dataset de detecção de objetos a partir do OpenStreetMap
- Os dados do OpenStreetMap são importados, combinados com imagens de satélite e convertidos para um formato adequado ao treinamento
- Há um Create Dataset Colab pronto para execução
- Duas APIs são usadas para coletar os dados do OpenStreetMap
- Nominatim API: permite ao usuário selecionar com flexibilidade a área de interesse
- Overpass API: baixa os polígonos correspondentes a tags específicas dentro da área selecionada
- No exemplo de piscinas, Galicia é usada para treinamento e Viana do Castelo para validação
- A tag-alvo é leisure=swimming_pool, e os alvos que também têm location=indoor são excluídos
- Depois de baixar os polígonos, escolhe-se um zoom level e identificam-se os tiles que contêm esses polígonos nesse nível de zoom
- Os tiles são baixados pela Static Tiles API do Mapbox
- Os polígonos em coordenadas de latitude e longitude são convertidos em bounding boxes em coordenadas de pixel relativas a cada tile e salvos no Ultralytics YOLO format
- O dataset final é enviado ao Hugging Face Hub, e o dataset de exemplo é o mozilla-ai/osm-swimming-pools
-
Etapa 2: fine-tuning do modelo de detecção de objetos
- Quando o formato do dataset está pronto, é possível fazer fine-tuning do YOLOv11 ou de outros modelos compatíveis com a Ultralytics
- Há um Finetune Model Colab pronto para execução
- Os hiperparâmetros disponíveis podem ser consultados na documentação de configuração de treinamento da Ultralytics
- O modelo treinado também é enviado ao Hugging Face Hub
- O modelo de exemplo é o mozilla-ai/swimming-pool-detector
-
Etapa 3: contribuir para o OpenStreetMap
- A inferência é executada em vários tiles com o modelo de detecção de objetos ajustado
- Há um Run Inference Colab pronto para execução
- O detector de piscinas de exemplo pode ser testado na HuggingFace Demo
- O processo de inferência exige alguma interação humana
- Primeiro, seleciona-se um ponto de interesse no mapa
- Em torno do ponto selecionado, uma bounding box é calculada de acordo com o argumento
margin - Os objetos de interesse já existentes são baixados do OpenStreetMap
- Todos os tiles são baixados do Mapbox, combinados e transformados em uma imagem empilhada
- A imagem empilhada é dividida novamente em tiles sobrepostos
- Em cada tile, o modelo de detecção de objetos YOLOv11 é executado
- Quando um objeto de interesse como uma piscina é detectado, a bounding box é passada para o SAM2 para obter uma máscara de segmentação
- Os polígonos previstos são comparados com os polígonos já baixados do OpenStreetMap para evitar uploads duplicados
- Os candidatos identificados como novos objetos são exibidos um a um, e o usuário faz a validação e filtragem manualmente
- Os objetos que o usuário decide manter são enviados ao OpenStreetMap em um único changeset
Desempenho e implicações práticas
- O OpenStreetMap AI Helper Blueprint mostra que a AI pode reforçar a contribuição humana em mapas, mantendo a validação humana no centro do processo
- Em um processo totalmente manual, é possível mapear de 2 a 3 piscinas por minuto
- Com o Blueprint, mesmo com a UX ainda não otimizada, é possível mapear de 10 a 15 piscinas no mesmo tempo, cerca de 5x mais
- Com dados de alta qualidade do OpenStreetMap, é possível treinar modelos como o YOLOv11 para realizar detecção de objetos
- Nem todo problema precisa de LLM, e para detectar funcionalidades de mapa e gerar polígonos, uma combinação leve de visão computacional pode ser uma escolha mais direta
- Se quiser treinar modelos para outras funcionalidades de mapa ou contribuir com o repositório, é possível usar o OpenStreetMap AI Helper Blueprint
- Outros Blueprints públicos podem ser vistos no Blueprints Hub
2 comentários
Pelo que pesquisei, parece que
Map Featurenormalmente é traduzido como elemento cartográfico.Opiniões no Hacker News
Do ponto de vista da OpenStreetMap Foundation, elementos detectados por IA não devem ser adicionados diretamente ao banco de dados.
Algoritmos têm problemas de falsos positivos e, como no penúltimo screenshot, também há o problema de mapear objetos retos e retangulares em formas tremidas.
Eles são valiosos como ferramenta auxiliar para encontrar elementos ausentes, mas ainda é necessária intervenção humana para verificar se os objetos detectados foram desenhados corretamente.
Referência: https://wiki.openstreetmap.org/wiki/Import/Guidelines e https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_...
Sem modificar o código-fonte, não é possível fazer upload automático, e a validação humana foi enfatizada repetidamente em toda a documentação, no artigo vinculado e nos exemplos de código.
Nunca fiz upload automático de elementos e, mesmo antes de treinar a primeira versão, editei e rotulei manualmente centenas de amostras de piscinas.
Se houver ideias para melhorar o processo a fim de impedir uploads automáticos de elementos, gostaria de ouvi-las e implementá-las.
Pode haver quem reaja dizendo para não publicar a ferramenta de jeito nenhum, mas acredito que seja possível uma forma melhor de aceitar a IA e discuti-la abertamente.
De fato, há casos em que os polígonos previstos saem tremidos, então a recomendação é descartar esses resultados.
Mesmo assim, não publiquei esta demonstração até sair uma primeira versão do modelo que atingisse uma qualidade mínima.
O código também inclui lógica de simplificação de formas para evitar que os polígonos previstos tenham nós demais.
É muito provável que ferramentas assim já estejam sendo usadas de forma semiautomática, e isso poderia ajudar a reduzir o risco de contaminar o banco de dados inteiro.
A detecção de piscinas é boa, e detecção de painéis solares também está na minha lista de coisas que quero tentar.
Sinto que boa parte da resistência aqui vem da premissa de que o OSM pode crescer apenas com mapeamento manual.
Mas, como alguém que criou 60 mil changesets em 10 anos, não dá para “resolver” o mapeamento só com entusiasmo voluntário até o ponto de tornar os dados cartográficos esmagadoramente úteis em escala global.
Precisamos de um framework escalável para importação e manutenção de dados: formas de deixar anotados qualidade, origem e onde relatar bugs da fonte de dados, além de orientações para consumidores.
Por exemplo, se eu quiser consultar “estabelecimentos do tipo X mapeados por uma pessoa no último ano”, isso é possível até certo ponto com
check date.Mas é difícil saber quão preciso esse atributo é, ou se o mapeador que verificou olhou apenas um aspecto, como o nome ou a localização.
Talvez seja melhor importar e manter automaticamente todos os meses os dados de horário de funcionamento do alltheplaces.
Do ponto de vista de consumidores dos dados, poderia ser melhor poder filtrar apenas fontes específicas em que confiam, ou usar dados com limitações conhecidas, como “pontos de interesse inferidos por IA”, mesmo que os polígonos não sejam perfeitos.
https://community.openstreetmap.org/t/what-you-think-about-i...
https://www.openstreetmap.org/user/Mateusz%20Konieczny%20-%2...
https://codeberg.org/matkoniecz/list_how_openstreetmap_can_b...
No estado atual, pode servir de inspiração, mas não é compatível com o OpenStreetMap.
É ambíguo como diferenciar painéis fotovoltaicos de coletores solares térmicos.
Por fora eles parecem quase iguais, mas suas funções são muito diferentes.
Quando você vivencia mapeamento automático na prática, acaba ficando extremamente cauteloso.
Atravessei a América do Sul de moto, e havia muitas edições que pareciam automáticas no OSM, especialmente no Brasil; em algumas regiões, o mapa era quase difícil de usar.
Não era só em estradas rurais, mas também em cidades bem grandes.
Quando viajo, costumo usar o mapwithme e tento deixar notas com fotos explicando os problemas.
Eu costumo tirar fotos de cercas e parquinhos, enquanto outras pessoas tiram fotos de paisagens.
Pode ser mapeamento automático, mas até meu próprio mapeamento remoto às vezes fica bem bagunçado quando vou conferir em campo.
Trabalhei nessa área alguns anos atrás, e já existe uma quantidade enorme de modelos, datasets e ferramentas.
https://github.com/satellite-image-deep-learning
Eu estava mexendo no QGIS, me cadastrando em várias APIs públicas e privadas de imagens de satélite, trazendo dados e experimentando.
A agência espacial da UE tem muitas boas fontes de dados com acesso totalmente público, mesmo sem conta de usuário.
Estou animado para trabalhar com este novo conjunto de ferramentas dedicado a aprendizado de máquina.
O Google provavelmente não permitiria, mas a Mapbox parece permitir se for para fins não comerciais ou para uso no OSM
Porém, isso só é possível ao usar dados de satélite, não os dados vetoriais da Mapbox
Os termos dizem que o cliente não pode rastrear nem derivar/extrair conteúdo, dados ou informações das ofertas do serviço, mas há uma exceção dizendo que é possível rastrear Mapbox Maps compostos apenas por imagens de satélite, usando o Studio ou software de terceiros, para criar um conjunto de dados vetorial derivado, desde que a finalidade seja não comercial ou o OpenStreetMap
No fim, a Mapbox foi bem razoável
https://wiki.openstreetmap.org/wiki/Bing_Maps#Aerial_imagery
Trabalhei em algo parecido alguns meses atrás
Embora seja para dados geográficos em escala menor: https://github.com/uav4geo/GeoDeep
Não se deve mapear o que aparece em imagens de satélite, mas sim o que existe como fato em campo
O que a IA alucinar jamais deve ser contribuído
A qualidade desse traçado às vezes varia muito, e já tive de corrigir várias vezes litorais estranhamente desalinhados que colocavam estradas sobre o mar
Se esta ferramenta for minimamente consistente, talvez seja melhor do que o colaborador médio do OSM
Ainda assim, seria bom começar segmentando casas, estradas e corpos d'água, comparando com os dados atuais e destacando inconsistências como alvos de correção
Será que a Mozilla não poderia se concentrar em fazer um bom navegador?
Gostaria de ver mais detalhes sobre como fazer fine-tuning do SAM/2 para detectar piscinas ou arranjos solares
Ambos seriam muito úteis se mapeados para projetos de resiliência comunitária, mas foi difícil acompanhar o fine-tuning do SAM2
Encontrar e segmentar energia solar com um modelo Yolov8 funciona razoavelmente bem, mas as bordas ficam tão ruins que exigem um trabalho enorme de limpeza
Vi os resultados de um SAM2 treinado e pareciam muito melhores
Por questões de precisão, eu não colocaria isso no OSM, mas em outros lugares dá para usar sem problemas
Os dados de segmentação do OSM não têm qualidade suficiente para treinar corretamente um modelo de segmentação
Aqui usamos um modelo YOLO para previsão de caixas delimitadoras
As caixas delimitadoras do OSM são suficientes para esse uso, e cada caixa delimitadora é passada ao SAM2 como prompt para que ele segmente o interior
Também tentamos passar o ponto central da caixa ao SAM como prompt, mas os resultados foram piores
Lançamos uma nova versão incorporando vários feedbacks, e todo o código que fazia upload direto para o OSM foi substituído por exportação no formato OsmChange
Espero que seja um passo na direção certa, e vamos continuar a discussão em um tópico dedicado no fórum do OSM