Relatório CSV dos pacotes disponíveis no Download

[IgorEliezer]

Conversando com @ThierryAJean, vimos ainda a necessidade de ter um relatório/planilha que liste todos os pacotes disponíveis na página de Download para um usuário comum que não lida com GitHub, mas gostaria de ver uma lista completa para ter um panorama geral da situação.

Porém quero evitar criar outra planilha que teria que ser mantida sincronizada com as planilhas donor.csv e donatedPack.csv dos vários repositórios dos países no GitHub; ela seria gerada a partir dos dados que já estão na página Download, uma versão CSV da página HTML

Conterias colunas: jurisdição, doador, pacote, descrição do conteúdo, etiqueta da licença e link para a página README do pacote.

Este relatório seria gerado ou obtido de um link no topo da página de Download.

[0e1]

Crie a api.

Ver os links:

CSV: http://osm.codes/_sql.csv/pkindown JSON: http://osm.codes/_sql/pkindown

Comente aqui se precisar mudar nomes dos campos ou acrescentar/remover campos.

---

Notar que onde license for null o problema está no donatedPack.csv.

[IgorEliezer]

Muito bom, já dá um panorama do que temos. Vi que alguns precisam de licença e descrição.

Já vou passar para Thierry uma versão formatada para ele ver.

EDIT:

Ver minha resposta abaixo.

[ThierryAJean]

Estou conversando com o Igor e sugerimos adicionar o seguinte a esta planilha:

1. Uma frase de cabeçalho que explica o que tem na planilha:
   • "This table describes ingested data by the Digital-Guard project, maintained by the AddressForAll Institute"
2. Criar colunas com os diferentes tipos de dados que temos: block, nsvia, parcel, via, geoaddress
   • Para cada dado colocar yes para as colunas correspondentes aos pacotes com o dado.
3. No caso de haver endereços ou lotes, colocar o n de pontos + lotes numa coluna com titulo: Address Qty

[IgorEliezer]

Consolidei as sugestões minhas e de @ThierryAJean:

1. Colocar a data de geração no nome do arquivo: pkindown_2023-09-12_113400.csv
2. Adicionar 1ª linha como título, algo como "Filtered data packages - this table lists ingested data by the Digital-Guard project, maintained by the AddressForAll Institute"
3. Após a coluna description, adicionar uma coluna para cada data type de disponibilizamos (block, geoaddress, nsvia, parcel, via etc.), com valor yes ou no, para indicar se está disponível.
4. Após as colunas de disponibilidade, colocar uma coluna que mostra a contagem de objetos com endereços no pacote (Thierry sugeriu o label address_qty).
5. É possível adicionar, após a lista, notas explicativas dos lables das colunas?

Verificar viabilidade. Eu lembro que no futuro teremos um dashboard que vai detalhar numa interface melhor, então acho que não vale a pena carregar a planilha de muita formatação, notas etc. (i.e. itens 2 e 5).

[IgorEliezer]

@0e1 , gerei uma planilha para ver. A cidade BR-RS-Bage aparece na página de download, está nas planilhas donors.csv e package.csv, tem README e pacotes publicados, mas não parece na planilha pkindown. Ela não tem dados filtrados, é por isso?

[0e1]

@0e1 , gerei uma planilha para ver. A cidade BR-RS-Bage aparece na página de download, está nas planilhas donors.csv e package.csv, tem README e pacotes publicados, mas não parece na planilha pkindown. Ela não tem dados filtrados, é por isso?

Não é por isso.

1. aparecem em downloads os arquivos originais preservados;
2. foi feita a ingestão e commitados arquivos no CutGeo. Mas não foi concluída a publicação;
3. faltou executar os passos Copiar para datalake e Aprovação do nosso Workflow.

Se a cópia para o datalake e aprovação não são realizadas, não foi publicado. Vou tentar consertar isso.

[0e1]

Se a cópia para o datalake e aprovação não são realizadas, não foi publicado. Vou tentar consertar isso.

Conclui a publicação.

Verificar:

• https://github.com/digital-guard/preserv-BR/tree/main/data/RS/Bage/_pk0082.01
• https://addressforall.org/downloads/#BR-RS-Bage
• https://addressforall.org/visualization/
• https://addressforall.maps.arcgis.com/home/gallery.html?sortField=title&sortOrder=asc&searchTerm=Bag%C3%A9
• https://wiki.addressforall.org/doc/dg:Listagem_dos_downloads_por_jurisdi%C3%A7%C3%A3o
• https://wiki.addressforall.org/doc/dg:Listagem_dos_downloads_por_hash

