[Talk-br] RES: idéias dados IBGE >> OSM: CNEFE, setores censitários, quarteirões.
Lucas Ferreira Mation
lucasmation em gmail.com
Quarta Abril 2 22:02:33 UTC 2014
Fernando,
concordo, tem várias etapas de "normatização" no CNEFE a serem feitas. Você
chegou a desenvolver algo para cruzar automaticamente estes
CNEFEs-normalizados com a lista de ruas do OSM?
2014-04-02 18:50 GMT-03:00 Reinaldo Neves <rneves em equacao.com.br>:
> Para uso com o OSM talvez seja interessante processar as tabelas mais
> normalizadas, eu subi os mesmos dados no MariaDB, com a seguinte estrutura:
>
>
>
> CREATE TABLE `cnefe` (
>
> `id_cnefe` int(11) NOT NULL,
>
> `id_uf` char(2) DEFAULT NULL,
>
> `id_municipio` char(5) DEFAULT NULL,
>
> `id_distrito` tinyint(2) unsigned zerofill DEFAULT NULL,
>
> `id_subdistrito` tinyint(2) unsigned zerofill DEFAULT NULL,
>
> `id_setor` smallint(4) unsigned zerofill DEFAULT NULL,
>
> `situacao_setor` tinyint(1) DEFAULT NULL,
>
> `tipo_end` varchar(20) DEFAULT NULL,
>
> `titulo_end` varchar(30) DEFAULT NULL,
>
> `nome_end` varchar(100) DEFAULT NULL,
>
> `numero_end` varchar(15) DEFAULT NULL,
>
> `compl_numero` varchar(30) DEFAULT NULL,
>
> `bairro_refer` varchar(40) DEFAULT NULL,
>
> `especie_end` char(2) DEFAULT NULL,
>
> `indicador_end` char(1) DEFAULT NULL,
>
> `numero_quadra` char(3) DEFAULT NULL,
>
> `numero_face` char(3) DEFAULT NULL,
>
> `cep_end` char(8) DEFAULT NULL,
>
> `id_loc_ect` int(11) DEFAULT NULL,
>
> PRIMARY KEY (`id_cnefe`),
>
> KEY `loc_ibge` (`id_uf`,`id_municipio`),
>
> KEY `loc_ect` (`id_loc_ect`),
>
> KEY `nome_end` (`nome_end`),
>
> KEY `tipo_end` (`tipo_end`)
>
> ) ENGINE=MyISAM DEFAULT CHARSET=latin1
>
>
>
> E separei tabelas com os nomes de logradouro por estado, uma tabela de
> localidades e complementos dos endereços que são informações que se repetem
> ou estão vazias na tabela original do cnefe:
>
>
>
> CREATE TABLE `localidade` (
>
> `id_uf` int(2) unsigned zerofill NOT NULL,
>
> `id_municipio` int(5) unsigned zerofill NOT NULL,
>
> `nome_municipio` varchar(60) DEFAULT NULL,
>
> PRIMARY KEY (`id_uf`,`id_municipio`)
>
> ) ENGINE=MyISAM DEFAULT CHARSET=latin1
>
>
>
> CREATE TABLE `complemento` (
>
> `id_complem` int(11) NOT NULL AUTO_INCREMENT,
>
> `id_cnefe` int(11) DEFAULT NULL,
>
> `complemento` varchar(180) DEFAULT NULL,
>
> PRIMARY KEY (`id_complem`),
>
> KEY `id_cnefe` (`id_cnefe`)
>
> ) ENGINE=MyISAM AUTO_INCREMENT=34164810 DEFAULT CHARSET=latin1
>
>
>
> CREATE TABLE `cnefe_53` (
>
> `id_cnefe` int(11) NOT NULL,
>
> `tipo_end` varchar(20) DEFAULT NULL,
>
> `nome_end` varchar(100) DEFAULT NULL,
>
> `numero_end` varchar(15) DEFAULT NULL,
>
> `compl_numero` varchar(30) DEFAULT NULL,
>
> `bairro_refer` varchar(40) DEFAULT NULL,
>
> `cep_end` char(8) DEFAULT NULL,
>
> `id_loc_ect` int(11) DEFAULT NULL,
>
> PRIMARY KEY (`id_cnefe`),
>
> KEY `loc_cep` (`id_loc_ect`),
>
> KEY `nome_end` (`nome_end`),
>
> KEY `bairro` (`bairro_refer`)
>
> ) ENGINE=Aria DEFAULT CHARSET=latin1 CHECKSUM=1 PAGE_CHECKSUM=1
> ROW_FORMAT=DYNAMIC
>
>
>
> CREATE TABLE `ident_domicilio_coletivo` (
>
> `id_cnefe` int(11) NOT NULL,
>
> `ident_domicilio` varchar(30) DEFAULT NULL,
>
> PRIMARY KEY (`id_cnefe`)
>
> ) ENGINE=MyISAM DEFAULT CHARSET=latin1
>
>
>
> CREATE TABLE `ident_estabelecimento` (
>
> `id_cnefe` int(11) NOT NULL,
>
> `ident_estabelecimento` varchar(40) DEFAULT NULL,
>
> PRIMARY KEY (`id_cnefe`),
>
> FULLTEXT KEY `identificacao` (`ident_estabelecimento`)
>
> ) ENGINE=MyISAM DEFAULT CHARSET=latin1
>
>
>
> Em paralelo estou fazendo um trabalho de correção/padronização em tipo,
> nome nomes de logradouros e bairros, tipos de logradouros. Caso alguém tem
> interesse posso disponibilizar os dados para download.
>
>
>
> Reinaldo
>
>
>
>
>
> *De:* Lucas Ferreira Mation [mailto:lucasmation em gmail.com]
> *Enviada em:* quarta-feira, 2 de abril de 2014 17:58
> *Para:* OpenStreetMap no Brasil
> *Assunto:* Re: [Talk-br] idéias dados IBGE >> OSM: CNEFE, setores
> censitários, quarteirões.
>
>
>
> Fernando, (o email ficou gigante de novo, mas tem que ir botando as idéias
> no papel...)
>
>
>
> bacana, você pode começar a wiki? Depois me passa as instruções que eu vou
> lá complementando/editando. Seria muito importante ter ajuda de mais gente,
> é bastante trabalho e requer algumas habilidades de programação (talvez
> valesse a pena fazer uma hackton ou algo assim, se tiver programadores ou a
> equipe em alguma universidade animada para ajudar), mas acho que o
> resultado pode sr fantástico.
>
>
>
> Eu não tenho familiaridade com programação phyton, web, e as várias APIs,
> instances do OSM, nem sei muito dos softwares de GIS. Entretanto consigo
> programar bem no Stata (um software estatístico, similar ao R só que
> proprietário) e tenho um servidor de 96gb de ram a que posso usar aqui.
> Então se alguém me ajudar a importar os dados do OSM como um "tabelão", eu
> consigo fazer o cruzamentos aqui, numa escala e velocidade muito boas e
> que seriam quase impensáveis nestes programas de GIS (Arcgis, Qgis).
>
>
>
> Abaixo alguns detalhes adicionais (tem muitas coisa para falar, espero que
> não fique gigante de novo):
>
>
>
> *A e 0)* Bacana que você mapeou corretamente as favelas. Talvez te
> interesse o estudo que estou participando sobre favelas no Brasil com base
> nestes mesmodados. Veja uma versão preliminar aqui<https://www.dropbox.com/s/l7hlb5dzr9ibe80/2014_03_31_Faveliza%C3%A7%C3%A3o%20no%20Brasil_preliminar_p_envio.pdf> de
> um dos artigos.
>
> A vantagem de garantir que o shape de setores censitários seja compatível
> é poder cruzar os dados do OSM com os dados dos censos. Isto é, poderia se
> ter informações demográficas (sexo, idade), renda, tx. de analfabetismo,
> etc para cada setor. Não sei qual a política do OSM sobre adicoinar este
> tipo de informação, imagino que seja de não adicoinar, mas ter a
> possibilidade de fazer estes cruzamentos é fundamental (seja apenas
> garantindo a compatibilidade dos arquivos,mesmo que separados, ou
> adicionando as fronteiras dos setores e seus códigos no OSM).
>
>
>
> A qualidade depende de lugar para lugar. Seria excelente mapear/corrigir
> isso.
>
> Para corrigir o shape de setoressei de 3 fontes que podem ser usadas:
>
> - o IBGE divulga um arquivo com a descrição dos perímetros dos setores.
> Tipo: "(1) esquina da rua X com a Y até (2) esquina da rua Y com a Z, (3)
> ... , (N) até retornar ao ponto original". Este é um arquivo descritivo
> quem vem junto dos dados de "Agregados por Setor Censitário". Vem um
> arquivo por estado, que coloquei aqui<https://www.dropbox.com/s/1q75e41tbludftf/descricao_perimetro_setores.7z>
> .
>
> - além disso o IBGE divulga um PDF o perímetro e quarteirões de cada setor
> (aqui por exemplo). É o que é usado como base para o IBGE tools (o problema
> é que lá, ao juntar/sobrepor imagens de diferentes setores, perde-se o
> perímetro do setor. Mas acho que seria interssante integrar com o que o
> Thiago Santos fez com o IBGE tools).
>
> - ontem fiquei sabendo que o Centro de Estudos da Metrópole refez/corrigiu
> o shape de setores censitários (aqui<http://www.fflch.usp.br/centrodametropole/1178>)
> das principais regiões metropolitanas. Entretanto o arquivo veio sem
> informações de projeção e ao tentar abrir vimos que estava errado, todo
> deslocado uns 30 metros para nordeste. Mas os contornos parecem mais
> corretos mesmo.
>
>
>
> *B)* Os arquivos do "CNEFE público" são disponibilizados em um txt para
> cada subdistrito, pelo IBGE aqui, veja no arquivo "layout" a estrutura da
> base. Além de muito "picotados" os dados vem num txt "colunado", então meio
> difícil de visualizar antes de importar como tabela. De todo modo eu já
> baixei tudo, importei e unifiquei em um único arquivo, que fica com 32GB no
> formato .dta (formato do Stata). Isso corresponde aos 81,5 milhões de
> endereços. Fiz várias tabelas com estatísticas (número de endereços
> ruais, endereços com coordenadas, end. com coordenadas por tipo de
> domicílio, etc..) que estão neste arquivo<https://www.dropbox.com/s/mo4taezn4d06f3q/estat%C3%ADsticas_CNEFE.log>.
> Dá uma olhada.
>
>
>
>
>
> *1)* Pedi ajuda sobre isso neste outro email pra lista<https://lists.openstreetmap.org/pipermail/talk-br/2014-April/006635.html>.
> Esta forma que você propôs seria bastante lenta. Acho que inviável. Uma
> forma natural seira fazer um "spatial join" do shape de ruas do OSM-Brasil
> com alguma divisão geográfica. Tentei fazer começando cruzando o shape
> the ruas do OSM-Brasil<http://download.geofabrik.de/south-america/brazil.html>com um shape
> de municípios<https://www.dropbox.com/s/zhsfdc0eqeijl24/malha_municipal2010.7z>do IBGE. Tentei no Arcgis e no Qgis, ambos travaram. Vou tentar agora em
> algum programa tipo SQL server ou PostGis. Este mesmo cruzamento pode ser
> feito em níveis mais desagregados (distrito, subdistrito, localidade (um
> conceito do IBGE que não sei exatamente o que é acho que é +o- equivalente
> a bairro) ou setor (garantindo antes a compatibilidade dos polígonos dos
> setores)). Outra possibilidade seria usar as divisões geográficas já
> incorporadas na base do OSMs e fazer uma exportação de uma tabela incluindo
> nomes de ruas e identificadores da divisão geográfica. No IRC#dev me
> sugeriram o OSMOSIS <https://wiki.openstreetmap.org/wiki/Osmosis>. Tem
> outras alternativas nesta wiki<http://wiki.openstreetmap.org/wiki/Shapefiles>.
>
>
> Enfim, acho que consigo fazer bem os cruzamentos, mas vou precisar de
> ajuda para tornar isso disponível de forma interativa na internet. Seja por
> tabelas aninhadas ou heat maps.
>
>
>
>
>
> 2) Concordo que é algo mais geral. Só não consigo pensar em outra base
> similar no Brasil. Talvez tenha interesse para gente de outros países, e
> neste caso se fizéssemos em inglês talvez atraíssemos mais voluntários para
> ajudar. Para mim não importa, só não queria criar muito overhead de ficar
> documentando em duas línguas, ou perder muito tempo discutindo isso.
>
>
>
>
>
> gostei das sugestões de como disponibilizar isso para os mapeadores. Mas
> vamos começar com o cruzamento, depois pensamos numa interface para quem
> estiver mapeando de fato
>
>
>
>
>
>
>
>
>
>
>
> 2014-04-01 12:44 GMT-03:00 Fernando Trebien <fernando.trebien em gmail.com>:
>
> Oi Lucas,
>
> A) Eu não sei se poderíamos importar no OSM os contornos dos setores
> censitários, não temos tags pra isso ainda. Mas podemos pensar em
> propor essas tags. Setores não são nem áreas residenciais
> (landuse=residential), nem limites administrativos
> (boundary=administrative), seriam algo novo. Talvez tenhamos alguns
> problemas em disponibilizar essa informação para que as pessoas
> alterem como queiram, o que poderia introduzir erros uma vez que os
> setores não são visíveis/identificáveis em solo e/ou imagens de
> satélite.
>
> C) Seria bem interessante importar os domicílios rurais com base
> nessas coordenadas. Onde encontramos essa informação?
>
> 0) Fiz a importação dos aglomerados subnormais (que são um subconjunto
> dos setores censitários) e a geometria me pareceu muito boa nos casos
> que eu tratei (revisei mais de 10 mil polígonos, um por um). Só em
> Salvador havia um deslocamento uniforme (que o Wille me avisou e eu
> corrigi manualmente depois) de menos de 30 metros.
>
> 1) Com o "osmosis" (https://wiki.openstreetmap.org/wiki/Osmosis) você
> consegue extrair geometria a partir de um polígono-limite. Se você
> baixar o mapa do país
> (http://download.geofabrik.de/south-america/brazil.html), pode aplicar
> o osmosis a cada uma das cidades ou mesmo a cada setor censitário (a
> partir do shape do IBGE), e com isso descobrir quais ruas pertencem a
> cada cidade/setor. Seria um processamento complexo e talvez demorado,
> mas possível.
>
> 2) Eu acho esse assunto muito interessante e acho que deveríamos
> pensar em generalizar para cadastros quaisquer (não só o CNEFE). Vamos
> criar uma página no wiki pra tratar disso como um projeto (com
> objetivos, idéias/brainstorm, obstáculos a resolver, etc.)? Acho mais
> fácil chamar gente pra nos ajudar se fizermos isso, e pra servir de
> registro/inspiração pra revisões similares no futuro.
>
> Da maneira que eu sugeri no fórum, acho arriscado aplicar uma correção
> 100% automática. O melhor é sugerir uma correção e deixar que as
> pessoas decidam. O CNEFE já se mostrou um tanto desatualizado nos
> casos em que eu testei.
>
> Eu também tinha em mente dividir o território em partes e entregar o
> resultado da comparação pros mapeadores locais, que então nos
> avisariam quais porções já foram tratadas/revisadas (ninguém mais
> precisaria repetir a comparação nessas porções).
>
> 3) Acho uma idéia interessantíssima.
>
> 4) Acho que se você conseguir extrair uma lista de nomes por setor
> como eu sugeri em (1), você não precisa fazer esse pareamento.
>
> Num primeiro momento, acho que o mais fácil seria fazer assim:
> - a partir dos shapes dos setores censitários do IBGE, extrair nomes
> de ruas para cada setor; isso envolve usar o osmosis pra extrair a
> geometria dentro dos limites do setor, e depois usar algo como o
> osmfilter pra extrair o nome das ruas
> - gerar, para cada setor, o resultado da comparação dos nomes de ruas
> (talvez usando o script que eu propus no fórum, com melhorias)
> - descartar os setores que não tiverem diferenças
> - distribuir para os mapeadores locais (talvez através do wiki) o
> resultado da comparação por setor, junto com o shape do setor, para
> que possam fazer os ajustes que acharem necessários
> - conforme vão consumindo essa informação, os mapeadores nos
> informariam e nós registraríamos no wiki quais setores já foram
> revisados (com isso os esforços se concentrariam nos setores que ainda
> não foram revisados)
>
> O que mais poderíamos fazer:
> - uma interface com o LeafletJS que, a partir da posição atual do
> usuário no mapa, descobriria qual é o setor mais próximo, mostraria o
> seu contorno e o resultado da comparação
>
> Mas o pessoal que está acostumado com o JOSM não precisaria muito
> disso. Poderíamos colocar (no próprio artigo do projeto) como usar o
> JOSM para fazer a revisão; isso seria mais fácil do que desenvolver
> uma interface só pra mostrar as diferenças graficamente com algum grau
> de aproximação.
>
> O mesmo processo poderia ser aplicado pra todas as demais comparações
> que pensarmos em fazer no futuro.
>
> Acho que, pras cidades menores, seria mais rápido/eficiente fazer a
> revisão por cidade ao invés de por setor.
>
> Que tal?
>
> 2014-03-31 6:32 GMT-03:00 Lucas Ferreira Mation <lucasmation em gmail.com>:
>
> >
> > Prezados,
> >
> > Sou economista e trabalho no IPEA, entre outras coisas, com questões de
> > economia urbana e favelas. Sempre sentimos falta de uma base de dados
> > completa, precisa e gratuita de ruas, e outros atributos. Apenas
> > recentemente tive contato com o OSM e estou impressionado com a riqueza
> de
> > informações disponíveis. O projeto e o trabalho de vocês é fantástico.
> >
> > Como tenho trabalhado com as bases de setor censitário e CNEFE do censo
> > 2010, minha primeira idéia ao entrar em contato com o OSM foi de trazer
> as
> > informações destas bases para dentro do OSM, ou como um rascunho-guia
> para
> > pessoas validarem. Sugeri esta idéia no forum
> > e o Alexandreme sugeriu a lista talk-br, onde encontrei outras treads com
> > idéias similares. Listo abaixo as informações que sei destas bases do
> Censo
> > 2010, e depois minhas idéias sobre como poderiam ser
> exploradas/mireradas:
> >
> > A) Setor censitário: são uma divisão do território para operacionalizar a
> > coleta de informação no censo, tal que um setor seja área de
> > responsabilidade de um único recenseador, com 250 a 350 domicílios em
> áreas
> > urbanas, um pouco menos em áreas rurais. Costumam corresponder a uns
> poucos
> > quarteirões, mas podem ser apenas um quarteirão, ou até meio quarteirão
> em
> > áreas muito densas. São 316,5 mil setores em 2010.
> > O IBGE fornece um shapefile para cada uf com os polígonos dos setores.
> Além
> > disso o IBGE fornece uma base de dados com informações
> > demográficas e econômicas agregadas para os moradores de cada setor
> > censitário. O grau de precisão destes shapes varia de cidade para cidade.
> >
> > B) Base de quarteirões/quadras: o IBGE também dispõem internamente de uma
> > base de dados de quarteirões, entretanto esta base, em formato digital
> não é
> > divulgada. Aprendi com o projeto IBGEtools (muito bacana por sinal), que
> > imagens dos quarteirões de cada setor estão dispníveis em PDF no site do
> > IBGE.
> >
> > C) CNEFE : lista os endereços de todos os domicílios recenseados = 81
> > milhões de observações. Para os domicílios rurais são incluídas as
> > coordenadas do domicílio. Para os urbanos é indicado o setor censitário
> > (localização conhecida pelo item A). Também são indicados o quarteirão e
> > face de quarteirão, cujo shape eles não divulgam mas que cuja numeração
> > segue uma contagem seguencial dentro do setor (acho que no sentido
> horário).
> >
> > Dado isso, listo as coisas dúvidas que penso que podem ser feitas e as
> > dúvidas associadas:
> >
> > 0) medir imprecisão dos shapes de setor censitário: acho que este
> > diagnóstico seria a primeira coisa a ser feita seria, para ter uma idéia
> do
> > grau de erro deste dado em cada cidade. Já foi feito alguma estimativa
> do
> > tipo ? Alguma tentativa de corrigir os shapes de setor censitário? Digo
> isso
> > porque as idéias subsequentes, na maioria usam o shape de setores para
> > juntar espacialmente os dados.
> >
> > 1) Comparar listas de ruas CNEFE vs. OSM para ver o grau de coberturado
> OSM:
> > , conforme proposto/implementado para o Brasil (aqui1 e aqui2) e Alemanha
> > (aqui). Esta comparação pode ser feita em diversas escalas (município,
> > distrito, subdistrito e até setor (supoondo mapas compatíveis) na forma
> de
> > tabela ou de um heatmap. Aliás, baixei o shape de ruas do Brasil do OSM
> mas
> > não vem com informação de município ou nenhuma indicação geográfica.Como
> > obtenho isso nos shapes do OSM? ou preciso eu mesmo cruzar com um shape
> de
> > municípios no qgis?
> >
> > 2) Dado este paramento, o CNEFE poderia ser usado para corrigir typos
> dos
> > nomes de ruas no OSM, ou pelo menos sugerir correções. (neste caso seria
> bom
> > fazer um matching probalistico/fuzzy dos nomes).
> >
> > 3) Criar traçados de ruas a partir de CNEFE+shape-setores. Conforme
> descrito
> > no post no forum, sabendo que a rua passa dentro de um conjunto de
> setores
> > seria possível esboçar o trajeto da rua, ou uma área no meio da qual
> sabemos
> > que ela passa, o que poderia servir de guia para os mapeadores.
> >
> > 4) Pareamento de quarteirões e faces de quarteirão do CNEFE e do OSM em
> > áreas já mapeadas. Supondo que o perímetro do setor seja conhecido
> > (shape-setor seja preciso) deve ser possível identificar qual quarteirão
> do
> > CNEFE corresponde a qual quarteirão do OSMs. Sendo assim seria possível
> > adicionar toda a estrutura de números de rua do CNEFE ao OSM.
> >
> > Enfim, estas são a idéias mais preliminares, espero que o email não tenha
> > ficado longo demais. Queria ver o que o pessoal acha delas e se alguém se
> > anima a ajudar. Tenho algumas idéias sobre algoritmos, etc para fazer
> estes
> > cruzamentos, mas não sei python, detalhes do OSM , etc para implementa
> tudo
> > num código na web.
> >
> > abraço
> > Lucas
> >
>
> > _______________________________________________
> > Talk-br mailing list
> > Talk-br em openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-br
> >
>
>
>
> --
> Fernando Trebien
> +55 (51) 9962-5409
>
> "Nullius in verba."
>
> _______________________________________________
> 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/20140402/a8c50f06/attachment-0001.html>
Mais detalhes sobre a lista de discussão Talk-br