[Talk-br] RES: idéias dados IBGE >> OSM: CNEFE, setores censitários, quarteirões.
Lucas Ferreira Mation
lucasmation em gmail.com
Quinta Abril 3 12:34:13 UTC 2014
Ops, confundi os nomes.
Reinaldo: Você chegou a desenvolver algo para cruzar automaticamente estes
CNEFEs-normalizados com a lista de ruas do OSM?
2014-04-02 19:02 GMT-03:00 Lucas Ferreira Mation <lucasmation em gmail.com>:
> 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/20140403/d12199be/attachment-0001.html>
Mais detalhes sobre a lista de discussão Talk-br