Protocolo geo muito lento

[ppKrauss]

Por exemplo https://osm.codes/geo:-22.9045,-47.07365 da ordem de meio minuto. Discutir aqui eventuais estratégias para otimizar.

Já foi comentada antes, em algum lugar, a indexação prévia dos países com geohash-bin de alguns bits, garantindo que células interiores dispensem análise de polígono e demais analisem apenas o trecho de interseção.

[0e1]

A função osmcode_encode não estava usando as funções contextualizadas. Ajustei isso. Agora retorna mais rápido, exemplo:

dl05t_main=# EXPLAIN ANALYZE SELECT api.osmcode_encode('geo:-22.9045,-47.07365');
                                     QUERY PLAN                                      
-------------------------------------------------------------------------------------
 Result  (cost=0.00..0.01 rows=1 width=32) (actual time=0.001..0.001 rows=1 loops=1)
 Planning Time: 1085.766 ms
 Execution Time: 0.014 ms
(3 rows)

[0e1]

Eu mudei a forma que a função decide o contexto, mais uma vez. Passei a usar o optim pra decidir o contexto e, então usar as funções contextualizadas da grade cientifica:

    SELECT api.osmcode_encode_scientific(uri,grid,isolabel_ext)
    FROM
    (
      SELECT isolabel_ext, geom
      FROM optim.jurisdiction_geom
      WHERE isolabel_ext IN ('BR','CO','UY','EC')

      UNION

      SELECT isolabel_ext, geom
      FROM optim.jurisdiction_eez
      WHERE isolabel_ext IN ('BR','CO','UY','EC')
    ) x
    WHERE ST_Contains(geom,ST_SetSRID(ST_MakePoint(latLon[2],latLon[1]),4326))

Com isso temos:

dl05s_main=# EXPLAIN ANALYZE SELECT api.osmcode_encode('geo:-22.9045,-47.07365');
                                     QUERY PLAN                                      
-------------------------------------------------------------------------------------
 Result  (cost=0.00..0.01 rows=1 width=32) (actual time=0.001..0.001 rows=1 loops=1)
 Planning Time: 16.789 ms
 Execution Time: 0.011 ms
(3 rows)

[0e1]

Decidir qual interface deve responder.

Atualmente, é a logística que exibi a célula. Mas, quem responde a requisição é a pilha de funções cientificas. Eu acho que a interface cientifica que deveria responder.

[ppKrauss]

Corrigir a busca por uma view materializada (mv) da união das geometrias de EEZ com country (já expandido pelo mar territorial), mas condicionado ao fato de existir cobertura (na Colômbia foi prevista a EEZ na cobertura e no Brasil não)

 SELECT api.osmcode_encode_scientific(uri,grid,isolabel_ext)
 FROM optim.mv_jurisdiction_eez_union
 WHERE isolabel_ext IN ('BR','CO','UY','EC') 
       AND ST_Contains(geom,ST_SetSRID(ST_MakePoint(latLon[2],latLon[1]),4326))

---

Sobre a melhor interface na busca por ponto aleatório

O OSMcodes tem abrangência mundial, e efetivamente resolve qualquer ID do OSM por redirecionamento, por exemplo em https://osm.codes/r13532396

Portanto bom lembrar: o escopo do domínio OSM.codes é o escopo do domínio OSM.org, que é o globo inteiro... Só não tem tudo implementando: a principal resposta da interface é ser amigável nos casos não-implementados.

Em termos de funcionalidades implementadas ou implementáveis, temos a proposta de "liberdade do usuário", muito parecida com o Geohack utilizado pela Wikipedia. Exemplo: https://geohack.toolforge.org/geohack.php?pagename=Catumbela_Airport&params=12_28_45_S_013_29_15_E_type:airport

Conclusão:

1. A interface ideal indica as opções, inclusive opção de mapa do geocódigo logístico ou científico.
2. Opções externas também precisam ainda ser implementadas. A decisão sobre quais, seria por curadoria da comunidade OSMcodes e reusando código do Geohack. Talvez 3 seções, nessa ordem: internos, externos abertos e externos proprietários. O link das buscas por CEP por exemplo estariam no último, e indicando um prefixo consistente com o ponto.
3. Países com resolução interna (BR, CO, etc.) possuem tratamento especial, mas isso é obtido no flag de retorno na query, pois com a nova funcionalidade, todos os demais países também estarão presentes (com geometrias simplificadas).

Quanto à performance, o grande gargalo serão as geometrias dos países: podemos otimizar por exemplo pelo sinal das coordenadas LatLong em 4 quadrantes globais, ou seja, recortando as geometrias dos países dentro desses 4 quadrantes (Geohash de 2 bits) para não sobrecarregar a busca.

PS: links para BING, PlusCodes e GoogleMap são importantes pois conferem comparabilidade dos geocódigos e/ou presença de endereços.

Sobre a interface por OSMcodes implementados

Usar as geometrias otimizadas para SVG (optim.jurisdiction_geom.geom_svg) para retornar mapas SVG das jurisdições-mãe durante a navegação por jurisdições (interface de mapa grosseiro SVG React acoplada ao seletor).

Ver https://github.com/osm-codes/gridMap-draftPages/issues/40

[0e1]

View materializada criada em https://github.com/digital-guard/preserv/commit/6c65d3bd235b4a90ca152dea58c1f59ddd00a87b.