Talk:Pt:Import/Catalogue/Brazil PMPA Addresses Import
Insira aqui comentários que julgar necessários.
Sugestão de voto no Talk-BR
Por favor, votos de aprovação e discussões finais sobre aprovação em https://lists.openstreetmap.org/pipermail/talk-br/2019-February/012550.html
Ver sugestão de organização dos anúncios e do processo em Importações realizadas. --Krauss (talk) 09:09, 8 February 2019 (UTC)
Sugestão de "conversar" com outras importações
Esta Wiki e o histórico de importações-OSM no Brasil já possuem "massa crítica" e certo grau de maturidade, suficientes para evoluir, para padronizar o processo. Senão fica a pergunta,
Por que toda importação parece estar "reinventando a roda"?
Temos as paginas como Pt:Import, Metodologia/Importação de endereços e Curitiba/Importação IPPUC... Já seria possível comentar ou oferecer alguns esclarecimentos: o que há de comum e o que há de diferente?
Como muitos dos demais processos não se encontram documentados, convém chamar as pessoas que estão importando ou já importaram, para esclarecer e descobrirem juntos o que houve ou poderia haver de comum, de melhores práticas, em cada procedimento. --Krauss (talk) 09:09, 8 February 2019 (UTC)
- Obrigado Peter. / ...Por que toda importação parece estar "reinventando a roda"?... / a) Em parte talvez, creio, porque cada material costuma ter peculiaridades, formatos, exigências diversas. Sim, seriam muito úteis roteiros padronizados; talvez sejam possíveis; ou mais genéricos: todo modo algumas questões se repetem sempre, devem ser tomadas por padrão. Por exemplo, verificações iniciais de: qualidade de polígonos; de resultado efetivo de posicionamento e CRS (exemplo importação de polígonos de prédios - "Comparação prévia entre as camadas de dados..."); importante que possa ser previsto para isto ter elementos seguros para comparar (ex. marcos geodésicos, etc). b) Ou de fato talvez por excesso de cuidado, de minha parte, achando que precisará de todas estas explicações técnicas para ser compreendido e aprovado; talvez pudesse ter sido mais resumido (agora já está, creio melhor deixar assim); em outra, se pessoal achar, ou tendo um padrão do que é realmente indispensável registrar, pode-se resumir mais. / Sergio (talk) 09:48, 8 February 2019 (UTC)
- Concordo com o Sérgio. Toda importação deve ser documentada porque cada conjunto de dados tem suas peculiaridades porque cada grupo de cartografia fora do OSM tem suas próprias práticas, podendo afetar a qualidade dos dados. É justamente por causa das peculiaridades que elaboramos uma documentação e pedimos para a comunidade conferir o que está sendo proposto.--Fernando Trebien (talk) 19:08, 8 February 2019 (UTC)
Questão da necessidade (ou não) de ter addr:street
(esta questão é muito importante para esta e quaisquer outras importações do tipo de "endereços".)
-Levantada a questão de que: "para um endereço ser localizado no OSM, precisa ter ainda addr:street=*".
-Problema: nos dados originais não tem registrado nome da rua. O que pode ser obtido do original é:
addr:housenumber=* + coordenadas.
Necessidade (teórica ou real?): teria que complementar (adicionar) addr:street=* para todos os 200.000 nós. (?!?)
Dúvidas: Isso vale para qualquer endereço, para que possa ser localizado?
Possibilidades de executar:
a) automatizado: gerando e adicionando valores de "nome de rua" por análise de proximidade aos pontos: pode gerar erros;
b) manualmente: adicionando valores de "nome de rua" (preciso).
Objeções:
-É possível "retornar" o "nome de rua" por busca? Como com análise de proximidade? Os aplicativos podem operar assim?
Isso não pode deixar para ser feito pelos aplicativos de localização/navegação, sob demanda? Se isso for possível, não necessitaria adicionar valor de "nome de rua", nem manualmente, nem automatizadamente; simplesmente não adicionar.
-Se for real a "necessidade indispensável" de ter que constar ou "adicionar" addr:street=* a cada nó importado de addr:housenumber=*, mesmo onde não haja no original,
então vai certamente inviabilizar inúmeras possibilidades de importações de endereços.
-Se tiver que adicionar, sobretudo "manualmente": trabalho gigantesco;
eu não faço, esqueça-se; outros se quiserem peguem os dados ali disponibilizados e façam.
Sergio (talk) 11:48, 8 February 2019 (UTC)
- É possível projetar os pontos nas ruas e adicionar o nome das ruas aos pontos de forma automática no QGIS usando o plugin NNjoin. Ver: discussão e documentação do plug-in. Isso faz ~90% do trabalho MAS ainda requer uma conferência manual do resultado nos pontos junto aos cruzamentos, para garantir que a projeção encontrou a rua certa.--Fernando Trebien (talk) 19:13, 8 February 2019 (UTC)
- Probabilisticamente, como Porto Alegre tem numeração sequencial (então o truque a seguir não se aplica onde não for assim), quase todos os casos de projeção incorreta levarão a descontinuidades na sequência de números de uma rua. Então uma forma mais "fácil" de verificar manualmente se a projeção foi feita corretamente seria assim: após a projeção no QGIS pra associar o ponto ao nome da rua e após a conversão pro formato OSM, no JOSM:
- Escolher o nome de uma rua da lista de todos os nomes de ruas
- Pesquisar no JOSM pelo nome da rua (Ctrl+F → name="Nome da Primeira Rua")
- Percorrer visualmente os elementos selecionados pela pesquisa do passo anterior
- Em cada um dos cruzamentos da rua, certificar-se de que os elementos selecionados têm numeração consecutiva
- Eliminar o nome da rua da lista de ruas a serem verificadas, e repetir para a próxima
- No raro caso (< ~1%) de duas ruas se encontrarem aproximadamente na mesma numeração, passaria despercebida a associação incorreta. Acho que esse nível de incorreção poderia ser deixado para uma revisão posterior, já no mapa.
- É possível fazer um script que verifique se os números ao longo de uma rua são sequenciais, se é que já não existe (procurei e não achei). Uma forma relativamente simples (do ponto de vista da programação) é ordenar os pontos pela numeração, calcular a distância entre cada par de números consecutivos, e ordenar as distâncias de cada par em ordem decrescente - quase todos os erros vão aparecer no topo da lista. Uma forma mais precisa (mas requer um programa mais sofisticado, talvez não valha a pena a menos que a intenção seja reutilizar em outros lugares) seria projetar os pontos na rua, calcular a distância deles ao longo da rua desde o começo dela, ordenar os pontos pela numeração e percorrer a lista verificando se cada ponto na sequência incrementa a distância desde a origem - onde decrementar (significando que "voltou-se atrás na rua") há um erro na sequência.
- Essa abordagem DEVE dar errado nos casos de ruas com o mesmo nome (ex.: "Rua 1" em bairros diferentes). Nesses casos não tem como escapar de uma revisão manual.
- --Fernando Trebien (talk) 19:44, 8 February 2019 (UTC)
- @Ftrebien: e @SergioAJV: parace que há convergência em se aceitar diversos casos de "addr:street inferido", mas hoje o OSM-Brasil carece de regras claras... Que tal propormos algumas regras? O efeito prático seria uma importação parcial, nem todos os pontos carentes de rua poderiam ter sua tag "addr:street" inferida. Também podemos sugerir algo como a tag "addr:street:inferrd" analog do "addr:interpolation" (ou ainda "addr:inclusion"). --Krauss (talk) 20:10, 8 February 2019 (UTC)
Obrigado a ambos Krauss e Fernando, certamente vocês entendem muito mais das matemáticas e programações possíveis, suas contribuições são valiosas.
De minha parte vou testar efetuar a projeção dos pontos às linhas de vias do OSM e assim que conseguir trago.
Sim, pode-se ir montando e propor um roteiro padrão básico de regras comuns para tipos comuns de importações, como sugerido.
Que tente abarcar as possibilidades de objetos e fontes diversas, oferecendo um roteiro básico historicamente comum de passos + operações e algoritmos de preparação de dados, como este caso de adição de addr:street; posicionamento de pontos de endereços em testadas; etc; e outros processos comuns de se encontrar em importações. Pode começar com o roteiro básicos dos históricos de importações recentes; e ir sendo implementada com outras situações encontradas. As fontes sendo variadas, os problemas tendem a ser em parte comuns, e em parte diversos também. Que possa ajudar muito diversas futuras importações de materiais, que podem ocorrer em vários outros locais. Tipo uma wiki, que possa ser na página de talk votada pela comunidade para proposta adoção como roteiro padrão. Vai-se vendo como fazer. --
Sergio (talk) 10:29, 9 February 2019 (UTC)
Testes de adição de addr:street / QGIS-NNJoin
Seguindo a proposta do @Ftrebien::
PROCEDIMENTOS - QGIS - NNJoin:
1) ENDEREÇOS (PONTOS): JUNTAR TOTAL SHPs: NUM1 + NUM2 (com e sem conflito, tudo) PRESERVAR todos os campos: SMF_IDNUM1=* e SMF_IDNUM2=* (e todos os outros) ARQUIVO: TOTAL-NUM1-NUM2-OK-E-CONFLITOS-203058.shp (WGS84) = 203.058 objetos 2) LOGRADOUROS (LINHAS): Usando OVERPASS no JOSM para: WIZARD: highway=* and highway!=path and highway!=track and highway!=proposed and highway!=cycleway and type:way in "Porto Alegre" Removidas todas tags que não são: highway=* / name=* / postal:code=* Salvo .osm / .geojson Convertido p/ SHP só linhas = 25.835 features (linhas) / (WGS84 / UTF-8 names) ARQUIVO: TOTAL-highway-OVP-10-02-2019.shp (WGS84 / UTF-8 names) QGIS: NNJoin Warning: Geographic CRS used for the join layer - distances will be in decimal degrees! 1-Input layer: TOTAL-NUM1-NUM2-OK-E-CONFLITOS-203058.shp 2-Join layer: TOTAL-highway-OVP-10-02-2019.shp 3-Output layer: NNJoin-TOTAL-N1-N2-203058.shp (distance dec.degrees) RESULTADO - NNJoin: ARQUIVO: NNJoin-N1N2-HGW-TOTAL-203058.shp Total = 203.058 objetos (endereços) ----------------------------------- CAMPOS NO RESULTADO NNJoin: distance (dado por NNJoin; in dec.degrees; real 23 / length=15): join_name (p/ addr:street=*) quantidade = 194.796 : 96% do total join_post (p/ postal:code=*) quantidade = 439 : 0,2% do total (=desprezível) adicionado campo: dist_metro (L15;P5) (= "distance" x 96480 m): "WGS 84...no nível de latitude 30° S, um grau de longitude equivale a 96,48 km" (https://pt.wikipedia.org/wiki/Paralelo_30_S) ESTATÍSTICAS SIMPLES: ANÁLISE CAMPO "dist_metro" menor = 0.00016 m (0,16mm) = menor probabilidade de erro maior = 1952.29411 m = MAIOR probabilidade de erro DIFERENÇA: 7 casas decimais (10^7) DISTÂNCIAS NORMALMENTE ESPERADAS EM ESQUINAS: Tamanho médio de frente de lotes (testada; na prática; não calculado): ~ 15m (unifamiliar/casa) a 30m (multifamiliar/edifício) = Até "dezenas" de metros. CAMPO "dist_metro" : QUANTIDADES DE DECIMAIS de metros : ------------------------------------------------ com valor > milhar 1xxxx m) : 0 com valor em milhar (1xxx m) : 7 = 0,003 % // MAIOR PROBAILIDADE DE ERRO com valor em centena (1xx m) : 569 = 0,280 % com valor em dezena (1x m) : 173408 = 85,398 % // ACUMULADOS COM DIST. < 100m = 99,716 % com valor em metro (x m) : 28721 = 14,144 % com valor < metro (0.x m) : 353 = 0,174 % ------------------------------------------------ CONCLUSÃO ATÉ AQUI: A DISTÂNCIA DEPENDE TAMBÉM DA LARGURA DO LOGRADOURO, NÃO SÓ DE ERRO; PORCENTAGEM AJUDA MAS NÃO GARANTE; O QUE DETECTA MESMO É A QUEBRA DE SEQUÊNCIA
- AMOSTRAS SEPARADAS:
- a) 20 MAIORES DISTÂNCIAS: >> NNJoin-N1N2-HGW-20maiores.shp
- b) PARA VERIFICAR ESQUINAS COMUNS E LOTES DE MEIO DE QUADRA:
- Rua Vicente da Fontoura esq. Livramento e arredores
- (onde tem erro certo de Join por proximidade; amostra de toda extensão da Rua Vicente da Fontoura)
- >> NNJoin-N1N2-HGW-amostraVF.shp (5146 objetos)
- -----------------------------------
- EXAMES:
- AMOSTRA a) 20 MAIORES DISTÂNCIAS:
- Verificação:
- Das 20 maiores distâncias (probabilidades de erro):
- -Todos na zona sul rural;
- -os 07 primeiros são todos NUM1 (=não compatibilizada pela PMPA);
- -1º e 2º estão em uma fazenda: na orla zona sul rural (pegou nome da "Estrada Otaviano José Pinto");
- deveria ser acesso (não havia mapeado) na "Estrada Armando Inácio da Silveira"
- = aparentemente anomalia esperada como caso de acesso não mapeado (mapeado agora);
- >> adicionar marcador "fixme=addr:street"; poderia pegar o nome da "Estrada Armando..."?;
- -3º,4º,6º,10º estão "fora de PoA": em Viamão, é dado anômalo original;
- em uma vila; tomou nome da estrada mais próxima em PoA (Estrada das Quirinas);
- >> adicionar marcador "fixme=addr:street"; pegar manualmente o nome da estrada de Viamão (que cai fora da zona de vias próprias);
- -5º,7º,8º em fazenda, morro: (Estrada da Taquara); não pegou o nome = aparentemente erro
- >> adicionar marcador "fixme=addr:street"; pegar manualmente o nome da estrada
- -9º na orla zona sul rural: :Beco do Difini = aparentemente correto
- -------------------------------------------------------------------------
- Possibilidade de derivar +/- em um ROTEIRO, por princípio:
- 1) Efetuar NNJoin para adicionar "addr:street";
- mas tende a dar erros em esquinas e lotes de meio de quadra
- 2) POSSIBILIDADES DE DETECÇÃO DE ANOMALIAS DE ADIÇÃO DE "addr:street" POR NNJoin:
- -adicionar marcador "fixme=addr:street" onde detectar erro ; e/ou "fixme=addr:street confirm" onde supor dúvida
- (não adicionados ainda neste teste nem nas amostras ainda)
- 2.1) P/ REVISÃO MANUAL TOTAL (SE NÃO TIVER AUTOMAÇÃO):
- -revisar todas esquinas, todos os lotes de meio de quadra ?
- -os 1% de valores mais altos que o restante ? (neste caso daria uns 2.000 de 200.000)
- 2.2) AUTOMATIZAÇÃO P/ DETECTAR ANOMALIAS:
- -adicionar marcador "fixme=addr:street" onde houver quebra de sequência (erro conhecido);
- -revisão manual destes;
- Validação no JOSM:
- Buscar objetos marcados com "fixme=addr:street....":
- -Indicam necessidade de "REVISAR MANUALMENTE";
- -podem ser removidos e separados para poder importar o resto?;
- -posteriormente revisar só estes anômalos (não afetam importação dos restantes que são "bons").
- Sergio (talk) 19:57, 10 February 2019 (UTC)
Resposta SMF: não há campo de atributo direto de rua p/ numeração
Transcrevo resposta chegada agora da pergunta ao pessoal da cartografia da SMF.
Uma ideia surge agora dali: usar a camada de logradouros (EIXOS_TMPOA.SPH) com
(Numerações par e ímpar, inicial e final)
para ajudar a pré-localizar um número.
Já tem ali a sequência.
Não sei se ajudaria de fato.
Ainda tem o fato de, no EIXOS_TMPOA.SPH, os "nomes de ruas" e as "linhas" não casarem direto com os do OSM.
Assunto: Dados de endereços - Sistema de Referência de Coordenadas e Descritivo
Em seg, 11 de fev de 2019 às 09:58,
Alberto / @smf.prefpoa.com.br> escreveu:
Sérgio, bom dia
As informações que foram disponibilizadas (NUM e NUM2) não possuem nenhum atributo que as relacione de uma forma direta aos logradouros e/ou CEP.
Em nossas buscas por endereço, são utilizadas as informações que constam na camada dos logradouros (Numerações par e ímpar, inicial e final) e,
a partir da localização indicada, procuramos a numeração específica do imóvel.
Não é de meu conhecimento que exista algum relacionamento entre a camada dos logradouros e o CEP,
mas o Rodrigo Marsillac poderá informar com maior certeza.
Att,
Alberto
Engenheiro Cartógrafo
De: Sérgio
em: sexta-feira, 8 de fevereiro de 2019 17:00
Boa tarde Alberto,
pergunto se a Prefeitura tem alguma base de dados
que permita algum vínculo direto (ou indireto) de identificação entre "logradouros" e a "numeração" do MDB.
E com CEP, se tiver.
Antecipadamente obrigado por qualquer informação.
Sérgio