[Talk-br] Sobre addr:interpolation - possibilidades

[George Silva]

Uma das dificuldades que encontramos na hora de realizar uns testes foi
justamente esta forma mais complexa do OSM de usar faces de quadra para
numeração.

Concordo com o Vitor, é menos preciso usar a via, mas é muito mais ágil. Na
realidade, os geocoders poderia descontar um pequeno trecho do inicio do
fim da via. Ou seja, mais fácil de resolver com programação esse cenário.

Em vários municípios a base geocodificada é desta forma, utilizando-se o
próprio eixo da via.

Se fosse para votação, manteria o sistema de faces de quadra, mas também
permitiria a interpolação no próprio trecho.

2016-12-16 0:46 GMT-02:00 Vítor Rodrigo Dias <vitor.dias em gmail.com>:

> Usar o SHP das faces fornece uma localização bem mais precisa. E dá pra
> cruzar tudo: setor, quadra e face.
>
> Em qui, 15 de dez de 2016 às 22:15, Sérgio V. <svolk2 em hotmail.com>
> escreveu:
>
>> Pois é, esta seria a ideia:
>>
>> se der pra usar addr:interpolation "no próprio eixo da via", contendo
>> numeração impar/par (início cf. sentido da via ou critério local).
>>
>>
>> Creio que pode ajudar mais do que o sistema que tem sido
>> usado atualmente, de adicionar 2 ways paralelos, resultando em 3 ways: eixo;
>> lado esquerdo; lado direito.
>>
>>
>> A primeira questão é: teria que ser proposto no talk-tagging mundial.
>> Só antes poderíamos tentar testar separadamente pra ver como poderia
>> funcionar e adicionar os dados que prefeituras tenham disponíveis.
>>
>> Vantagens:
>> -para tentar agilizar o andamento das numerações de enderço
>> (coisa que é cada vez mais necessária para popularizar o OSM);
>>
>> -evita ter que usar 3 ways para a mesma via e sobrecarregar de dados
>> triplicados;
>>
>> -evita ter que "arrumar" 3 ways se tiver que realinhar alguma via;
>>
>> -evita poluição de ways;
>>
>> -evita problemas de outros mexerem (alterar, arrastar, etc) no way
>> errado ao editar;
>>
>>
>> Problemas eventuais (a verificar como contornar):
>>
>> -se alguém posteriormente fundir ways que estavam numerados em
>> sequência, bagunça a numeração.
>>
>> -talvez uma tag adicional para receber feedback ou correções (pode ser o
>> próprio "fixme": "=confirmar interpolação")
>>
>> - - - - - - - - - -
>>
>> -Da questão de lado e sentido de vias:
>>
>> Não serve colocar um padrão fixo, cada área tem o seu (ou nem tem):
>>
>> de todo modo teria que ser para verificar cada cidade/região a
>> interpolar e se necessário inverter no ato de taggear:
>>
>>
>> 1)Pensando melhor, pra adaptar a todos os casos, talvez tipo assim, 4
>> opções de namespace:
>>
>> addr:interpolation:left:odds=<inicio-fim>
>>
>> addr:interpolation:right:evens=<inicio-fim>
>>
>> ou
>>
>> addr:interpolation:left:evens=<inicio-fim>
>>
>> addr:interpolation:right:odds=<inicio-fim>
>>
>> 2)Se não tem lado bem definido, continua a usar apenas a tag básica:
>>
>> addr:interpolation=<inicio-fim>
>>
>>
>> Ou outra ideia melhor se tiver.
>>
>>
>> Sim, seria algo mais especializado. A princípio não é coisa simples para
>> principiante fazer (mas a atual addr:interpolation, também não o é de
>> todo modo)
>>
>> - - - - - - - - - -
>>
>>
>> QUANTO ÀS OBJEÇÕES:
>>
>>
>> 1)Uso indiscriminado de addr:interpolation :
>>
>> Obviamente não é necessário uso indiscriminado.
>>
>> Mas acho que temos que avançar na numeração e eventualmente
>> com automatização e/ou aproximação para isso se necessário. Ou vamos
>> esperar uns 20 anos pra ter numeração exata, ficando para trás na
>> popularização, só nós mesmos usando.
>>
>>
>> 2) O fato de eventualmente errar em numeração (lado da via, extensão da
>> numeração (range)) não me parece grave.
>>
>> Mesmo que errar algo, já ajuda p.ex. ter número na área mesmo que
>> só aproximada.
>>
>> Google libera assim, e faz bem. Alguns podem reclamar, porque ajuda de
>> fato, já aproxima. Não é lixo inútil. As pessoas usam porque de
>> fato ajuda. Em geral as pessoas não se perdem por causa de erro de
>> posição da numeração no GPS. Se perde se não olhar os números nas portas
>> também na realidade.
>>
>> Não dá para esperar perfeição. Tem que liberar pra uso. Ou então: não se
>> populariza, não terá mais gente contribuindo, e não se avança.
>>
>> O resto é feedback e correção progressiva.
>>
>>
>> 3) Endereçamentos do IBGE:
>>
>> No que vi no SHP face de logradouros (ways), não traz numeração de e
>> ndereços:
>>
>> ftp://geoftp.ibge.gov.br/recortes_para_fins_
>> estatisticos/malha_de_setores_censitarios/censo_2010/base_
>> de_faces_de_logradouros
>>
>> Endereços só encontrei na lista TXT em:
>>
>> ftp://ftp.ibge.gov.br/Censos/Censo_Demografico_2010/Cadastro_Nacional_de_
>> Enderecos_Fins_Estatisticos/
>>
>> vem listado o numero da rua, quadra, CEP, etc. Por estados/cidades
>> (código).
>>
>> Teria que processar a lista (no QGIS ou script), ver como poderia passar
>> para os ways do OSM para adicionar.
>>
>> Acho que talvez teria primeiro que cruzar com o SHP das faces, pra só
>> depois tentar ver como passar pras highways do OSM. Meio complicado, acho.
>> Talvez alguém pense jeito mais fácil.
>>
>>
>> Mas talvez sirva pra quem pretender extrair os CEPs.
>>
>>
>> De todo modo ainda vi que do IBGE tem que confirmar o ajuste da camada:
>>
>> entrou em CRS SIRGAS2000, mas nem sempre fecha bem com o que já está
>> correto no OSM com GPS, etc.
>>
>> No Centro de Porto alegre vi a diferença em torno de -40,-20m (x,y). Em
>> Viamão diferença não homogênea.
>>
>> Creio que seja problema de resolução e imagem usada no Censo 2010.
>>
>>
>> - - - - - - - - - - - - - - - -
>>
>> Sérgio - http://www.openstreetmap.org/user/smaprs
>> _______________________________________________
>> Talk-br mailing list
>> Talk-br em openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-br
>>
>
> _______________________________________________
> Talk-br mailing list
> Talk-br em openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>
>


-- 
George R. C. Silva
Sigma Geosistemas LTDA
----------------------------
http://www.sigmageosistemas.com.br/
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://lists.openstreetmap.org/pipermail/talk-br/attachments/20161216/5cb00d0b/attachment-0001.html>