[0e1]

Consolidei as sugestões minhas e de @ThierryAJean:

1. Colocar a data de geração no nome do arquivo: pkindown_2023-09-12_113400.csv

2. Adicionar 1ª linha como título, algo como "Filtered data packages - this table lists ingested data by the Digital-Guard project, maintained by the AddressForAll Institute"

3. Após a coluna `description`, adicionar uma coluna para cada data type de disponibilizamos (`block`, `geoaddress`, `nsvia`, `parcel`, `via` etc.), com valor `yes` ou `no`, para indicar se está disponível.

4. Após as colunas de disponibilidade, colocar uma coluna que mostra a contagem de objetos com endereços no pacote (Thierry sugeriu o label `address_qty`).

5. É possível adicionar, após a lista, notas explicativas dos _lables_ das colunas?

Verificar viabilidade. Eu lembro que no futuro teremos um dashboard que vai detalhar numa interface melhor, então acho que não vale a pena carregar a planilha de muita formatação, notas etc. (i.e. itens 2 e 5).

Estão na fila pra resolver.

[0e1]

@IgorEliezer

Para os itens 3 e 4 eu implementei uma alternativa. Avalie se não fica melhor (baixe o arquivo pra ver):

• adicionei uma coluna para cada data type depois de description;
• ao invés de yes ou no, adicionei a quantidade de elementos (se estiver em branco, o pacote não possui o respectivo layer). A quantidade de endereços seria obtida do valor na coluna geoaddress ou da coluna parcel ao invés da coluna _addressqty.

Concordo sobre os itens 2 e 5 (mas podem ser incluídos facilmente). O item 2 quebra a estrutura do arquivo (tabela em csv onde a primeira linha contem os rotulos das colunas).

Para o item 1 ainda não tenho uma solução simples. Porém, me parece que o comportamento correto da API e retornar sempre um arquivo com o mesmo nome, especialmente se ele será consumido automaticamente em algum momento. Uma alternativa para obter o csv com data seria usando o comando:

curl https://afa.codes/_sql.csv/pkindown > pkindown_$(date +"%Y-%m-%d").csv

[IgorEliezer]

Para o item 1 ainda não tenho uma solução simples.

Então fica postergado. O usuário pode simplesmente fazer o controle renomeando o arquivo localmente.

Para os itens 3 e 4 eu implementei uma alternativa. Avalie se não fica melhor (baixe o arquivo pra ver):

Ficou melhor. Onde for zero a gente considera que não tem.

[0e1]

Ficou melhor. Onde for zero a gente considera que não tem.

Não tinha notado valores zero. Mas tem.

Então, o entendimento correto seria:

• campo vazio significa que não foram doados dados daquele tipo de layer;
• campo com zero significa que foram doados dados daquele tipo de layer mas todos foram descartados na ingestão.

No fim das contas, em ambos os casos dá pra consideram que não tem.

[IgorEliezer]

Não tinha notado valores zero. Mas tem.

Ah, imprecisão minha. Quando falei zero, falei no sentido de vazio.

Agora se aparecer o valor "0", eu já consideraria que o arquivo existe mas está sem contagem ou sem objetos contados ou a tabela de dados do arquivo está vazia, como você sugere.

Será que é interessante colocar um "N/A" (not available) quando inexiste arquivo, ou é mais prático deixar vazio mesmo?

[ppKrauss]

@IgorEliezer o NULL tem suas ambiguidades conforme lembra a Wikipedia, e em geral isso se resolve com a "padronização local":

• do banco de dados (o nosso é PostgreSQL que tem por exemplo na concatenação comportamento diverso do Oracle)
• do usuário (empresa usuária e sua equipe) estabelece padrões.

Vamos então fechar as nossas padronizações na Wiki, usar o artigo "Convenções gerais SQL":

• NULL significa "informação não fornecida" (not available), mas opera de forma contaminante: numeros ou strings numa expressão com null ficam em null, conforme regras do PostgreSQL.
• String vazia (ex. em nomes e categorias) significa "informação não fornecida" (not available), mas não contamina, a concatenação por exemplo não é afetada.

[IgorEliezer]

Ver os links: CSV: http://osm.codes/_sql.csv/pkindown JSON: http://osm.codes/_sql/pkindown

Adicionei estes dois links no README raiz do projeto: https://github.com/digital-guard#logs-and-reports