Importação de endereços Contagem/MG

Bom dia,

Gostaria de apresentar a proposta de importação de pontos de endereços em Contagem/MG.

A Prefeitura Municipal de Contagem cedeu ao Instituto AddressForAll (que eu represento) um pacote de dados contendo quadras; pontos de endereços, divisa de bairros, lotes e eixos de vias. A licença indicada pelo doador é CC0/Domínio Público.

O import é focado em pontos de endereços (103.847 pontos). O restante fica como material de apoio do import e para uso de outros usuários no OSM, eventualmente.

A proposta está detalhada na wiki, com a evidência da licença e link para o pacote de dados: Contagem/Importação Prefeitura Municipal de Contagem 2023 - OpenStreetMap Wiki

Fico disponível para esclarecimentos e sugestões de melhoria.

Excelente! Tem previsão para uma tarefa de atualização dos nomes de rua futuramente com base nesses dados da prefeitura (imagino que sejam os certos, oficiais)? Numa olhada rápida, notei que tem várias diferenças entre esses nomes e os já mapeados.

1 Like

Parabens Igor

1 Like

Oi Igor, primeiramente parabéns pelo empenho em realizar a importação. Desde já você tem meu apoio!

Gostaria de fazer algumas considerações, não duvidando da sua capacidade de realizar a importação (dado seu excelente histórico no OSM!), mas justamente para que passe mais fácil pela comunidade internacional e também para ficar registrado aqui para futura consulta.

Gerais:

1 - Licença está ok, excelente!
2 - As orientações de importação pedem (mas não exigem) um certo template na criação da wiki, que engloba os principais pontos para uma importação de sucesso. Acho que valeria a pena adaptar esse template (um exemplo PT aqui: Dourados/Projetos/Importações/Árvores - OpenStreetMap Wiki)
3 - Seguindo esse template, acho que o que faltou para mim é demonstrar em detalhe o Processo da importação (limpeza dos dados, qual software, vai ser mais automatizado ou manual etc).
4 - Na seção Atribuição, meio que ficou decidido pela comunidade que, em importações, não é necessário adicionar source em cada nó, mas sim diretamente no Conjunto de Alterações.
5 - Não sei está escrito em algum lugar, mas a comunidade geralmente pede para prover um arquivo .osm teste para identificar que o Processo está adequado (limpeza de dados, uso de etiquetas corretas etc). Seria interessante se você conseguisse mostrar um exemplo de como ficariam os dados a serem enviados.

Específicas

Como te disse no Telegram, @Gustavo22Soares, @Smarzaro e eu tínhamos uma ideia de realizar essa importação. A princípio, identificamos que era necessário um tratamento decente dos dados, apesar da qualidade evidente. Vimos que:

1 - arrumar maiúsculas
2 - arrumar acentuação
3 - arrumar nomes compridos, que foram cortados
4 - arrumar algumas abreviações
5 - arrumar nomes incorretos (tipo Rua Turqueza)
6 - filtrar dados com número de imóvel = 0
7 - filtrar dados com número de imóvel incompatível (números grandes ou que não são números)
8 - adicionar addr:suburb (tem arquivo de bairro, é só fazer o merge espacial) e adicionar addr:city=Contagem
9 - nomes de bairros precisam ser ajustados também
10 - Overpass diz que há cerca de 1100 endereços em Contagem, então conflação deve ser fácil de fazer:

[out:xml][timeout:250];
{{geocodeArea:Contagem Minas Gerais}}->.searchArea;
(
nwr["addr:housenumber"](area.searchArea);
);
// print results
out meta;
>;
out meta qt;

Por isso que pediria para termos um exemplo (bairro ou alguns quarteirões, por exemplo), que assim a comunidade pode ver que o arquivo a ser enviado ao OSM está bem.

De qualquer forma, fico à disposição para conversar (pode mandar mensagem no privado no Telegram), mas tenho certeza que tem tudo pra dar certo nessa importação, os dados são muito bons e o usuário também é capacitado!

2 Likes

