osmc:Metodologia/Algoritmo SQL/Lib/Cpp: mudanças entre as edições

De Documentação
Sem resumo de edição
Sem resumo de edição
 
(21 revisões intermediárias por 2 usuários não estão sendo mostradas)
Linha 1: Linha 1:
aqui
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
**[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#L5348 wrap to c++]
* 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/postgis.sql.in#L5366 wrap to c++]
* decode CM: https://postgis.net/docs/ST_GeomFromGeoHash.html
**[https://github.com/postgis/postgis/blob/stable-3.4/postgis/postgis.sql.in#L5380 wrap to c++ box2d_from_geohash]
* decode CM: https://postgis.net/docs/ST_PointFromGeoHash.html
**[https://github.com/postgis/postgis/blob/stable-3.4/postgis/lwgeom_in_geohash.c#L103 point_from_geohash]
**[https://github.com/postgis/postgis/blob/stable-3.4/postgis/postgis.sql.in#L5373 wrap to c++]


natcod.hiddenBig_to_vBit
* natcod.hiddenBig_to_vBit
* natcod.vBit_to_hiddenBig
* grid_cm.cover_to_xy
* grid_cm.cover_to_xy
* 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
** 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


natcod.vBit_to_hiddenBig
PS: supor apenas células quadradas, caso retangular avaliamos numa segunda etapa (aparentemente não terá problema pois a topologia é a mesma - apenas rotaciona).
 
== Decisões de projeto pendentes ==
* Número de argumentos e complexidade das arrays: o que é mais rápido?<br/> 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 [https://github.com/madlib fontes] PostgreSQL para entender como paralelizar e declarar funções de alta performance
* [https://github.com/locationtech/geomesa/blob/main/geomesa-z3/src/main/scala/org/locationtech/geomesa/zorder/sfcurve/Z2.scala Curva-Z no GeoMesa]. Implementação em Scala, sugere uso das funções *Contains* e *Overlaps*.
 
== Ver também ==
....

Edição atual tal como às 18h40min 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):

PS: supor apenas células quadradas, caso retangular avaliamos numa segunda etapa (aparentemente não terá problema pois a topologia é a mesma - apenas rotaciona).

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

Lembretes

Ver também

....

Disponível em “https://wiki.addressforall.org/w/index.php?title=osmc:Metodologia/Algoritmo_SQL/Lib/Cpp&oldid=4404”