Segundo Dados Apurados No Censo 2010

Trabalhando com a base revisitada do IBGE

Quando você baixa os dados do Censo 2010 pelo Sidra ou pelo repositório oficial do IBGE, a primeira coisa que nota é que existem pelo menos duas versões da base. A versão inicial, aquela que sai na mão do censeiro e passa pela validação automática, e a versão revisitada, que recebe ajustes manuais pós-coleta. Eu já perdi uma tarde inteira comparando dois arquivos pensando que era um bug de join, quando na verdade um tinha vindo da base inicial e o outro da revisitação. A diferença entre eles costuma variar entre 0,3% e 2% nos fluxos agregados, dependendo da variável e da região.

segundo dados apurados no censo 2010

O que muitos não percebem de cara é que a revisitação não é apenas uma correção de erros de digitação. O IBGE reabre setores inteiros em municípios pequenos para recenseadores passarem novamente, especialmente nas regiões Norte e Nordeste, onde a dificuldade de acesso gera mais omissões. O resultado é que setores com 50 domicílios na base inicial podem terminar com 53 na revisitação. Se você está fazendo análise espacial ou cruzamento por setor censitário, usar a versão errada pode distorcer densidade populacional e indicadores socioeconômicos de forma silenciosa.

Aqui vai um problema concreto que eu encontrei: estava fazendo uma regressão com dados de rendimento domiciliar por setor no município de Boa Vista (RR). O R-quadrado não fechava, os coeficientes pareciam bizarras. Descobri que minha base original continha setores que foram substituídos na revisitação, e o código de setor (CODSECTOR) mudou em cerca de 8% dos casos. O workaround foi mapear as tabelas de equivalência que o IBGE disponibiliza no pacote dadosIBGE do R, ou então fazer o join manualmente usando o shapefile de setoriais atualizado. Leva uns 20 minutos no início, mas evita horas de depuração.

Como baixar a versão revisitada corretamente

No Sidra, o filtro mais importante não é o tópico — é o agrupamento em nível Setor Censitário. Se você selecionar apenas o município, o sistema entrega os totais agregados, que são os mesmos em ambas as versões. Para ver a diferença, precisa descer ao nível setor. O arquivo ZIP que você baixa tem três pastas: microdados, ambientes e setores. A pasta de microdados contém os arquivos Pessoal, Domicilios e Mostruario. Eles vêm em formato .csv com codificação Latin-1, não UTF-8. Abrir direto no Excel converte mal os acentos e corrompe campos string como nome de rua. A solução é importar pelo Power Query ou usar read.csv(file, fileEncoding = "latin1") no R.

O shapefile de setoriais (pasta setores) é o mais subestimado. Ele contém os geometria corrigida após a revisitação, com limites redrawn em áreas de difícil acesso. Se você faz qualquer coisa com GIS, use esse shapefile como base spatial, não os geometria de versões anteriores. Eu já vi gente usar a base de 2010 com geometria de 2000 porque achou que era a mesma coisa. O resultado são setoids sobrepostos e áreas fantasmas que aparecem nos mapas.

Armadilhas comuns que ninguém menciona

A tabela de metadados do IBGE (arquivo descricao_base.txt) muda entre lançamentos. Às vezes o IBGE renomeia colunas ou altera a escala de variáveis Likert sem avisar no changelog. Antes de confiar em qualquer cross-tabulation, leia o arquivo de documentação específico daquele módulo. Outro problema: o código de unidade da federação (UF) em alguns arquivos de microidados vem como número inteiro, em outros como string com leading zero. Um left_join cego quebra quando uma coluna é 11 e a outra é "11". Converter tudo para character antes de qualquer merge resolve em 90% dos casos.

A última dica prática: se você precisa de dados para municípios pequenos (população abaixo de 50 mil habitantes), espere variações maiores entre as versões. O IBGE prioriza a revisitação nessas áreas justamente porque a cobertura inicial tende a ser mais rasa. Se o seu estudo depende de precisão municipal, considere solicitar dados tabulados em nível municipal direto pelo SIDRA, que já vêm consolidados, em vez de fazer aggregation manual a partir dos microdados setoriais. A economia de tempo é real — o que levaria 45 minutos de limpeza de base vira 10 minutos de query pronta.