Legal seus comentários, Matheus, tanto os gerais como os específicos.

Sobre os nomes de ruas, isso também chamou minha atenção, precisam de um bom saneamento antes da importação. Além dos muitos erros de acentuação - parece que houve um início de saneamento na acentuação mas ficou incompleto, p. ex. não encontrei nenhuma ocorrência de ‘ção’, todas estão com ‘cao’ - há também ouitros tipos como partículas ‘de’ aparentemente extras ex: ‘Rua de Constantinopla’, ‘Rua de Atenas’, e várias outras assim na mesma região, as quais já estão mapeadas sem esse ‘de’.

IgorElizer, me coloco à disposição para ajudar no sanemento de erros de acentuação e outros detalhes como abreviaturas nos arquivos GeoJSON. Não é 100% mas a grande maioria fica corrigida. Se for de interesse é só avisar.

2 Likes

Sim, é de interesse. Já estou vendo isso com o pessoal do instituto. Logo saem os próximos passos.

Informação adicional:

O mapa de pontos de Contagem já é dividido em blocos de ~10.000 pontos. Pode-se ver isso na versão geojson: https://github.com/digital-guard/preservCutGeo-BR2021/tree/main/data/MG/Contagem/_pk0009.01/geoaddress

Sim, é de interesse. Já estou vendo isso com o pessoal do instituto. Logo saem os próximos passos.

OK, já gerei geojsons com a grande maioria dos novos nomes das vias e dos endereços corrigidos (acentuação, abreviaturas, etc).

Uma outra coisa, parece que vai ser necessária uma grande atualização dos nomes de rua já mapeados para ficarem coerentes com os endereços importados. Para facilitar, testei um procedimento de identificação automática das vias cujos nomes mapeados não batem com os “novos” já corrigidos e são muitos mesmo, mais de 1.800. Esse procedimnento gera um .geojson que funciona como uma camada no iD ou JOSM com indicações das vias a serem verificadas/corrigidas.

Como muitas vezes é difícil dizer qual é o nome certo, o mapeado ou o novo, acho que vai envolver um grande trabalho manual de edição. As imagens abaixo mostram a camada que indica as diferenças. Os dados da “bolinha” selecionada aparecem à esquerda para decisão do mapeador:

1 Like

Não saberia responder, porque para mim tudo é manual (eu edito e olho no editor) e tudo é automático (o editor valida e envia).

O que eu planejava fazer seria:

  1. abrir o shapefile/geojson no JOSM.
  2. escolher um bloco, quadra ou uma região pequena.
  3. converter as tags para o padrão OSM.
  4. rever visualmente, considerando compatibilização com elementos pré-existentes.
  5. executar validação do JOSM.
  6. correções/revisão final.
  7. envio com preenchimento dos metadados do changeset.
  8. repete 1 – 7 no próximo bloco.

Pode-se ver os arquivos geojson, dividido por setores de 10K pontos: preservCutGeo-BR2021/data/MG/Contagem/_pk0009.01 at main · digital-guard/preservCutGeo-BR2021 · GitHub. Eles já estão no padrão OSM de etiquetas. Só precisaria de revisão manual (checar nome de rua e “sem números”).

Igor, Matheus, se ajudar, podem verificar os arquivos no link abaixo:

Contém uma versão do original com nomes de ruas (lns_7h2.geojson) e uma versão de cada um dos arquivos de endereços (pts_7h2??.geojson) com os nomes de rua já corrigidos em sua grande maioria (acentuação, abreviações expandidas, ortografia, complemetados os truncados, apenas iniciais maiúsculas). Pode haver um ou outro caso que tenha passado despercebido sem correção ou eventuais erros meus de digitação nas tabelas de correção, mas creio que a maior parte está corrigida. Usei um software meu nessa correção.

