osmc:Convenções/Coberturas municipais/Algoritmos: mudanças entre as edições

De Documentação
(→‎Poeira: Especifica passos no tratamento de poeira.)
Linha 202: Linha 202:
Baseado no fator de precisão, duas estratégias são possíveis:
Baseado no fator de precisão, duas estratégias são possíveis:
# recortar os polígonos, de maneira análoga a um "snap to grid"
# recortar os polígonos, de maneira análoga a um "snap to grid"
## Cobrir município;
## Remover poeira;
### reindexar??
## Atualizar jurisdição do município;
### Criar chave em info para indicar que foi '''removida''' poeira e atualizada geometria
## Atualizar jurisdição dos municípios lindeiros:
### Absorver poeira do vizinho;
### Atualizar geometria das células de cobertura;
### Criar chave em info para indicar que foi '''absorvida''' poeira e atualizada geometria;
# ajustar o comportamento da interface nas bordas, quando à validade e detecção das judisdições.
# ajustar o comportamento da interface nas bordas, quando à validade e detecção das judisdições.


Para os eliminados:
# Remover células de cobertura
## reindexar??
# Não atualizar jurisdição
# Criar chave em info para indicar que foi removida poeira
   
   
[[Categoria:OSMcodes]]
[[Categoria:OSMcodes]]

Edição das 15h40min de 23 de maio de 2023

Resumo das conclusões

Dos estudos e evidências a seguir, concluíu-se para Brasil e Colômbia o seguinte:

  • xxx
  • yyy

CoberturaBase

Na verdade é um conjunto de regras heurísticas. Aplica-se à grade associada ao geocódigo logístico. Em geral a base32 em uso: vamos assumir a seguir apenas casos com base32, fica pendente o desenvolvimento similar para base16.

Objetivo:

  1. Minimizar tamanho do geocódigo cientifico da cobertura, minimizando o tamanho das células de cobertura-base.

Possibilidades, p=quantidade total de células na cobertura

  1. CoberturaBase com p=1; (dispensa indexação se nao houver demanda overlay)
  2. CoberturaBase com p>1;
  3. CoberturaBase + coberturaOverlay.

Limitantes:

  1. p <= 31;
  2. 32-p = q, onde 1 < q < 32. q é a reserva.
  3. LevelcoberturaBase - LevelcoberturaOverlay = 2.5

Casos:

  1. Municípios com uma célula (extraído de email): A heurística é a seguinte: se além de estar contido em uma célula dessas, o município tem área abaixo da mediana, então precisa usar a cobertura de uma célula. Nos demais casos há que se considerar área urbana para saber quanto de overlay resolveria ou não o problema dele. Heurística final: para ampliar o percentil de 50% (mediana) para 75%, deveríamos filtrar as geometrias com área grande (entre 40% e 75%) e elongation_factor grande.
  2. Sem perímetro urbano: cobertura base
    1. dado q, encontrar maior Level tal que 32-p>=q. Outra forma de pensar: se quero geocódigos de 5 dígitos, devo responder se p da cobetura-base de Level5792,6 satisfaz 32-p>=q. Aqui q codifica o entendimento de quantas reservas devem existir.
  3. Com perímetro urbano
    1. qual o valor de p da cobertura que resulta em códigos curtos do tamanho que defini? dado q, 32-p>=q? Se sim, usar a cobertura-base encontrada;
    2. Se 32-p<q, reduzir 1 digito na cobertura encontrada mantendo as células da cobertura anterior que interceptarem o perímetro urbano. A quantidade de células nessa nova cobertura satisfaz 32-p'>=q? Se sim, usar cobertura-base + overlay. Se não satisfaz, reduzir um digito da definição de 'curto' utilizada e repetir.

Algumas estatísticas sobre não indexação:

A consulta

SELECT *
FROM optim.jurisdiction
WHERE isolevel=3
     AND (info->'area_km2')::int <= 1
     AND (info->'area_km2')::int >  0;

não produz resultados em Brasil e Colômbia. Produz resultados no Uruguai. Porém, geometrias de jurisdições no Uruguai ainda não estão boas. Então, não foi testado se jurisdições cabem numa célula de 1km de lado. Que produziriam, sem indexação, geocódigos de tamanho 4.

Já a consulta

SELECT *
FROM optim.jurisdiction
WHERE isolevel=3
     AND (info->'area_km2')::int <= 36 -- lado 5.7km
     AND (info->'area_km2')::int >  0
     AND jurisd_base_id IN (76,170)

resulta em 51 municípios em Brasil e Colômbia.

No entanto, apenas 1 município cabe dentro de uma célula com lado 5.7km:

SELECT *
FROM (
    SELECT isolabel_ext,

            ST_ContainsProperly(ST_GeomFromGeoJSON(((CASE split_part(isolabel_ext,'-',1)
            WHEN 'BR' THEN osmc.encode_scientific_br(ST_Transform(ST_PointOnSurface(geom),952019),3000,0)
            WHEN 'CO' THEN osmc.encode_scientific_co(ST_Transform(ST_PointOnSurface(geom),  9377),3000,0)
            END)->'features')[0]->'geometry'),geom)
            
    FROM optim.vw01full_jurisdiction_geom
    WHERE isolevel=3
        AND (info->'area_km2')::int <= 36
        AND (info->'area_km2')::int >  0
        AND jurisd_base_id IN (76,170)
) r
WHERE st_containsproperly IS TRUE;
--     isolabel_ext      | st_containsproperly 
--  BR-MG-SantaCruzMinas | t
(1 row)

Avançando mais um pouco, considerando células de 32km de lado, a consulta

SELECT *
FROM
(
    SELECT isolabel_ext,
            ST_ContainsProperly(ST_GeomFromGeoJSON(((CASE split_part(isolabel_ext,'-',1)
            WHEN 'BR' THEN osmc.encode_scientific_br(ST_Transform(ST_PointOnSurface(geom),952019),19000,0)
            WHEN 'CO' THEN osmc.encode_scientific_co(ST_Transform(ST_PointOnSurface(geom),  9377),19000,0)
            END)->'features')[0]->'geometry'),geom) 
    FROM optim.vw01full_jurisdiction_geom
    WHERE isolevel=3
        AND (info->'area_km2')::int <= 1024
        AND (info->'area_km2')::int >  0
        AND jurisd_base_id IN (76,170)
) r
WHERE st_containsproperly IS TRUE;

Resulta que 603 municípios brasileiros e colombianos têm área que cabem dentro de uma célula de 32km de lado. Se não houver indexação os geocódigos resultantes teriam tamanho 6 em 1m. Aproximadamente, menos de 10% dos municípios. Evidente que esses municípios podem ser cobertos por células de 5,7km de lado com indexação, onde teríamos os mesmos 6 dígitos.

A consulta a seguir mostra que, de fato, 467 municípios estão dentro de uma célula com código de 3 dígitos na base 32nvu. Importante notar que foi compatibilizado as grades logísticas entre Brasil e Colômbia, implicando que geocódigos de mesmo tamanho equivalem a células de mesmo lado.

drop table lix; create table lix as  SELECT * FROM osmc.tmpvwcellContainsProperly;
select * from lix where length(cellcontainsproperly)>=3  order by 1;
...
 BR-MG-SantaCruzMinas           | C1J9
...
 BR-SP-TresFronteiras           | B3Z
 BR-SP-Tuiuti                   | FZS
 BR-SP-UniaoPaulista            | B96
 BR-SP-Uru                      | B8S
 BR-SP-Vargem                   | FZT
 BR-SP-VarzeaPaulista           | FZL
 BR-SP-VistaAlegreAlto          | B9N
 BR-SP-VitoriaBrasil            | B9B
 BR-TO-BuritiTocantins          | 6Y9
 CO-ANT-Envigado                | 6HR
 CO-ATL-Polonuevo               | F5J
 CO-BOY-Busbanza                | DDC
 CO-BOY-Caldas                  | D66
 CO-BOY-LaCapilla               | D3T
 CO-BOY-SantaSofia              | D6S
 CO-BOY-Sora                    | D6M
 CO-BOY-Tunungua                | D6D
 CO-CUN-Gachancipa              | D36
 CO-CUN-Granada                 | D0X
 CO-CUN-Quebradanegra           | D1W
 CO-RIS-Dosquebradas            | 6CN
 CO-SAN-Guapota                 | D7W
