Revisando estrutura de donated_packcomponent

[ppKrauss]

Na tabela ingest.donated_packcomponent temos atualmente um erro:

• feature_asis_summary: deveria conter apenas sumarizações, em particular a "assinatura geohash" (hcode_signature_reduce) está ausente.

• feature_distrib: deveria conter a distribuição (hcode_distribution_reduce), mas está null.

A sugestão é já mudar o nome das colunas...

Tabela ingest.donated_packcomponent hoje:

Column	Type	Collation	Nullable	Default
id	bigint		not null	nextval('ingest.donated_packcomponent_id_seq'::regclass)
packvers_id	bigint		not null
ftid	smallint		not null
is_evidence	boolean			false
hash_md5	text		not null
proc_step	integer			1
file_meta	jsonb
hcode_distribution_parameters	jsonb
feature_asis_summary	jsonb
feature_distrib	jsonb

Proposta de nova estrutura ingest.donated_packcomponent hoje:

Column	Type	Collation	Nullable	comentário
id	bigint		not null	ok
packvers_id	bigint		not null	ok
ftid	smallint		not null	ok
is_evidence	boolean			ok
proc_step	integer			ok (precisamos retomar para controlar UPDATES aqui)
lineage	jsonb		not null	todas as informações originais e que não podem sofrer update. Inclui file_meta e signature
lineage_md5	text		not null	separado por conta da UNIQUE(packvers_id, ftid, hash_md5)
kx_profile	jsonb			todas as informacoes de cache, que podem ser regeneradas. Ver abaixo novos nomes.

[ppKrauss]

Nomes de chaves JSON:

• ghs_signature: contém o resultado final de hcode_signature_reduce().
• ... ghs_feature_distrib: contém o resultado final de hcode_distribution_reduce().. mas se vai ter dados do mosaico, precisa?
• ghs_distrib_mosaic: contém o resultado final de hcode_distribution_reduce() e a cada prefixo de geohash contem objeto com dados (aqueles hoje utilizados pelo mosaico).

A diferença de ghs_distrib_mosaic para ghs_feature_distrib é que no mosaico há o recorte de geometria.. Mas é justamente o que decidimos antecipar, já que podem haver geometrias excluídas por não estarem dentro da jurisdição.

Fica pendente a decisão de ghs_signature entrar na coluna lineage ou na coluna kx_profile... Por não afetar a linhagem (já tem o MD5 para dar integridade), sugiro em kx_profile.

Sobre ter ou não ter o input comum (por exemplo prefixos de gehashes com média de 5 dígitos) para as funções hcode_signature_reduce() e hcode_distribution_reduce(), se formos usar, chamar de ghs_pre_distrib.

[ppKrauss]

Mudança menor na tabela ingest.feature_asis,

Column	Type	Collation	Nullable	Comment
file_id	bigint		not null	ok
feature_id	integer		not null	ok
properties	jsonb			ok
kx_geom_ghs	text		not null	novo, Geohash-9 pontual
geom	geometry		not null	ok

[0e1]

Mudança em ingest.feature_asis implementada.

Exemlo de como ficou lineage:

{
  "file_meta": {
    "file": "/tmp/sandbox/_pkBR421_001/logradouros.shp",
    "size": 533156,
    "isdir": false,
    "access": "2022-01-28T21:09:46+00:00",
    "change": "2022-01-28T21:09:45+00:00",
    "creation": null,
    "modification": "2020-08-28T18:25:03+00:00"
  },
  "ghs_signature": {
    "6q": 1918,
    "6qpz": 1261
  },
  "ghs_distrib_mosaic": {
    "6": 440,
    "6qpxp": 874,
    "6qpxr": 2814,
    "6qpyc": 814,
    "6qpz0": 4677,
    "6qpz1": 2201,
    "6qpz2": 6652,
    "6qpz3": 2562,
    "6qpz8": 1118
  },
  "ghs_feature_distrib": {
    "6": 142,
    "6qpx": 476,
    "6qpz": 2561
  },
  "feature_asis_summary": {
    "n": 3179,
    "size": 1046,
    "n_unit": "segments",
    "bbox_km2": 240,
    "size_mdn": 0.21,
    "size_unit": "km"
  },
  "hcode_signature_parameters": {
    "p_heuristic": "1",
    "p_percentile": "0.75"
  },
  "hcode_distribution_parameters": {
    "p_heuristic": "2",
    "p_threshold": "500",
    "p_threshold_sum": "5000"
  },
  "hcode_distribution_parameters_publi": {
    "p_heuristic": "3",
    "p_threshold": "750",
    "p_threshold_sum": "8000"
  }
}

