subdominio viz de visualização de dados, resolucao de-para

[ppKrauss]

Analogo ao subdominio DL de downloads, viz.addressforall.org/{obj} permite a visualização do objeto obj.

PS: subdominio viz porque é a abreviação de Data VisualiZation, segundo a Wikipedia.

Ver planilha DE-PARA e VIZ-DE-PARA em https://docs.google.com/spreadsheets/d/1CL6f0I9DSpqKxKC7QNJGCfyabq7mDOVab5QBGV5VLOk

Sintaxe do obj

Conforme a planilha, temos {jurisdiction}/{package}.{version}/{layer} , a mesma hierarquia que utilizada pelo CutGeo (ex. )

Exemplos:

• BR-SP-Guarulhos/_pk0081.01/geoaddress
• BR-SP-Jacarei/_pk0145.01/parcel

Basta que o usuário digite um prefixo largo o suficiente para não ser ambíguo, que o redirecionador pode operar com a linha DE-PARA correta. Por exemplo BR-SP-Guarulhos, havendo um só layer e um só pacote, não precisa especificar.

Diferenças com serviçoDL:

• se por acaso digitar BR/pk0081 transforma em LIKE 'BR%pk0081% e novamente seria único.
• se por acaso digitar BR-SP-Guarulhos/via transforma em LIKE 'BR-SP-Guarulhos%via% e novamente seria único.

[ppKrauss]

A interface planilha precisa alimentar corretamente a planilha CSV de https://github.com/digital-guard/preserv/blob/main/data/viz/fromCutLayer_toVizLayer.csv

O CSV é que precisa ser atualizado no PostgreSQL para função análoga ao DL de redirecionamento.

PS: quando atualizar, incluir esse recurso no template de Readme

[0e1]

análoga ao DL de redirecionamento.

@ppKrauss por favor, defina nome e local no git para a de-para. Atualmente ele é consumida diretamente. Já aproveito para mudar e passar a consumir csv para o caso DL.

@crebollobr ou @ppKrauss por favor, fazer o necessário para tornar funcional o dominio viz.addressforall.org. Já criei o server block em config.nginx e já adicionei em /var/etc/nginx/sites-available/addressforall.org.

[0e1]

Em https://github.com/digital-guard/preserv/commit/232e235d590ccf1e51df85a861616dc52c437b71 inclui coluna para informar o sha256.ext do arquivo que originou a vizualização.

[ppKrauss]

Ok,

• fromCutLayer_toVizLayer.csv está resolvido... @0e1 eu não entendi como o software resolve o caso de mesmo file (hash) com múltiplos layers. Quando for o caso o usuário precisa expressar {hash}/{layer}, por exemplo 14431e2f20/geoaddress... e não pode dar erro no caso do layer ser redundante (um só layer por file).

• Falta @IgorEliezer e Luis atualizarem fromCutLayer_toVizLayer com o que acrescentaram, precisa entrar na rotina,

• Quanto aos downloads e pasta viz em preserv/data, reomear para preserv/data/redirs e incluir fromDL_toFileServer.csv (de-para dos downloads). Bom lembrar que CSVs e redir não deveriam estar no git

Testes: @e1 falta desenvolver e testar a função api.redirects_viz() e seu PHP.

• https://viz.addressforall.org/BR-SP-Guarulhos/_pk0081.01/geoaddress
• https://viz.addressforall.org/BR-SP-Guarulhos/geoaddress
• https://viz.addressforall.org/14431e2f20
• https://viz.addressforall.org/14431e2f20/geoaddress
• ...

[IgorEliezer]

Testes: @e1 falta desenvolver e testar a função api.redirects_viz() e seu PHP. {links}

Olha, só avisando. Tentei abrir os links no Chrome e no Firefox. Ambos estão dando, respectivamente, erro de certificado (SSL_ERROR_BAD_CERT_DOMAIN) e privacidade (NET::ERR_CERT_COMMON_NAME_INVALID).

Abrindo como http contorna o problema.

[crebollobr]

Os certificados foram criados. Já pode usar https

[0e1]

Testes: @e1 falta desenvolver e testar a função api.redirects_viz() e seu PHP.

Sim, faltam. Ainda não está pronto. Portanto, não gastem tempo testando. Solicitei apenas o subdomínio funcional.

• eu não entendi como o software resolve o caso de mesmo file (hash) com múltiplos layers.

