osm-codes/br_ibge_new

New Brazilian Hierarchical Grid

br_ibge_new's Issues

Modelo de dados e gestão interna da grade concreta

A grade abstrata é, tal como Geohash ou S2 geometry, composta apenas de funções de encode/decode e demais handlers do geocódigo. A grade concreta, tal como BR_IBGE, inclui o armazenamento de dados — por exemplo a densidade populacional, o percentual de área terreste, o percentual de área estrangeira, etc.

As decisões de projeto relativas à grade concreta podem depender de parâmetros de referência, tais como o tipo de sistema de dados (convencional tipo PostgreSQL ou Big Data tipo Hive), a disponibilidade de disco, e, principalmente, dos dados originais (vetoriais e não-vetoriais) que se pretende distribuir pela na grade.

Estas decisões. bem como critérios utilizados e modelo ou regras resultantes, precisam ser documentadas. Sugere-se primeiro discutir aqui depois documentar.

---

Principais decisões a discutir e formalizar:

1. Na sua distribuição aqui no git, adotar apenas dados básicos oficiais, tais como a população em 2010 e a população estimada em 2021, o território nacional e o mosaico municipal.

2. Os dados originais são apresentados ou como valor da célula (de grandeza preferenciamente intensiva), a exemplo da densidade populacional, ou como array de geometrias (por exemplo divisão administrativa, pontos de endereçoamento, rios, vias, etc.) e arrays correspondente de atributos padronizados.

3. A exportação/importação de dados é feita através de GeoJSON, de modo que os algoritmos e dados de apoio para o mapeamento array_geometrias/GeoJSON é parte do modelo.

4. Os layers de atributos são em número limitado, idealmente um bigint (presence) usando cada bit para representar a presença/ausência do layer e outro (original) usando cada bit para indicar se é a célula-folha da hierarquia que contém os dados brutos (de modo células-filha apenas calculam e não armazenam em cache os dados concretos).

5. Os dados originais de população fixados em células de resolução igual ou inferior à do IBGE, ou seja, 1KM é a mesma, e 125M para representar 200M_IBGE. Os demais dados originais, de pontos de endereçamento, de divisões administrativas, etc. em células maiores e relação espaço/processamento otimizada provavelmente nas células de 128KM. Um algoritmo otimizado para localização da célula-mão contendo os dados originais será importante para a otimização.

6. Pontos e polígonos aproximados também podem ser representados diretamente, ou seja, com a geometria do dado original fornecida pela célula ou conjunto de células. Pontos de endereço podem ser representandos por células da ordem de 3 a 5 metros de lado, enquanto a cobertura de um município por células de 5 a 500 quilômetros. Essa geometria grosseira pode ser suficiente para a maioria das aplicações, dispensando a representação vetorial nas tabelas indexadas por IDs de células da grade.

Atribuição de dados métricos à grade

Duas decisões importantes ao se trazerem dados de grades incompativeis (sem encaixe perfeito) e quanto à convenção de tipo de grandeza (forçando ou não o uso de grandeza intensiva).

1. Quando não há encaixe deve-se tomar a contribuição proporcional à área das células projetadas... Mas em casos de porção inválida (por exemplo população no mar ou em terra estrangeira) a proporcionalidade distorce e cria um falso espalhamento da grandeza. Células de fronteira podem "concentrar valores" sem propagá-los para vizinhas inválidas.

2. Quanto ao uso de grandezas intensivas na grade, que é o que faz mais sentido, há o problema da passagem do valor inteiro para real, e a questão de se ter ou não algoritmos otimizados para a sumarização. Se agrandeza precisa ser sempre multiplicada pela área da célula, o melhor é de fato armazenar como grandeza extensiva.

A questão de como lidar com células contendo duas ou mais fronteiras, bem como contendo porções inválidas, é discutida neste artigo, https://proceedings.esri.com/library/userconf/proc00/professional/papers/PAP552/p552.htm