Reparar em:

• hcode_distribution_parameters: parametros para reduce no ato da ingestão.
• hcode_distribution_parameters_publi: parametros para reduce na publicação. Os valores desses parametros, exibidos no exemplo acima, são os valores default que já vinham sendo usados no processo de ingestão e publicação. A diferença entre os dois processos de reduce é o tamanho do geohash. No primeiro ghs9, e no segundo ghs7.

Já para hcode_signature_parameters os valores são os valores default da função hcode_signature_reduce, uma vez que essa função ainda não vinha sendo usada.

Essas três chaves obtem valores de hcode_parameters.csv

Depois de ajustar o cast de string para int, o processo de reduce signature ou distribution parece normal.

[ppKrauss]

ghs_distrib_mosaic

Não faz sentido e requer correções:

1. mosaic e distrib deveriam ser iguais (e portanto estaria redundante o uso de ambos). Ambos deveriam levar ao mesmo balanceamento de células...
2. se somar todos os valores, pois o total em feature_asis_summary é n=3179... Talvez seja ST_NPoints da issue #64
3. Cada célula do mosaico deveria ter (como no publicado) um conjunto key-value de propriedades da célula, não apenas um value.

Só falta corrigir o mosaico portanto. Se um dos objetos tinha a intenção de ser o "input comum" comentado acima, então seu nome precisa ser, conforme indicado, ghs_pre_distrib.

[0e1]

1. Ajustei e movi pra kx_profile. Exemplo: 1 | 7600004201301 | 31 | f | 4 | {"file_meta": {"file": "/tmp/sandbox/_pkBR421_001/logradouros.shp", "size": 533156, "isdir": false, "access": "2022-01-29T13:30:01+00:00", "change": "2022-01-29T13:29:59+00:00", "creation": null, "modification": "2020-08-28T18:25:03+00:00"}, "ghs_signature": {"6q": 1918, "6qpz": 1261}, "feature_asis_summary": {"n": 3179, "size": 1046, "n_unit": "segments", "bbox_km2": 240, "size_mdn": 0.210, "size_unit": "km"}, "hcode_signature_parameters": {"p_heuristic": "1", "p_percentile": "0.75"}, "hcode_distribution_parameters": {"p_heuristic": "3", "p_threshold": "750", "p_threshold_sum": "8000"}} | e0f6fe0bac0a48c1c0b9b1372af37299 | {"ghs_feature_distrib": {"6": 618, "6qpz": 2561}}

2. É valor da st_npoints. Depende se a função de recursão retorna o número de elementos nesse ponto https://github.com/digital-guard/preserv/blob/main/src/ingest-step1-ini.sql#L1229. Acho que sim.

3. É gerado no ato da publicação. Então, ghs_feature_distrib deve ser gerado pela any_load, no ato da ingestão (apenas com a quantidade de elementos) e sobreescrito durante a publicação (com as informações adicionais). Lembrar que na ingestão a distribuição é gerada utilizando ghs9 (obtido na ingestão) e quantidade de elementos. E na publicação a geração da distribuição começa com ghs7 (obtido do ghs9 + group by) e número de pontos por elemento (no caso de vias). Essas duas formas produzem a mesma distribuição?

[ppKrauss]

1. Ajustei e movi pra kx_profile.

Ok. Usando apenas ghs_feature_distrib e ghs_signature. Resta decidirmos se fica mosaico no lugar de distrib.]

2. É valor da st_npoints.

Ok, vai ser padronizado em função do tipo de geometria... Assim como n_unit muda.

3. É gerado no ato da publicação. Então, ghs_feature_distrib deve ser gerado pela any_load, no ato da ingestão (apenas com a quantidade de elementos) e sobreescrito durante a publicação (com as informações adicionais).

Pode ser... Quem controla o que foi feito é o proc_step, que atualmente termina em 4. Importante documentar o que é gerado em função do proc_step. Sobre inputs de ghs7 ou ghs9, como está mais fácil refazer tudo a partir do ghs da feature_asis, podemos decidir então gravar apenas os resultados finais relevantes: ghs_signature e ghs_mosaic. Outras distribuições não são de interesse.

---

Sugestão para ingest.feature_asis.ghs9 renomear para kx_ghs9 e declarar mais explicitamente a sua formação no CREATE com GENERATED ALWAYS AS f(geom) STORED, onde a função f seria padronizada na PubLib.

[0e1]

Nessa issue, resta implementar a contagem de elementos em cada geohash da distribuição gerarda por número de pontos em cada geometria. Consolidado em https://github.com/digital-guard/preserv/issues/69 e fechada issue.