osmc:Metodologia/Algoritmo SQL/Lib/Cpp: mudanças entre as edições
< osmc:Metodologia | Algoritmo SQL | Lib
Sem resumo de edição |
Sem resumo de edição |
||
Linha 6: | Linha 6: | ||
* deinterleaveBitsEven | * deinterleaveBitsEven | ||
* neighbors_raw | * neighbors_raw | ||
Funções para estimar custo em horas, para copiar e colar template do PostGIS (para Afacodes CM): | Funções para estimar custo em horas, para copiar e colar template do PostGIS (para Afacodes CM): | ||
Linha 15: | Linha 11: | ||
**[https://github.com/postgis/postgis/blob/stable-3.4/postgis/lwgeom_functions_basic.c#L2911 lwgeom_in_geohash] | **[https://github.com/postgis/postgis/blob/stable-3.4/postgis/lwgeom_functions_basic.c#L2911 lwgeom_in_geohash] | ||
**[https://github.com/postgis/postgis/blob/stable-3.4/postgis/postgis.sql.in#L5361 wrap to c++] | **[https://github.com/postgis/postgis/blob/stable-3.4/postgis/postgis.sql.in#L5361 wrap to c++] | ||
* decode CM: https://postgis.net/docs/ST_Box2dFromGeoHash.html | * decode CM: https://postgis.net/docs/ST_Box2dFromGeoHash.html | ||
**[https://github.com/postgis/postgis/blob/stable-3.4/postgis/lwgeom_in_geohash.c#L77 box2d_from_geohash] | **[https://github.com/postgis/postgis/blob/stable-3.4/postgis/lwgeom_in_geohash.c#L77 box2d_from_geohash] | ||
**[https://github.com/postgis/postgis/blob/stable-3.4/postgis/postgis.sql.in#L5379 wrap to c++] | **[https://github.com/postgis/postgis/blob/stable-3.4/postgis/postgis.sql.in#L5379 wrap to c++] | ||
* decode CM: https://postgis.net/docs/ST_GeomFromGeoHash.html | * decode CM: https://postgis.net/docs/ST_GeomFromGeoHash.html | ||
**[https://github.com/postgis/postgis/blob/stable-3.4/postgis/postgis.sql.in#L5386 wrap to c++ box2d_from_geohash] | **[https://github.com/postgis/postgis/blob/stable-3.4/postgis/postgis.sql.in#L5386 wrap to c++ box2d_from_geohash] | ||
* decode CM: https://postgis.net/docs/ST_PointFromGeoHash.html | * decode CM: https://postgis.net/docs/ST_PointFromGeoHash.html | ||
**[https://github.com/postgis/postgis/blob/stable-3.4/postgis/lwgeom_in_geohash.c#L103 lwgeom_in_geohash] | **[https://github.com/postgis/postgis/blob/stable-3.4/postgis/lwgeom_in_geohash.c#L103 lwgeom_in_geohash] | ||
Linha 32: | Linha 25: | ||
natcod.hiddenBig_to_vBit | * natcod.hiddenBig_to_vBit | ||
* natcod.vBit_to_hiddenBig | |||
natcod.vBit_to_hiddenBig | * grid_cm.cover_to_xy | ||
* grid_cm.cover_to_xy | |||
* osmc.cell_relate (https://github.com/osm-codes/GGeohash/blob/main/src/step03def-lib.sql) | |||
* osmc.neighborsl0 | |||
grid_cm.cover_to_xy | * para as próximas, da uma olhada nas "oficiais" em https://wiki.addressforall.org/doc/osmc:Metodologia/Algoritmo_SQL/Lib#Construtor_do_identificador_cbits | ||
grid_cm.cover_to_xy | |||
osmc.cell_relate (https://github.com/osm-codes/GGeohash/blob/main/src/step03def-lib.sql) | |||
osmc.neighborsl0 | |||
osmc | |||
== Decisões de projeto pendentes == | == Decisões de projeto pendentes == |
Edição das 18h27min de 21 de agosto de 2024
Funções já feitas em https://github.com/osm-codes/NaturalCodes/blob/main/src-c:
- interleaveBits
- deinterleaveBits
- xy_to_cover
- deinterleaveBitsOdd
- deinterleaveBitsEven
- neighbors_raw
Funções para estimar custo em horas, para copiar e colar template do PostGIS (para Afacodes CM):
- encode CM: https://postgis.net/docs/ST_GeoHash.html
- decode CM: https://postgis.net/docs/ST_Box2dFromGeoHash.html
- decode CM: https://postgis.net/docs/ST_GeomFromGeoHash.html
- decode CM: https://postgis.net/docs/ST_PointFromGeoHash.html
Desafios: dado um ID de célula, retornar a array das vizinhas4 top/botton/left/right, https://en.wikipedia.org/wiki/Z-order_curve#Coordinate_values
PS: supor apenas células quadradas, caso retangular avaliamos numa segunda etapa (aparentemente não terá problema pois a topologia é a mesma - apenas rotaciona).
- natcod.hiddenBig_to_vBit
- natcod.vBit_to_hiddenBig
- grid_cm.cover_to_xy
- grid_cm.cover_to_xy
- osmc.cell_relate (https://github.com/osm-codes/GGeohash/blob/main/src/step03def-lib.sql)
- osmc.neighborsl0
- para as próximas, da uma olhada nas "oficiais" em https://wiki.addressforall.org/doc/osmc:Metodologia/Algoritmo_SQL/Lib#Construtor_do_identificador_cbits
Decisões de projeto pendentes
- Número de argumentos e complexidade das arrays: o que é mais rápido?
uma função f(x,y,z) ou uma função de array f(xyz_array)? Não só o código, mas o custo de chamar uma função com 1 argumento e com vários.- Para ser amigo do usuário final, basta criar "funções wrap", para sobrecarga nos diferentes estilo de passagem de argumento (por array ou por multiplos parametros).
- Empiricamente, mais rápido acessar diretamente os parâmetros. Tem um overhead ao acessar parâmetros indexados no array. Então, as funções utilizariam vários parâmetros e as wrap arrays.
- "IMMUTABLE" "STRICT", etc. o que precisa? em wrap para funções c++? ver em libs de alta performance (ex. MadLib) as boas práticas
- IMMUTABLE: sim. A princípio, todas as funções tratadas aqui retornam a mesma coisa para as mesmas entradas.
- STRINCT: sim, se caso um dos argumentos for null a função retornar null. Parece ser o caso das funções tratadas aqui.
- Usar em wrap de C++: sim. Exemplo: https://github.com/search?q=repo%3Amadlib%2Fmadlib%20immutable&type=code
- PARALLEL SAFE: sim
Lembretes
- https://madlib.apache.org/ e fontes PostgreSQL para entender como paralelizar e declarar funções de alta performance
- Curva-Z no GeoMesa. Implementação em Scala, sugere uso das funções *Contains* e *Overlaps*.
Ver também
....