Não precisa. layer <-> hash file viz é uma correspondência biunívoca. No entanto, se isso for desejado, é necessário desenvolver. Lembrar que hash nesse contexto (referido na coluna _hashfrom de _fromCutLayertoVizLayer.csv) é o sha256 do shapefile compactado com o zip, gerado a a partir dos dados ingestados. Não se trata do hash citado no make_conf.

• Quanto aos downloads e pasta viz em preserv/data, reomear para preserv/data/redirs e incluir fromDL_toFileServer.csv (de-para dos downloads).

Farei as adequações.

• Bom lembrar que CSVs e redir não deveriam estar no git

Então, daria pra deixar como está, consumindo direto do docs. E fazer o mesmo no caso de fromCutLayer_toVizLayer.csv. Pedi a definição do nome/local para o redirecionamento DL, por semelhança. Pois, se fromCutLayer_toVizLayer.csv está no git , fromDL_toFileServer.csv também poderia estar.

[0e1]

Não precisa. layer <-> hash file viz é uma correspondência biunívoca. No entanto, se isso for desejado, é necessário desenvolver. Lembrar que hash nesse contexto (referido na coluna _hashfrom de _fromCutLayertoVizLayer.csv) é o sha256 do shapefile compactado com o zip, gerado a a partir dos dados ingestados. Não se trata do hash citado no make_conf.

Esse trecho deve ser desconsiderado.

O _hashfrom em _fromCutLayertoVizLayer.csv é o respectivo sha256 citado no _makeconf.

• fromCutLayer_toVizLayer.csv está resolvido... @0e1 eu não entendi como o software resolve o caso de mesmo file (hash) com múltiplos layers. Quando for o caso o usuário precisa expressar {hash}/{layer}, por exemplo 14431e2f20/geoaddress... e não pode dar erro no caso do layer ser redundante (um só layer por file).

Apenas para deixar registrado que isso não havia sido dito na especificação inicial.

[0e1]

Recapitulando especificações:

Conforme a planilha, temos {jurisdiction}/{package}.{version}/{layer} , a mesma hierarquia que utilizada pelo CutGeo (ex. )

Exemplos:

* BR-SP-Guarulhos/_pk0081.01/geoaddress

* BR-SP-Jacarei/_pk0145.01/parcel

Basta que o usuário digite um prefixo largo o suficiente para não ser ambíguo, que o redirecionador pode operar com a linha DE-PARA correta. Por exemplo BR-SP-Guarulhos, havendo um só layer e um só pacote, não precisa especificar.

Diferenças com serviçoDL:

* se por acaso digitar `BR/pk0081`  transforma em `LIKE 'BR%pk0081%`  e novamente seria único.

* se por acaso digitar `BR-SP-Guarulhos/via`  transforma em `LIKE 'BR-SP-Guarulhos%via%`  e novamente seria único.

• caso de mesmo file (hash) com múltiplos layers. Quando for o caso o usuário precisa expressar {hash}/{layer}, por exemplo 14431e2f20/geoaddress... e não pode dar erro no caso do layer ser redundante (um só layer por file).

[0e1]

• Quanto aos downloads e pasta viz em preserv/data, reomear para preserv/data/redirs e incluir fromDL_toFileServer.csv (de-para dos downloads). Bom lembrar que CSVs e redir não deveriam estar no git

Alterações realizadas. Ambos redirecionadores consem csv em redirs.

Assim, a partir de agora deve-se atualizar fromDL_toFileServer.csv ao invés de de-para em se tratando de preservação digital (dl.digital-guard.org).

[0e1]

Link da página documentação: https://wiki.addressforall.org/doc/a4a:Conven%C3%A7%C3%B5es/Visualiza%C3%A7%C3%A3o_de_dados

Exemplos:

• https://viz.addressforall.org/BR-RN-Natal/_pk0073.01/block
• https://viz.addressforall.org/BR-RN-Natal/block
• https://viz.addressforall.org/63f265
• https://viz.addressforall.org/63f265/block
• https://viz.addressforall.org/63f265730d08e440bbfaf630a78c053968ee7ec12447b19af9554f5a8a78614f.zip
• https://viz.addressforall.org/63f265730d08e440bbfaf630a78c053968ee7ec12447b19af9554f5a8a78614f.zip/block

[0e1]

Inclui as definições na wiki https://wiki.addressforall.org/doc/a4a:Conven%C3%A7%C3%B5es/Visualiza%C3%A7%C3%A3o_de_dados