read_statistical_grid(): células sem município atribuído são silenciosamente inacessíveis por consultas de município/estado

[pedreirajr]

Olá, pessoal!

Primeiro, parabéns pela v2.0.0. A mudança no read_statistical_grid() para aceitar code_muni foi transformadora para quem trabalha com a Grade Estatística. Até então, obter a grade de um município exigia identificar visualmente quais quadrantes de 500 km o cobriam, baixar os ZIPs do FTP do IBGE, ler os shapefiles, empilhar com rbind(), reprojetar e recortar com st_filter(). Agora é uma linha, e ainda com as duas edições (2010 e 2022) disponíveis e os nomes de campo padronizados. Para material didático, em particular, isso muda completamente o que é viável mostrar em sala.

Foi justamente ao migrar um material meu para a nova função que encontrei o ponto que quero reportar.

Contexto

Eu mantenho um tutorial de aula que faz comparação intercensitária com a Grade, usando Maceió como caso: seção 9.5 — Variação populacional entre Censos: o caso de Maceió. Ele baixava os quadrantes direto do FTP. Ao reescrever esse material para usar read_statistical_grid() da v2.0.0, os resultados da comparação mudaram, e a investigação levou ao comportamento abaixo.

O comportamento

Em R/statistical_grid.R, a atribuição municipal é feita por centroide (linhas ~158-187): ddbs_centroid() sobre as células, ddbs_join(join = "intersects") contra a malha municipal do ano correspondente (para a grade de 2010, a malha municipal de 2010), e o resultado volta por LEFT JOIN. Células cujo centroide não cai em nenhum polígono municipal ficam, corretamente, com code_muni = NA.

O efeito colateral aparece na leitura. O geobr:::filter_arrw() filtra por code_muni %in% code ou abbrev_state %in% code, e como NA %in% "AL" é FALSE, essas células não são retornadas por nenhuma consulta por município ou estado. Elas só existem para o usuário via code_muni = "all".

Na prática, isso são células sobre lagoas, baías e o mar, cujo centroide cai na água mas cujo quadrado cobre território municipal.

Números (grade do Censo 2010, quadrante ID_58)

Células da grade 2010 no shapefile do FTP (grade_id58.zip, censo_2010)	145.199
Dessas, com centroide fora de qualquer município (malha municipal 2010)	12.442 (8,6%)
Células da grade 2010 retornadas pelo geobr para AL, quadrante ID_58	57.202
Células da grade 2010 do FTP com centroide em município de AL (malha municipal 2010)	57.201

Ou seja, o conjunto entregue coincide quase exatamente com "células cujo centroide cai em município", com uma única divergência de borda. Nenhuma das 12.442 é recuperável.

Recortando para Maceió, usando o polígono municipal de 2010 como recorte em ambas as fontes:

• Grade 2010 do FTP: 6.607 células intersectando o município
• Grade 2010 via geobr: 6.456 células
• Ausentes: 151, e todas as 151 têm centroide fora de qualquer município do país (malha municipal 2010)
• Dessas 151, 142 têm POP = 0 na grade 2010, mas 9 têm população, somando 226 habitantes no Censo 2010

Exemplo reproduzível

library(geobr)

g10 <- read_statistical_grid(year = 2010, code_muni = 2704302)

# duas células de 1 km sobre a Lagoa Mundaú, presentes na grade do
# Censo 2010 no FTP (grade_id58.zip, censo_2010) com POP = 0
c("1KME6971N10194", "1KME6972N10194") %in% g10$id_unico
#> [1] FALSE FALSE

Essas duas em especial ilustram bem o efeito colateral analítico. No meu tutorial antigo, feito sobre os arquivos do FTP, elas apareciam como células de 1 km presentes na grade de 2010 e ausentes na de 2022, e eu as interpretei como caso de subdivisão por urbanização. Com a v2.0.0 elas simplesmente não existem na grade de 2010, e o diagnóstico da comparação intercensitária muda.

Por que acho que merece atenção

1. A contagem de células diverge da dos arquivos originais do IBGE sem nenhum aviso, o que é difícil de perceber para quem não faz a conferência contra o FTP.
2. O efeito não é simétrico entre edições, porque a malha municipal usada na atribuição difere entre a grade de 2010 (malha 2010) e a de 2022 (malha 2022). Isso introduz um resíduo assimétrico justamente em análises de variação intercensitária, que é um dos usos mais naturais da Grade.
3. A perda populacional é pequena, mas não é zero (226 habitantes só em Maceió, no Censo 2010).

Ambiente

R version 4.6.0 (2026-04-24 ucrt)
geobr 2.0.0
sf 1.1.1
Windows 11

Obrigado pelo trabalho no pacote, e à disposição para testar o que for útil.

[rafapereirabr]

oi @pedreirajr , obrigado pelo issue. O seu diagnóstico está correto, e ele aponta um problema que já conheciamos mas achávamos que não seria um problema critico.

A raiz desse problema é que na hora de definirmos o code_muni de cada celula, nós usamos o centroide das celuas, como voce observou. A gente escolheu essa abordagem porque tornaria a grade mais 'simples' com cada célula pertencendo a um único município. Uma alternativa seria usar uma função de interseção espacial tipo ddbs_join(join = "intersects") entre as geometrias das celulas e dos municipios. O problema é que nesse caso uma mesma célua poderia ter mais de um município e isso complicaria o processo de filtro com geobr:::filter_arrw(). Porque daí não poderíamos mais usar code_muni %in% code. Teria que ser algo como code_muni %like% code .

[pedreirajr]

Oi @rafapereirabr, obrigado pelo retorno!

Eu imaginei que a causa fosse essa das fronteiras mesmo. O que me deixou mais intrigado, entretanto, foi outro aspecto não relacionado à fronteira entre municípios, mas sim na costa Atlântica. Só para dar uma ideia na imagem, quando realizo esse processo puxando direto do FTP, conforme a seção 9.5 do tutorial que mencionei anteriormente, temos essa subdivisão da quadrículas de 1 km pra 200 m:

Com o procedimento da versão atual do geobr, entretanto, essas duas quadrículas de 1 KM de 2010 somem, ao mesmo tempo que aparece uma isolada de 200 m em 2022 (PS: o que está abaixo é de um tutorial novo usando a read_statistical_grid()):

Acho que é pelo mesmo motivo que você deu. Não imagino que precise mudar algo, até porque olhando com mais detalhe, esse local refere-se a um píer da Braskem que tem por lá:

Talvez seja algo pra refinar mais adiante, caso vocês julguem necessário.

Abs,