Pessoal, tenho um incômodo pessoal com a forma como os boundary=administrative / admin_level=3,5,6,7 são usados no Brasil e escrevi uma proposta de correção, ainda em rascunho:
https://wiki.openstreetmap.org/wiki/Brazil/Proposta_de_Simplificação_de_fronteiras
Basicamente, para deixarmos de termos resultados de busca assim:
e que sejam assim:
Opiniões são muito bem-vindas.
[]s
Olhando de maneira rápida me parece bem, Arlindo! Eu só gostaria de ver como foi feita a discussão anterior de admin_level no Brasil, para termos uma noção dos argumentos usados à época. Além disso, interessante notar que boundary=statistical tem pouquíssimos usos, então teria de ser bem documentado seu uso no BR (e as etiquetas propostas)
Gostei, Arlindo, acho que ficou muito bom para início da discussão. Digo início pensando em fases futuras (ex. devemos abrir espaço para outras divisões administrativas sem nível próprio que estão hoje agrupadas em outros?) porque o que você abordou e da forma como o fez eu concordo completamente e penso que já poderia ser implementado após um pequeno debate e ouvirmos mais opiniões.para refinar detalhes.
Também estava trabalhando uma ideia de reforma da divisão político-administrativa
Os pontos principais seriam:
Divisas de uso do IBGE (admin_level = 5 e 6) deixariam de ser boundary=administrative e passariam a ser boundary=census (ou seriam deletadas, mas acho isso extremo, pois podem ser úteis para outras coisas);
Divisa de Região Metropolitana, Aglomeração Urbana e Microrregião passaria a ser admin_level = 6;
Divisa municipal passaria a ser admin_level = 7;
Divisa distrital passaria a ser admin_level = 8;
Adota divisa subdistrital em admin_level = 9;
Divisa de bairro continua em admin_level = 10;
Criação da etiqueta census_level = N para indicar o nível censitário da divisa.
Quanto ao item 1. Há um pressuposto em que divisas de um nível elevado é composta por divisas de níveis inferiores. (2 < 3 < 4 < 5 … 10), porém as divisas do IBGE, ao serem colocadas juntas às divisas político-administras, quebram o pressuposto. Por exemplo, as divisas do level 6 não são compostas de divisas do level 7.
As divisas do IBGE (level 5 e 6) não são divisas político-administrativa ou de uso geral, mas são de uso específico (censitário e estatístico dele), e os governos dos Estados não têm controle sobre estas divisas. Por sua vez, os Estados têm autonomia quanto a criação e modificação das suas RMs, AUs e MRs (level 7). Esta situação leva a casos esdrúxulos em que uma divisa level 6 ou 5 pega pedaços de uma ou mais divisas do level 7, ou uma divisa de level 7 fazer parte de diferentes divisas de level 6 e 5, como já descrevi aqui (notem a imagem anexa): Pergunta relativa a possível redundância - #9 by IgorEliezer.
A minha proposta levaria a;
Igor: gosto da sua ideia também, mas movendo Reg. Metropolitana / Aglom. Urbana / Microrregião também para a coluna censitária.
O fato de estados poderem criar regiões metropolitanas para fins de aproveitar oportunidades de integração entre os municípios etc. não os torna entidades administrativas distintas. (Aliás antes tivessem independência política para poder melhorar coisas como transporte intermunicipal de forma efetiva, mas essa é outra discussão.)
[]s
IgorEliezer, sua proposta está mais elaborada e traz pontos interessantes, só não me atrai a ideia de amarrar/misturar uma relação administrativa com uma estatística ao adicionar etiquetas. *_level à mesma relação. Creio que quem precisa usar as relações específicas do IBGE, após separadas como ‘statistical’, poderá perfeitamente usar também, adicionalmente, as administrativas com limites equivalentes se necessário - ou seja, quando coincidem, bastariam as administrativas.
Achei a sugestão do Arlindo mais interessante em relação às tags IBGE:. Entretanto, só sugestão, talvez a gente possa unificar as 4 etiquetas “IBGE:XXX=yes” sob uma mesma, “IBGE:CENSUS” (aproveitando seu ‘census’), com os 4 valores: “Região”, "Mesorregião’, “Região Metropolitana” e “Microrregião”.
O problema é que IBGE não usa as RM/AU/MRs na sua Divisão Territorial Brasileira e para gerar os geocódigos. Ao invés, prefere a Região Imediata, que em muitos casos, coincide com as RMs.
As RM/AU/MRs poderiam ser outro tipo de divisa, junto à RIDE, mas não saberia qual.
Talvez outro tipo de boundary que não administrative. Elas me passam a ideia de órgãos com poder político, decisório independente, legislativo, orçamento próprio etc. Ou ainda “o que vc escreve na carta” para fazer o endereçamento. O município estar dentro de uma região metropolitana etc. é irrelevante para 99% dos usuários.
[]s
Para mim as divisões político-administrativas (boundary=administrative) não se restringe à geração de endereços, mas à divisão territorial multifinalitária; é, em especial, para dar identidade e nome a parcelas do território diante da sociedade e do poder constituído para várias abordagens. Não são como comarca, consórcio regional, setor escolar, distrito policial, região hídrica, zona de uso de solo etc. pois são de finalidade limitada.
Se fôssemos por este critério, região, distrito, subdistrito e bairro não poderiam ser boundary=administrative.
Uma RM é unidade regional instituída pelos Estados por lei estadual (embasada em lei federal e pela Constituição). Possui câmara de governança interfederativa composta pelos municípios, decisão sobre alocação de recursos, plano diretor integrado (ao qual os municípios se adaptam), é multifinalitário, tais coisas não se veem em 99,9% nos distritos, subdistritos e bairros. Distritos e subdistritos são instituídos por lei e, no máximo, têm um subprefeito ou administrador regional, mas em muitos municípios ficam vagos. Bairros raramente são instituídos por lei e poucos possuem representação em conselheiros e orçamento participativo (quando há).
Certamente uma RM não é igual a um país, estado ou município, pois não é um ente federado. Tampouco o são região, distrito, subdistrito e bairro. E certamente não é uma área estatística como nos EUA.
A princípio, não sou contra à ideia de que RM deixe de ser boundary=administrative, mas não pelo critério de endereçamento. Na verdade, estou bastante relutante, pois a RM possui até muita relevância, como descrevi; talvez não o é para boa parte das pessoas. Para mim, censo comum nunca foi uma boa conselheira.
EDIT:
RMs mapeadas no OSM no mundo: overpass turbo (pode estar impreciso)
Creio que a questão do endereçamento é a parte visível e que incomoda quando lista como parte do endereço vários limites que não interessam à maioria. Então, renomear os limites que não interessam como endereçamento parece ser uma boa medida. Outra opção que imagino, mais complicada de se implementar porque impactaria até em como o Nominatim funciona, seria criar limites específicos para endereçamento, ou simplesmente acrescentar uma tag nos limites administrativos informando se valem ou não para endereçamento, Mesmo a solução mais simples - acrescentar tag -, impactaria o nominatim. Acho bem mais complicado conseguir uma alteração lá.
Então, sendo prático, uma primeira fase das alterações poderia ser simplesmente renomear os limites que não interessam ao endereçamento na linha do que foi proposto pelo Arlindo e adiar as discussões de outros aspectos. Isso teria impacto apenas local e nos limites 3, 5, 6 e 7. Os aplicativos que lidam com os níveis administrativos para endereçamento não seriam afetados, apenas a página da wiki sobre boundary=administrative precisaria ser atualizada para eliminar os 3, 5, 6 e 7, que seriam descritos em outra. Não sei de apps que usam os limites 3, 5, 6 e 7. Se houver, precisariam de revisão.
Fiz alguns testes com variantes das tags a serem usadas e achei mais interessante a seguinte:
Então, um limite estatístico específico do IBGE seria indicado por type=boundary + boundary=IBGE:CENSUS + IBGE:CENSUS=nome do limite
Deixei um .osm como exemplo de como fiocaria depois dessas alterações para o RJ:
Descomprimir e abrir no JOSM. Apenas para visualização e verificação. Não subir para o OSM.
Comentário rápido: por que não usar boundary=census? A descrição do https://wiki.openstreetmap.org/wiki/Tag%3Aboundary%3Dcensus é bem semelhante (inclusive o problema inicial de que pessoas quiseram deletar logo depois de importado) nos EUA.
Uma tag principal (isto é, nem é secundária, mas principal) como boundary=IBGE:CENSUS dificilmente seria suportada por aplicações. A boundary=census pelo menos dá uma dica forte do que significa.
Ops, esqueci da boundary=statistical https://wiki.openstreetmap.org/wiki/Tag%3Aboundary%3Dstatistical que ja foi sugerida.
De qualquer forma, criar uma tag principal nova, ainda mais super específica de um país, dificilmente será implementada. Mesmo uma pouco usada é melhor do que criar uma nova.
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:
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.boundary=census + census_level=*.Pode ser ‘census’ ou 'IBGE:CENSUS", tanto faz. Tirei o nome da americana mesmo, só prefixei com IBGE para indicar que não é a mesma.
Sobre maior ou menor facilidade para se usar uma tag nova, não vejo nenhum problema nesse caso já que seu uso será bem restrito - apenas que está interessado nesses limites. Quem?
Se você limitar as consultas dentro do território brasileiro (como indiquei na consulta acima), dispensaria o prefixo. Da mesma forma não precisamos de BR:admin_level para diferenciar o nosso admin_level do admin_level dos outros países.
Uma vez que o IBGE publica dados do Censo e do CNEFE agregados por nível censitário, suponho que haveria pesquisadores e usuários destes dados e queiram visualizá-los no mapa. Assim como o próprio IBGE usa as divisas do OSM no site deles, o INDE (https://visualizador.inde.gov.br/).
Faça um teste, pesquise por qualquer Região Intermediária ou Imediata, que vai aparecer na interface.
Outra ideia,
No meu modo de ver, o nome do limite (Região, Mesorregião… etc) como valor da ‘IBGE:CENSUS’ ou ‘census’ deixa mais claro, em vez de census_level com um número. Sim, admin_level usa números mas precisa ser assim, genérico, para atender todos os países e o significado do número varia para cada país. Um limite estatístico que só faz sentido no Brasil e já tem nome, não precisa usar uma identificação mais obscura.
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;
Creio que assim também ficaria simples, mais clara e com menos chance de se errar no número associado ao limite desejado:
[out:json][timeout:25];
{{geocodeArea:Brazil}}->.a;
(
rel[boundary]['census'~'Região Geográfica Imediata'](area.a);
);
out body;
>;
out skel qt;
Se você limitar as consultas dentro do território brasileiro (como indiquei na consulta acima), dispensaria o prefixo. Da mesma forma não precisamos de BR:admin_level para diferenciar o nosso admin_level do admin_level dos outros países.
Não me referi a esse tipo de diferenciação/limitação, mas pensando no algoritmo que poderia tratar esses ‘census’. Certamente os limites ‘census’ do Brasil e dos EUA têm certas características diferentes que precisam de algum tratamento mais específico. Ao ver a tag ‘census’ já seria chamada uma rotina para tratamento do caso americano, já se for ‘IBGE:CENSUS’ seria chamada uma outra apropriada para o Brasil.
Do ponto de vista de desenvolvimento de APIs e softwares, usar uma string que não seja para filtrar nomes, acho isso bem frágil. Fora que não deixa claro qual é o nível dela para quem lê um código-fonte.
census_level=5 é explícito, mostra: 1) é sobre censo; 2) é um nível (do censo); 3) e qual nível na hierarquia (do censo). Nem precisa olhar o manual do IBGE.
Já census~Região Geográfica Imediata força a filtragem pelo nome e se utiliza de uma redundância (pode haver erro de digitação)
boundary=census
IBGE:census=Região Geográfica Imediata
name=Região Geográfica Imediata de Sorocaba
ou então para evitar redundância, seria preferível:
boundary=census
IBGE:census=Região Geográfica Imediata
name=Sorocaba
Aqui vejo vantagem. Só haveria o problema de retornar numa pesquisa sobre “Sorocaba”, mais Sorocabas que o habitual: Sorocaba (região intermediária), Sorocaba (região imediata) e Sorocaba (município). A princípio não é um problema, pois já temos Sorocaba (distrito) e Sorocaba (município).
Do ponto de vista de desenvolvimento de APIs e softwares, usar uma string que não seja para filtrar nomes, acho isso bem frágil.
Não sei porque você tem essa impressão mas não há razão para se falar em fragilidade, é só impressão. Em especial quando se trata de OSM. Um arquivo OSM é na verdade um arquivo XML onde só existe string. Tudo lá é string desde a representação dos elementos básicos (nós, caminhos e relações) até os pares chave, valor (até mesmo os dados com interpretação natural numérica - coordenadas, velocidade, peso, data e hora, etc) nos metadados (atributos) e nos dados (tags e valores). Assim, o parsing de um arquivo .osm é fundamentalmente um processamento de strings com comparações e filtragens baseadas tanto nas chaves como nos valores. Ou seja, todo o OSM depende fundamentalmente de strings.
Não estou dizendo isso apenas teoricamente, lido com parsing de OSM (XML) há anos, seja com parser de terceiros ou com o meu próprio. O parsing do XML e a estruturação dos dados são básicos para geração de mapas, para extração de alertas, para verificação de qualidade (relações quebradas, ausência de dados, dados incoerentes) e correção/atualização (edição automática do XML) como nos casos recentes que fiz de limites estaduais e municipais, atualização de dados populacionais, reclassificação dos places e atualização/inclusão dos IBGE:GEOCODIGO. Tudo é feito basicamente com comparação e filtragem baseada em strings.
Já
census~Região Geográfica Imediataforça a filtragem pelo nome e se utiliza de uma redundância (pode haver erro de digitação)
Erro de digitação sempre pode haver, mas em um nome é mais fácil de ser percebido e corrigido por qualquer pessoa do que em um número.
ou então para evitar redundância, seria preferível:
boundary=census IBGE:census=Região Geográfica Imediata name=Sorocaba
Sim, poderia ser assim. Quando usei o próprio valor “IBGE:CENSUS” como uma tag de hierarquia inferior cujo valor seria o nome da região, a ideia foi eliminar uma tag, essa do nome em seguida que você sugeriu. A ideia é semelhante ao nome de uma rua, onde colocamos o tipo da via (Rua, Avenida, Travessa, etc) no próprio nome e não numa tag adicional, o que também seria uma solução embora mais espaçosa. Nota: se você precisar importar dados do OSM para um banco de dados, para processamentos bem mais pesados, pode ser interessante quebrar em 2 campos, tipo da via + nome, mas de modo geral isso não é necessário.
No caso de vias, a filtragem pelo tipo já é feita assim, pelo nome. Ex. se quisermos filtrar todas as “Travessas” temos de filtrar pelo nome, mais especificamente pela parte inicial do nome.
Além do código numérico, seu comentário sobre uma forma de descrever o que o código numérico significa me lembrou isso aqui
https://wiki.openstreetmap.org/wiki/Key:border_type
Não digo exatamente essa key, mas uma key (como em key=value) que ao menos em teoria não seja exclusiva do Brasil é interessante. O valor dela, descritivo do que o nível numérico significa, obviamente continua sendo local.