[Talk-br] RES: Sobre addr:interpolation - possibilidades

Peter Krauss ppkrauss em gmail.com
Quinta Janeiro 5 12:45:41 UTC 2017


Oi gente, que tal *consolidar *as discussões e decisões de projeto*?*
É impossível acompanhar e tirar alguma conclusão mais séria aqui em meio a
tantos e-mails dispersos e tantos tópicos discutidos pela metade.

Para mim está claro que é um experimento sério de consolidação global de
dados, e que portanto requer antes um preparo, reprodutível por exemplo com
PostGIS, para *experts* em processamento de dados poderem conferir e
"assinarem embaixo" (eu me incluo nos voluntários), bem como emitirem
relatórios mostrando os rumos da coisa antes de alterar a base OSM.

O uso dos dados do CNEF e o cruzamento com dados do CRP
<https://github.com/OSMBrasil/CRP> são dos mais relevantes (!),
são dados oficiais e atualizados.
Talvez o mais importante não seja a interpolação (num país onde ainda tem
gente adotando numeração predial por Numerologia), mas o destaque das
inconsistências e o registro confiável e definitivo dos dados
relativos a *faces
de quadra*.

Se todos aqui são "meio nerd", pode ser direto no Github,

   https://github.com/*OSMBrasil* <https://github.com/OSMBrasil>/
*_NOME_DO_PROJETO_*

*Qual nome será dado a esse projeto?*  (ex. *CNEFE2010*)






Em 5 de janeiro de 2017 09:35, Reinaldo Neves <rneves em equacao.com.br>
escreveu:

> Também acredito que interpolação pelos dados do CNEFE vai trazer mais
> problemas que solução.
>
>
>
> Apenas a título de informação em São Paulo nas cidades que compõem a
> região metropolitana, a capital inclusive, o cep se inicia por zero,
> acredito que seja por isso que observou registros com 7 digítos.
>
>
>
> Evidente que o problema ocorre na definição do campo CEP com sendo int e
> não char como é o correto.  No arquivo do CNEFE original a informação está
> correta.
>
>
>
> _______________________________
>
> Reinaldo Neves
>
> ☎: (11) 3221-3722
>
> ✉: rneves em equacao.com.br
>
> http://br.linkedin.com/in/rrneves
>
> https://medium.com/Reinaldo_Neves <https://medium.com/@Reinaldo_Neves>
>
>
>
> *De:* Papibaquígrafo [mailto:agostinho741-1 em yahoo.com.br]
> *Enviada em:* quinta-feira, 5 de janeiro de 2017 07:49
> *Para:* OpenStreetMap no Brasil
> *Assunto:* Re: [Talk-br] Sobre addr:interpolation - possibilidades
>
>
>
> Santamariense,
>
>
>
> Sobre o ponto 1:
>
>
>
> O trabalho do recenseador não é muito diferente do nosso como
> colaboradores do OSM: você vai a campo e coleta os números da fachada das
> casas. Se falta o número de uma casa, então para todos os efeitos práticos
> esse número não existe: este é o princípio da verificabilidade do OSM ("the
> truth is on the ground"). Portanto, não há nada de errado em pular os
> endereços que constam como S/N no CNEFE. Pode-se até deixar uma nota
> dizendo "faltam N números nesta face" para posterior verificação.
>
>
>
> Por outro lado, ao adicionar interpolações, nós estamos "especulando" a
> respeito da numeração, o que de certa forma até fere o princípio da
> verificabilidade. E isso pode até mesmo introduzir erros e inconsistências.
> Se o número faltante é o da esquina, a interpolação não vai deixar de ser
> incompleta. Pior que isso, é sabido que existem quebras na sequencialidade
> dos números (acontece na rua em que cresci em Porto Alegre). Imagine se
> você usar um desses números "anômalos" (ou mesmo um dado incorreto, algo
> que há de existir no CNEFE) como base da interpolação!!
>
>
>
> (Note também que as tags para numeração interpolada foram pensadas para o
> sistema europeu, de números sequenciais. No Brasil, onde a numeração é por
> metro, mais de 9 em cada 10 números gerados serão inexistentes! Em uma mapa
> completo, a *não existência* de um número é uma informação tão importante
> quando o da *existência* de um número)
>
>
>
> Em suma, vamos tirar do CNEFE o que o CNEFE nos dá, sem especular em cima.
>
>
>
> Agora, sobre pontos menos importantes:
>
>
>
> a) Será preciso realinhar os shapes do IBGE com o OSM. Eu queria pedir que
> se mantenha um registro desses deslocamentos, para uso futuro. O workflow
> poderia ser o seguinte: 1. abrir o shp no JOSM e traçar algumas linhas
> entre uma esquina do shp e a correspondente esquina no OSM; 2. salvar essas
> geometrias em um arquivo; 3. usar a média aritmética das linhas para
> realinhar o shp; 4. *arquivar* o deslocamento usado em cada setor
> censitário nalgum lugar da wiki.
>
> b) Notei que há muitas inconsistências no campo CEP. Em São Paulo, por
> exemplo, eles tem só 7 digitios, o erro parece ser que falta o "1" no
> início.
>
> c) Sobre a tag source, veja exemplos mais recentes. Na importação de Nova
> York, não há source nos objetos. Note que ninguém jamais atualiza o source
> ao fazer uma edição, logo você precisa ir no histórico de qualquer forma
> para saber algo com convicção.
>
>
>
> E, pra finalizar, queria dizer que essa é uma ótima iniciativa. Parabéns!
>
>
>
> Em Quarta-feira, 4 de Janeiro de 2017 23:30, santamariense <
> imagens.sm em gmail.com> escreveu:
>
>
>
> @Papibaquígrafo,
>
> 1. A questão é que existem muitos SN (sem número) cadastrados entre
> casas que já tem número. E as linhas ajudam a tapar este buraco,
> interpolando numerações intermediárias que possam existir. Do meu
> ponto de vista todo o material é provisório, pois na maioria dos casos
> o ponto será apagado porque vai para a building quando se tiver a
> certeza de qual building é. E a linha será apagada quando todas as
> casas de uma face da quadra tiver os números corretos na building
> correta.
>
> 2. Interessante. Não tinha pensado nisso. Mesmo assim me pergunto se
> não seria melhor nos objetos para ser mais prático, quando futuramente
> alguém for contribuir, buscar a fonte em históricos de changesets é
> não-prático. Em Paris, tudo indica que se adicionou source a todos os
> objetos (http://overpass-turbo.eu/s/l3J)
>
> 3. Isso são pormenores, mas que são sim muito relevantes. Eu proponho
> que numa primeira fase, se faça testes em alguns municípios e que a
> gente (cada um) faça relatório concomitantemente ao trabalho, a fim de
> anotar todos os problemas/dúvidas enfrentados.
>
> _______________________________________________
> 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
>
>
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://lists.openstreetmap.org/pipermail/talk-br/attachments/20170105/1b8b8f86/attachment-0001.html>


Mais detalhes sobre a lista de discussão Talk-br