Closed 0e1 closed 2 years ago
Decisão a tomar:
Sou mais favorável ao item 1, sem alterar o modelo de dados atual. A partição em multiplos arquivos, feita pelo fornecedor, é arbitrária, enquanto a jurisdição é fixa e já uma decisão tomada. Se por exemplo a prefeitura resolve fragmentar por bairro ou por urbano-rural, isso não deveria afetar a ingestão da jurisdição.
Ok, seguimos o item 1.
...
Duas situações envolvendo ingestão de múltiplos arquivos:
Até aqui os dois commits anteriores tratam a situação 1 usando as opções -p e -a de shp2pgsql, um dos arquivos é usado para criar a tabela e, na sequencia, os dados de todos os arquivos são carregados. A estrutura de cada arquivo deve ser igual.
No momento a ingestão de 1.a. está sendo feita, com a intenção de testar a ingestão e a publicação de, nesse caso, 1,6 milhão de dados.
2. Um sha256 com arquivos com nome disjuntos informados via array: a. BR/PR/Araucaria/_pk0061.01 b. BR/SC/Joinville/_pk0035.01
Sobre a situação 2:
Quandos os arquivos tem estruturas diferentes não podemos usar o sql_select
diretamente, uma vez que a any_load o usa internamente.
Então, eu acho que os sql_select
presentes no array precisam ser compatibilizados, possuindo a mesma quantidade de elementos e a posição de cada elemento, por exemplo da que corresponde a _housenumber, corresponder em cada array, para que seja possível gerar tabelas para cada arquivo, uni-las e então passar para a any_load.
Não vejo motivo para a compatibilização ser feita via software, acho que deve ser manual, diretamente no yaml.
Exemplo em 2.b de sql_select:
sql_select: [['gid', '___logradour', '___numero_25', '___bairro_28 AS ns_name', 'uso', 'geom'],['gid', 'iq_lote', 'geom']]
Observação: aqui estão as regras, quando foi implantada a possibilidade de usar array em sql_select
e orig_filename
: https://github.com/digital-guard/preserv-BR/issues/24#issuecomment-1010627483. Notar que entre as regras não está a que mencionei agora, mas acho que deveria.
Ingestão de múltiplos arquivos está funcional.
Resumo de como funciona: independentemente da situação _anyload é executada para cada arquivo. No entanto, o primeiro id gerado (na ingestão do primeiro arquivo) é reutilizado na a ingestão dos demais arquivos. Isso é feito passando como referencia o mesmo arquivo para todas as chamadas da _anyload, possibilitando recuperar o id a cada chamada da _anyload, subsequente a primeira chamada.
@ppKrauss Com isso a ingestão é feita de um em um, melhorando o uso dos recursos .
@crebollobr Você já pode testar e gerar as publicações de
Minhas recomendações:
Quanto à BR/PR/Araucaria/_pk0061.01 a ingestão depende da resolução de https://github.com/digital-guard/preserv/issues/102 . Como isso me parece estar relacionado a problemas nos dados e não a ingestão de múltiplos arquivos, fecho essa issue.
Conforme https://github.com/digital-guard/preserv-BR/issues/71#issuecomment-1091762131 ingestão e publicação de layers com múltiplos arquivos estão fora de compasso.
Tempos atrás, quando a ingestão de múltiplos arquivos por layer foi implantada, se decidiu por ingerir os arquivos separadamente. Em outras palavras, para cada arquivo é feita uma chamada da any_load, assim, para cada arquivo é gerado 1 id na tabela ingest.donated_packcomponent.
Por outro lado, a publicação espera 1 id por layer.
Resumo: Ingestão de múltiplos arquivos por layer:
Publicação:
Decisão a tomar: