Enquete: mapeamento das regiões estatísticas do IBGE

Communities Brasil (Brazil)
, , ,
1

Esta discussão foi iniciada em 2023 e aparentemente houve consenso, mas faltou definir alguns detalhes para viabilizar uma alteração efetiva no mapa. Estou reabrindo como enquete até 30/9 para tentar avançar nos pontos onde parece haver maior consenso.[1]

1. Qual valor de boundary deve ser usado para as Regiões Geográficas Intermediárias (RGInt) e Regiões Geográficas Imediatas (RGI), atualmente mapeadas como boundary=administrative com admin_level=5 e admin_level=7?
  • administrative (inalterado)
  • statistical
  • census
  • Outra opção (por favor explique nos comentários)
0 voters
2. Como tratar o admin_level existente nas RGI e RGInt?
  • Manter admin_level
  • Remover admin_level
  • Trocar admin_level por designation=RGI e designation=RGInt
  • Trocar admin_level por designation=Região Geográfica Imediata e designation=Região Geográfica Intermediária
  • Trocar admin_level por border_type=Região Geográfica Imediata e border_type=Região Geográfica Intermediária
  • Outra opção (por favor explique nos comentários)
0 voters
3. Qual valor de boundary deve ser usado para as regiões Norte, Nordeste, Centro-Oeste, Sudeste e Sul?
  • administrative (inalterado)
  • statistical
  • census
  • Outra opção (por favor explique nos comentários)
0 voters
4. Como tratar o admin_level=3 existente nas regiões Norte, Nordeste, Centro-Oeste, Sudeste e Sul?
  • Manter admin_level
  • Remover admin_level
  • Trocar admin_level por designation=Região
  • Trocar admin_level por border_type=Divisão Regional do Brasil
  • Outra opção (por favor explique nos comentários)
0 voters

@Nighto @matheusgomesms @Fidelis_Assis @IgorEliezer @fititnt @João_Gabriel_13 - reabrindo essa discussão da qual vocês participaram.

  1. Ainda ficam fora de escopo nesse momento as regiões metropolitanas, regiões integradas de desenvolvimento, subdistritos e outras regionalizações estaduais. ↩︎

1 Like
2

Sugestão:

1- Em vez de designation, usar border_type para identificar o tipo de região estatística.
Ex.
border_type=Divisão Regional do Brasil
border_type=Região Geográfica Imediata
border_type=Região Geográfica Intermediária
border_type=Região Metropolitana.

2- Lembro que, pela própria definição do IBGE, essas regiões são de natureza estatística e de planejamento, não administrativas.

2 Likes
3

Inclusive, o nome delas é utilizado em várias tipos diferentes de sistemas administrativos. Aqui onde eu moro, dependendo de qual órgão esteja utilizando o termo, os municípios de Santa Quitéria, Hidrolândia, Catunda e Quiterianópolis podem ser ou não parte da RGI de Crateús. Inclusive, a própria agência do IBGE não trabalha com SQ, Hidrolândia e Quiterianópolis nessa RGI.

1 Like
4

Adicionei a sugestão de border_type às perguntas 2 e 4. @João_Gabriel_13 @LucFreitas @Fidelis_Assis : caso queiram, podem alterar o seu voto livremente durante o período de votação.

5

Obrigado pelas sugestões, acho que podem fazer sentido para as divisões estatísticas do IBGE. Peço desculpas se o balão da nota de rodapé ficou meio escondido, mas apenas para esclarecer o escopo, as RMs ficaram fora desta enquete neste momento porque elas ainda me parecem uma questão em aberto no tópico anterior, e acho que merecem seu próprio tópico e enquete posterior. Em particular, o @IgorEliezer trouxe argumentos consistentes a favor de tratar as RMs como tendo caráter administrativo, e não meramente estatístico: elas são instituídas por leis estaduais com base no art. 25, §3º da Constituição, estão previstas no Estatuto da Metrópole, têm governança intermunicipal, plano diretor integrado observado pelos municípios, e poder de decisão sobre alocação de recursos, características que RGI, RGInt e as Grandes Regiões do IBGE não têm. (Eu também mencionei parte disso lá, ainda que bem mais tarde.)

1 Like
6

Verdade, as RMs, embora também usadas com fins estatísticos pelo IBGE, são definidas pelos estados com natureza administrativa. Para evitar que o Nominatim as inclua nos endereços, creio que podemos considerar a remoção da etiqueta admin_level e a inclusão de border_type=Região Metropolitana.

7

Votei em trocar admin_level por border_type. Se esta opção vencer, sugiro discutirmos antes da implementação se usamos valores propostos ou se adotamos os mesmos em snake case, por exemplo border_type=regiao_geografica_imediata, border_type=regiao_geografica_intermediaria e border_type=divisao_regional_do_brasil, sem acentos. O artigo sobre border_type recomenda snake case em inglês (ex.: immediate_geographic_region, intermediate_geographic_region, conforme a Wikipédia anglófona, e talvez algo como macroregion paras as 5 grandes regiões). Então também vale avaliar se seguimos a convenção global ou se documentamos uma exceção em português. De qualquer forma, snake case facilita a digitação, o processamento e a padronização internacional.

1 Like
8

Como ficou essa discussão mesmo?

9

A princípio deixei a votação aqui (sobre regiões imediatas, intermediárias e as 5 grandes regiões) programada para terminar dia 30/9 (fim desse mês). Podemos até encerrar antes se houver consenso sobre isso. Nesse momento, há um consenso forte na questão 1 e expressivo na questão 2. Já nas questões 3 e 4, o resultado está bem dividido. Abri um outro tópico específico pra discutir as regiões metropolitanas, sem enquete ainda.

10

Na verdade, o que é preciso é de uma forma de modelar os diferentes formatos de endereços em cada território, ou seja, quais componentes são usados, em que ordem, etc., e que o Nominatim e outros consumidores dos dados levem isso em consideração.

11

Acho que o Nominatim já oferece suporte a isso em algum grau. Este arquivo define a inclusão/exclusão de cada nível administrativo na linha do endereço. Ele foi modificado em abril deste ano removendo os níveis 5 (regiões intermediárias), 6 (regiões metropolitanas) e 7 (regiões imediatas) da linha do endereço no Brasil. Isso aconteceu aparentemente sem solicitação da comunidade brasileira, só com o objetivo de melhorar a velocidade do sistema. E de fato, esses níveis não constam mais nos endereços quando eu faço buscas no Nominatim. O nível 3 (relativo às questões 3 e 4 acima) ainda consta. Outros geocoders podem seguir trabalhando da forma anterior, não cheguei a verificar cada um. Mas o Nominatim não é mais uma razão prática para a alteração proposta aqui, a motivação é, em boa parte, semântica. A liberação do nível 7 pode ser útil para uma próxima etapa caso a comunidade concorde em deslocar os níveis 8 e 9 para cima para criar um espaço no nível 9 para representar os subdistritos - o que invariavelmente envolve um período em que os dados estarão incompatíveis com a configuração atual das ferramentas.

Fica a dúvida se a modelagem da formatação do endereço deveria ficar no código dos geocoders (mais estável, mas exige ação dos mantenedores) ou em dados mapeados no OSM (mais ágil, mas potencialmente mais frágil a eventuais erros involuntários ou até vandalismo, que nesse caso afetaria todos os consumidores). Talvez seria interessante levar isso para discussão com a comunidade internacional.

12

Quero agradecer a todos por toda consideração e menção. Para mim só removeria do boundary=administrative somente os limites que são exclusivamente do IBGE e moveria município para um level (ou dois levels) acima para dar espaço para haver distrito, subdistrito e bairro abaixo de município, pois são reconhecidos na Constituição Federal e Estadual, Decreto-Lei nº 311/1938 e Leis Territoriais estaduais.

E peço licença, estava me já desanimando: eu estava cutucando o assunto fazia um tempo! Escrever o post e pesquisar o embasamento leva tempo e parecia que ninguém ligava. Tanto que dei uma “pausa” no OSM, para voltar e…

… O QUE ACONTECEU COM A TRADUÇÃO PT-BR DO iD!!! panics :melting_face:

2 Likes
Tradução do editor iD pt-BR está em português de Portugal
13

O quê aconteceu? :frowning_with_open_mouth: Eu não uso o iD. Se tem algo errado, provavelmente o melhor seria criar um tópico específico.[1]

  1. Qualquer coisa sugiro usar/atualizar/corrigir essa referência de tradução pra tentar manter a consistência da terminologia técnica entre ferramentas diferentes. ↩︎

14

Aproveitando o resultado parcial da votação e tentando me antecipar, especificamente para a questão 2:

Nas RGI e RGInt, se houver consenso sobre alterar boundary=administrative para boundary=statistical com border_type=*, qual deve ser o formato do valor de border_type?
  • border_type=Região Geográfica Imediata e border_type=Região Geográfica Intermediária
  • border_type=regiao_geografica_imediata e border_type=regiao_geografica_intermediaria
  • border_type=immediate_geographic_region e border_type=intermediate_geographic_region
  • Outra opção (por favor explique nos comentários)
0 voters

@Fidelis_Assis @santamariense @João_Gabriel_13 @IgorEliezer @LucFreitas @KryFi

15

Eu preferiria usar valores para border_type exatamente como definidos oficialmente em português, ex. “Região Geográfica Intermediária”. Não vejo motivos para ficarmos presos hoje em dia a restrições antigas como não usar acentuação, maiúsculas, etc (Portugal padronizou o uso de algumas palavras em português para border_type). Entretanto, para seguir as regras explicitas na wiki, voto por usar snake_case e termos em inglês como recomendado.

16

Concoprdo com a ideia, é uma sugestão mais completa, mas também mais difícil de ser realizada. Noto que nem as mais simples têm avançado até a implementação.

18

@IgorEliezer Só pra avisar: jovandahiggs é bot, estava suspenso até ontem por “digitar rápido demais” logo após ter criado essa conta, tem zero changesets.

Temos tido outros bots no fórum. Eu reporto, mas eles continuam lá.

1 Like
23

Obrigado a todos os participantes.

Descontando os votos em “Outra opção (por favor explique nos comentários)” que não foram acompanhados de uma explicação nos comentários, há maioria clara a favor de representar as RGInts e RGIs usando boundary=statistical + border_type=*, sem admin_level=*. A segunda enquete, sobre os valores específicos de border_type=*, teve pouca participação, mas houve uma tendência ao uso de termos em inglês e snake case, conforme recomendado no wiki. Caso necessário, isso poderá ser rediscutido posteriormente.

O próximo passo, antes de uma alteração em escala nacional, seria fazer um teste simples em uma Região Geográfica Intermediária e em uma Região Geográfica Imediata e observar como os principais geocodificadores se comportam.

Sugiro usar como teste um restaurante em Passo Fundo (RS), com endereço representado apenas por addr:street e addr:housenumber, sem addr:city ou outras etiquetas de endereço redundantes. Primeiro registramos o comportamento atual das aplicações; depois alteramos as duas regiões e adicionamos um novo restaurante na mesma região, também com apenas as etiquetas de endereço mínimas. A partir daí, podemos acompanhar quando e como cada aplicação incorpora as alterações.

Escolhi este restaurante para teste. O comportamento que observei hoje, antes de qualquer alteração no mapa, foi o seguinte:

Nominatim (openstreetmap.org)

  • Buscas por “Domino’s Pizza, Passo Fundo, RS, Brasil” e “Rua Independência, 553, Passo Fundo, RS, Brasil”
    • Endereço exibido: “Domino’s Pizza, 553, Rua Independência, Centro, Passo Fundo, Rio Grande do Sul, Região Sul, 99070-060, Brasil”
  • Buscas por “Domino’s Pizza, Região Geográfica Imediata de Passo Fundo” e “Domino’s Pizza, Região Geográfica Intermediária de Passo Fundo”
    • Sem resultados
  • Ao mostrar o endereço nas coordenadas -28.262609, -52.405110
    • Endereço exibido: o mesmo anterior

Nominatim (nominatim.openstreetmap.org)

  • Buscas por “Domino’s Pizza, Passo Fundo, RS, Brasil” e “Rua Independência, 553, Passo Fundo, RS, Brasil”
    • Endereço exibido: “Domino’s Pizza, 553, Rua Independência, Centro, Passo Fundo, Rio Grande do Sul, South Region, 99070-060, Brazil”
  • Buscas por “Domino’s Pizza, Região Geográfica Imediata de Passo Fundo” e “Domino’s Pizza, Região Geográfica Intermediária de Passo Fundo”
    • Sem resultados

OsmAnd

  • A busca foi feita com o mapa posicionado em Passo Fundo porque não parece suportar os termos “Passo Fundo”, “RS”, “Região Geográfica Intermediária de Passo Fundo” nem “Região Geográfica Imediata de Passo Fundo”. Esses termos parecem ser ignorados caso o elemento do restaurante já tenha sido selecionado anteriormente.
  • Busca por “Domino’s Pizza, Rio Grande do Sul, Brasil”
    • Endereço exibido: “Rua Independência, 553, Centro”
  • Busca por “Rua Independência, 553, Rio Grande do Sul, Brasil”
    • Endereço exibido: o mesmo anterior
    • Em vez do restaurante, localiza o edifício que o contém, embora o edifício não tenha etiquetas de endereço
  • Ao clicar nas coordenadas -28.262609, -52.405110 (frente do edifício a leste)
    • Endereço exibido: o mesmo anterior

Organic Maps e CoMaps

  • Buscas por “Domino’s Pizza, Passo Fundo, Rio Grande do Sul, Brasil” e “Rua Independência, 553, Passo Fundo, Rio Grande do Sul, Brasil”
    • Endereço exibido: “Rua Independência, 553, Passo Fundo, Região Sul do Brasil, Brasil”
    • A busca não suporta os termos “RS”, “Região Geográfica Intermediária de Passo Fundo” nem “Região Geográfica Imediata de Passo Fundo”

Os próximos passos seriam:

  1. Alterar a Região Geográfica Intermediária de Passo Fundo e a Região Geográfica Imediata de Passo Fundo para boundary=statistical + border_type=intermediate_geographic_region / immediate_geographic_region, removendo admin_level=*.
  2. Adicionar um novo restaurante na mesma região, com as etiquetas de endereço mínimas. Estive recentemente no Pippo Cucina, então posso adicioná-lo.
  3. Acompanhar durante outubro quando o novo restaurante e as alterações nas regiões passarão a aparecer em cada aplicação, verificando em especial se há alguma outra alteração inesperada nos comportamentos já observados.

Sugestões de outros testes são bem-vindas. Neste primeiro momento, não me parece necessário fazer o mesmo teste em diversos pontos do país simultaneamente. Pode ser mais útil testar alguns tipos diferentes de elemento ou de endereço para verificar se o comportamento depende do tipo de objeto.

Se não houver problemas nessa transição, eu sugeriria então:

  • expandir a alteração para um estado inteiro; por mim, poderia ser o Rio Grande do Sul;
  • depois de um tempo sem relatos de problemas nas aplicações, expandir a alteração para o restante do país.
2 Likes