Este seria o mais ideal, usar algo que já existe do que criar algo do zero. E como o geocódigo do IBGE é gerado por vários níveis (região > estado > reg. intermediária > reg. imediata > município > distrito > subdistrito) que agrupam os setores censitários de forma hierárquica, sugeri a tag census_level.
A ideia original seria simplificar. Uma divisa de município é ao mesmo tempo uma divisa político-administrativa E uma divisa censitária do IBGE de nível 6*, então teria ambas as tags, admin_level=7 e census_level=6; então não precisaria de duas relações idênticas.
Já uma divisa de região intermediária é só divisa censitária do IBGE de nível 4*, então teria só census_level=4. Uma região metropolitana (e AU e MR) não é uma divisa censitária, é só uma subdivisão do Estado, então teria só a tag admin_level.
Uma consulta no overpass de todas as regiões imediatas do Brasil seria algo simples como:
[out:json][timeout:25];
{{geocodeArea:Brazil}}->.a;
(
rel[boundary][census_level=5](area.a);
);
out body;
>;
out skel qt;
Se quiser todos os municípios, troque para census_level=6
; distrito, census_level=7
; subdistrito, census_level=8
, e para setor censitário, census_level=9
.*
[ * – considerando que o país seria o nível 1 do censo IBGE. A não ser que queiram emparelhar o nível mais alto de admin_level
com census_level
em “2”, como eu sugeri no meu quadro. Se também quiserem subir o admin_level de município para 6, como na Colômbia, também fica bom, aí um admin_level não fica mais vago.]
Concluindo o meu raciocínio:
- Quando a divisa é criada por ente federado, o IBGE é somente uma usuária dela, por isso eu sugiro
boundary=administrative + admin_level=* + census_level=*
. Não vejo problema nisso, pois não é da competência do IBGE as divisas político-administrativas, pois o IBGE só as utiliza. Se um município ou estado é criado ou alterado, o IBGE segue. - Quando a divisa é criada pelo IBGE, é somente dela e é só censitária, não é político-administrativa, por isso sugiro
boundary=census + census_level=*
.