Open ppKrauss opened 1 year ago
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)
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)
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.
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))
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¶ms=12_28_45_S_013_29_15_E_type:airport
Conclusão:
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.
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
View materializada criada em https://github.com/digital-guard/preserv/commit/6c65d3bd235b4a90ca152dea58c1f59ddd00a87b.
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.