(467 rows)


Algumas estatísticas sobre cobertura-base com p próximo de 30 e geocódigos de 5 dígitos em 5.7m

Para em um município termos geocódigos de 5 dígitos em 5.7m, considerando indexação, a sua cobertura-base deve ser composta de células de 5.7km. Então a área do município deve ser menor que 1024km2. A consulta anterior mostra que 603 municípios em Brasil e Colômbia se encaixariam nessa situação.

Isso indica que a maneira de fornecer 5 dígitos em 5.7m em municípios com áreas maiores que 1024km2 é tendo uma cobertura-base com células de 32km de lado e uma cobertura-overlay com células de 5.7km de lado. Campinas é um exemplo dessa situação: https://osm.codes/BR-SP-Campinas. Ou seja, uma cobertura-base enxuta e a maior quantidade de overlays possível.


A tabela osmc.tmp_coverage_city possui cobertura geradas automaticamente e que possuem p<33. Notar que as cobertura comlobianas são anteriores a realização do shift na grade logística.

As consultas a seguir mostram que aproximadamente 1913 municípios brasileiros podem ser cobertos com coberturas de células de 5.7km de lado, tal que q>8, por exemplo http://osm.codes/BR-AL-BarraSantoAntonio. Se considerarmos q=2, 90% de 2551 podem ser cobertos com cobertura-base de 5.7km de lado.

-- número de municípios com cobertura-base com células de 5.7km de lado:
 SELECT COUNT (*)
FROM
(
    SELECT *, length(cover[1]) AS lgth_prefix
    FROM osmc.tmp_coverage_city
    WHERE unioncontainsproperly IS TRUE
) a
WHERE lgth_prefix = 4 and isolabel_ext like 'BR%';
-- count   2551

-- percentil 75 , 90 :
SELECT percentile_cont(0.75) within group (order by number_cells asc) as percentile_75,
       percentile_cont(0.90) within group (order by number_cells asc) as percentile_90
FROM
(
    SELECT *, length(cover[1]) AS lgth_prefix
    FROM osmc.tmp_coverage_city
    WHERE unioncontainsproperly IS TRUE
) a
WHERE lgth_prefix = 4 and isolabel_ext like 'BR%' order by 1;
 percentile_75 | percentile_90 
---------------+---------------
            25 |            30

Poeira

A consulta a seguir retorna as células de cobertura (base ou overlay) que possuem area menor que cem metros quadrados:

select round(st_area(geom)/10)*10 area_m2, count(*) n, round(avg(length(kx_prefix)),1) as prefix_len_avg from osmc.tmpvwpoeira group by 1;
-- 75 total
 area_m2 | n  | prefix_len_avg 
---------+----+----------------
       0 | 22 |            3.9
      10 |  6 |            3.8
      20 |  8 |            3.9
      30 |  9 |            3.9
      40 |  3 |            4.0
      50 |  3 |            4.0
      60 |  5 |            4.0
      70 | 12 |            3.9
      80 |  3 |            4.0
      90 |  2 |            3.5
     100 |  2 |            3.5

Pelo menos 22 podem ser eliminados. Para os restantes há que se estabelecer o critério de precisão, que resultada do produto de dois fatores: imprecisão técnica dos polígonos originais de jurisdição no OSM, e imprecisão legislativa no país de origem.

Baseado no fator de precisão, duas estratégias são possíveis:

  1. recortar os polígonos, de maneira análoga a um "snap to grid"
    1. Cobrir município;
    2. Remover poeira;
      1. reindexar??
    3. Atualizar jurisdição do município;
      1. Criar chave em info para indicar que foi removida poeira e atualizada geometria
    4. Atualizar jurisdição dos municípios lindeiros:
      1. Absorver poeira do vizinho;
      2. Atualizar geometria das células de cobertura;
      3. Criar chave em info para indicar que foi absorvida poeira e atualizada geometria;
  2. ajustar o comportamento da interface nas bordas, quando à validade e detecção das judisdições.


Para os eliminados:

  1. Remover células de cobertura
    1. reindexar??
  2. Não atualizar jurisdição
  3. Criar chave em info para indicar que foi removida poeira