Contém também um arquivo GeoJSON com indicações das vias mapeadas atualmente com nomes diferentes dos “novos” já corrigidos. Esse arquivo funciona como uma camada auxiliar para verificação e correção manual no iD, ou no JOSM. A deteção automática das vias com nomes diferentes é um procedimento que depende de vários detalhes do mapeamento e nem sempre encontra tudo, mas também nesse caso muita coisa é indicada, facilitando a verificação e correção manuais. Usei um outro software meu para gerar esse arquivo.

No meu modo de ver, creio que numa primeira fase seria importante atualizar os nomes de rua já mapeados com base nos novos arquivos da prefeitura (os já corrigidos, após revisão manual). Trabalho manual, difícil saber qual é o nome válido automaticamente, o mapeado ou o “novo”. Nisso o GeoJSON com nomes diferentes vai ajudar. A inclusão dos novos nomes ainda não mapeados (vias ainda não mapeadas ou sem nome) é mais simples.

Como tanto o arquiivo com nomes de ruas e os com endereços passaram pelo mesmo processo de correção, devem estar coerentes. Entretanto, isso não garante que o nome da via no endereço esteja batendo com o nome da via próxima, requer também verificação manual (ou usar a consulta para indicar addr:street diferente do name da rua próxima).

Para a fase de importação dos endereços, não sei que software usam para detetar colisão dos novos com os já mapeados, mas é possível filtrar automaticamente os novos que não tenham nenhum próximo (raio de 30m?) já mapeado. Isso permitira uma importação em lote dos filtrados com baixo risco de colisão/duplicação/erro. Os demais teriam de ser importados manualmente, corrigindo as colisões.

1 Like

Obrigado Fidelis. Estão muito bons os arquivos de correção. Encaminhei para o pessoal do Instituto para também fazer uma análise técnica, aí qualquer melhoria a gente compartilha com a comunidade para o import.

Realmente vi que o valor addr:street de algumas ruas divergem do name no eixo da via.

image

Temos os shapefiles e geojson dos eixos de vias. Será que ajudaria numa possível correção?

Descobri mais nomes que precisavam correção (acentuação, grafia, truncados, etc) e atualizei o zip (mesmo link anterior). Incluí no GeoJSON que mostra as divergências de nomes entre mapeadas X novas corrigidos (~1000), também as indicações de vias ainda não mapeadas ou com geometria alterada (~2000). A comparação dos nomes só é feita entre vias com traçado semelhante - inciam em pontos próximos e também terminam em pontos próximos.

Temos os shapefiles e geojson dos eixos de vias. Será que ajudaria numa possível correção?

A dificuldade que vejo aí é saber qual é o nome certo da via: o mapeado ou o do GeoJSON da prefeitura. Ex. há casos em que os nomes estão diferentes mas o nome no GeoJSON bate com o old_name mapeado sugerindo que algum mapeador já atualizou mas a prefeitura ainda não no GeoJSON.

Creio que só um trabalho de edição manual com o pessoal da própria prefeitura para garantir os nomes certos. Depois disso vai dar para identificar os erros de addr:street não batendo com a rua a que pertence (tem uma consulta overpass para isso).

@Fidelis_Assis e a outros a que interessarem:

O pessoal técnico do instituto fez a consolidação dos dados de MG-Contagem, com padronização dos valores dos endereços.

A pedido do pessoal técnico do instituto, repasso a explicação e os links para os datasets:

Olá, nossos dados em CC0 estão sendo mantidos nesse git, já incluimos todas as suas correções nele,
data-consolidation-BR/data/MG/Contagem at main · AddressForAll/data-consolidation-BR · GitHub

PS: os nomes de coluna que usamos não são padrão-OSM, se preferir uma versão do mesmo CSV porém com nomes de coluna mais amigáveis, pode usar esse link temporário, https://addressforall.org/_private/tmp_contagem.zip

Qualquer dúvida, me pergunte, que eu passo para lá.

Igor, a ideia com esse data.csv seria fazer as correções dos nomes nele em vez de nos GeoJSON? Se for isso, tranquilo, posso disponibilizar uma versão acentuada do csv.

1 Like

