Closed IgorEliezer closed 1 year ago
Olá @IgorEliezer , otima proposta! Vamos aguardar os demais darem um sinal de vida... Por hora apenas alguns adendos de minha parte:
do ponto de vista jurídico a doação de um patrimônio e a "contrato" de licença sobre uso e usufruto desse patrimônio, são relativos ao que o doador definiu, não o que nós (receptores) definimos. Não podemos adulterar o material fornecido. Ainda assim, tecnicamente, para o bom entendedor as operações de rename, zip e/ou unzip não adulteram arquivos digitais. Como receptores e curadores das obras doadas, temos o direito de desmembrar arquivos zip ou anexos de email em seus arquivos componentes.
O que importa, para garantir a integridade e rastreabilidade da obra doada, é o digest da função hash criptográfica (ex. SHA256) de cada arquivo (ou se decidirmos reunir similares num só zipadão).
já estamos montando o documento rascunho da Spec02-workflow, a norma técnica do Instituto AddressForAll que regerá (a partir da versão 1) o nosso workflow e as atribuições básicas de cada equipe.
podemos simplificar algumas coisas, o detalhamento da burocracia é importante todavia, até mesmo para ser documentado, pois servirá de subsídio na hora da automação, quando aumentar o volume de material e o número de prefeituras fornecendo dados. A burocracia, uma vez aprovada e testada conosco mais artesanalmente, terá a sua documentação efetivamente usada como requisito de software.
O desenho geral do workflow já podemos tomar como definitivo:
Até a publicação no UrbiGIS para efeitos de consulta pública, pelo que entendi, está tranquilo e todos em consenso. Uma vez pubicado no UrbiGIS o que a Equipe de Relacionamento faria é:
Solicita por email a licença/aceite do doador,
PS: já citando no email o número de bytes do arquivo doado, o seu hash (como referêcia jurídica do objeto doado) e o link para o UrbiGIS (como atestado visual do conteúdo doado).
Uma vez concedida a licença, já pode fazer as duas coisas indicadas no fluxo:
2.1. registro para a preservação digital de 20 anos; e 2.2. postagem no nosso PostGIS server online, para encaminhar à equipe de processamento e iniciar ingestão.
Resumidamente, já na direção de decidir um padrão de armazenamento, ao menos por hora:
0) O módulo básico do projeto são os municípios. Então tudo é organizado por municípios.
1) Cada município terá uma pasta BR-EE-NomeMunicipio
, onde EE
é a sigla do Estado e NomeMunicipio
é nome do município sem espaços, acentos e preposições.
2) Cada pasta de município teria as seguintes pastas:
3) O processo, usando como exemplo um material que possui conteúdo irrelevante e que precise de tratamento: um zip contendo um arquivo CAD, vários PDFs e PNGs.
Esta issue está ainda aberta. Fecha?
Fechando por inatividade/efeito esgotado.
Principais questões:
Para essa issue, considera-se:
(para demais termos, recomendo o artigo 4º da LAI)
Recepção
Até agora o meio predominante para a recepção de material é a caixa de e-mail.
O material chega de forma bem variada, geralmente em três situações:
O material é composto por conteúdo relevante e irrelevante para o nosso projeto.
Seleção
Aqui escolho o critério da relevância, isto é, aquilo que não é só essencial para a criação do banco de endereços, mas também material que possa servir como material auxiliar ou ser útil para o OpenStreetMap.
O critério de relevância é mais amplo do que o que é simplesmente essencial. Por exemplo, essencialmente nós precisamos só dos lotes e eixos das vias; os contornos de quadras não são essenciais mas podem servir de para distinguir qual face do lote está voltado para a rua.
Material que é servível para o OpenStreetMap e que não foge do nosso escopo pode ser considerado relevante. Exemplos: divisas de bairros e contornos de equipamentos públicos.
Material irrelevante será descartado.
Tratamento
Muitas vezes o material vem em formato que não é compatível com nossos processos, mas contém informações úteis. Este material então será submetido à conversão e adaptação, preservando as informações.
Em outras palavras: geramos um material intermediário, mas não geramos ou alteramos informações, só as tornamos "inteligíveis" para os nossos processos.
Preservação e autentificação SHA256 de material com perda da integridade/primariedade
Nos casos da "Situação 1" acima, na seleção teremos que deszipar o material recebido, descartar o material irrelevante, e o material relevante será processado e preservado.
Só o fato de deszipar e descartar o material irrelevante provoca a perda da integridade, pois não é mais exatamente o material como veio do fornecedor. Destaco que o material remanescente, i.e. relevante, é ainda autêntico, pois as informações são como vieram do fornecedor.
Então o que de fato estará sendo autenticado com chave SHA256: o material que o fornecedor nos envia ou o material relevante selecionado por nós?
A situação é mais drástica nos casos em que o material teve que ser convertido (hipoteticamente CAD ou PDF para CSV). O material intermediário é nosso, mesmo que as informações sejam autênticas.
Este assunto/issue precisa ainda ser melhor desenvolvido.