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

Papibaquígrafo agostinho741-1 em yahoo.com.br
Quinta Janeiro 5 17:13:56 UTC 2017


A resposta à minha pergunta anterior — se é possível determinar o sentido da numeração de uma rua usando o CNEFE — está na página 83 deste documento:
https://international.ipums.org/international/resources/enum_materials_pdf/enum_instruct_br2010a.pdf
Pra resumir: em tese, é possível deduzir o sentido da numeração a partir do TXT e dos shapefiles. Se o resultado é confiável são outros quinhentos...


 

    Em Quinta-feira, 5 de Janeiro de 2017 16:00, Papibaquígrafo <agostinho741-1 em yahoo.com.br> escreveu:
 

 Está claro que a direção das linhas nos shapefiles de face de quadra é completamente aleatória, não indicando nem numeração crescente nem descrescente. Pois agora eu notei que nos TXTs do CNEFE os numeros de uma mesma face às vezes vem em ordem crescente, às vezes decrescente.
Alguém checou se por acaso as duas coisas se compensam? Ou seja, distribuindo os números na ordem do TXT ao longo da face na direção que consta no shp, obtemos sempre a ordem real dos prédios?

Além disso, notei que no TXT às vezes aparece um endereço S/N entre dois que tem número. Nesse caso, dá pra ter certeza que a ordem dos elementos no TXT corresponde à ordem real dos prédios?
 

    Em Quinta-feira, 5 de Janeiro de 2017 13:45, Peter Krauss <ppkrauss em gmail.com> escreveu:
 

 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 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/_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.brhttp://br.linkedin.com/in/ rrneveshttps://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/f30c44bb/attachment-0001.html>


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