Atualizei o arquivo “Vias e endereços acentuados - Contagem-MG.zip” - mais correções e expansões de nomes. Mesmo link de mensagem anterior.

Conteúdo atualizado:

   Date      Time    Attr         Size   Compressed  Name
------------------- ----- ------------ ------------  ------------------------
2023-12-11 14:10:21 .....       620686        59416  Vias com nomes diferentes - Contagem-MG.geojson
2023-12-11 13:59:47 .....        58256        13345  edições-de-nomes.txt
2023-12-11 13:52:37 .....      7882935      1442430  data-acentuado.csv
2023-12-11 13:52:30 .....      4105832       660063  lns_7h2-acentuado.geojson
2023-12-11 13:52:29 .....      1938105       136663  pts_7h2wy-acentuado.geojson
2023-12-11 13:52:29 .....      1012853        72060  pts_7h2ww-acentuado.geojson
2023-12-11 13:52:28 .....      1458620       101219  pts_7h2wv-acentuado.geojson
2023-12-11 13:52:28 .....      3677278       259911  pts_7h2wt-acentuado.geojson
2023-12-11 13:52:28 .....       270739        17892  pts_7h2wt2-acentuado.geojson
2023-12-11 13:52:27 .....      2559053       181891  pts_7h2ws-acentuado.geojson
2023-12-11 13:52:26 .....      2540995       179784  pts_7h2wm-acentuado.geojson
2023-12-11 13:52:25 .....      2920495       206040  pts_7h2w-acentuado.geojson
2023-12-11 13:52:24 .....      3981395       208677  pts_7h2-acentuado.geojson
------------------- ----- ------------ ------------  ------------------------
2023-12-11 14:10:21           33027242      3539391  13 files

O arquivo edições-de-nomes.txt tem uma lista dos nomes de rua que foram editados para validação do pessoal técnico do instituto. Em muitos casos duvidosos, com erros de grafia e abreviações, etc, adotei o nome mostrado no Busca CEP.

1 Like

Boa tarde,

Darei o início ao import do material, usando o material corrigido de @Fidelis_Assis (de 11/dez/23).

Vou escolher o setor 7h2wt2 para iniciar o import.

Antes de eu começar, há ainda alguma objeção?

Eu não cheguei a acompanhar a discussão. Se teve qualquer objeção pelo caminho e já foi decidida, não vejo problema algum. Muito pelo contrário. Avante na importação!

1 Like

Fiz o primeiro changeset como teste: Changeset: 147463913 | OpenStreetMap

Questões:

  1. Tags usadas addr:housenumber e addr:street. Precisa adicionar addr:city?

  2. Casos com addr:housenumber={número};{número}. Provavelmente é um acesso a duas casas. Conforme já vi em conversas no Telegram, não precisa separar. Confirma?

  3. Casos com addr:housenumber=0. Esta tag pode ser convertida para [nohousenumber=yes](https://wiki.openstreetmap.org/wiki/Pt:Key:nohousenumber) sem problemas?

  4. Casos com addr:housenumber=0;{outro número}. É como caso 2, um acesso a duas casas, mas uma das casas é sem número. Como faria? Eu desmembraria em dois pontos: um com nohousenumber=yes e outro com addr:housenumber={outro número}.

1 Like
  1. Vejo addr:city=* como redundante no Brasil já que todo o território nacional é coberto por delimitação municipal.
  2. Eu separaria. Deixaria com ; se fosse o caso de uma residencia ter mais de um número segundo diferentes fontes como prefeitura e concessionárias de água e luz.
  3. Concordo.
  4. Eu apenas desconsideraria o número zero.

Entenda como sugestões, já que não analisei os dados como você fez.

1 Like

Não há duas fontes. A fonte é a prefeitura.

Talvez seja mesmo o caso de separar. Um exemplo:

Aqui há 3 números dentro de um lote. Parece ser um dos casos de lotes que são subdivididos em “apartamentos sem condomínio” (sem área comum) com acesso direto à rua. Dá para ver pelas setas vermelhas que há muros individualizando as unidades.

1 Like