a4a:Convenções/Dados

Documentação integrante do projeto AddresForAll

Convenções Dados Gits

Países: ...

Os dados do projeto AddressForAll e seus "projetos irmãos" foram organizados conforme a visão do fluxo de dados mais geral:

Em termos de processo e valor agregado, podemos descrever os dados da seguinte forma:

• Preservados (bronze): os dados e licenças do projeto Digital‑Guard são rigorozamente controlados e preservados tal como os originais recebidos dos doadores. São os “dados brutos”, sem padronização e nos mais diversos formatos (CSV, Shapefile, Geojason etc.). Eles são preservados por 20 anos, e durante esse tempo podem ser baixados, tal como os recebemos.

• Filtrados (prata): por terem origem diversa, os dados Preservados precisam ser filtrados e padronizados. O projeto AddressForAll faz um recorte com foco nos endereços. A estrutura do recorte é padronizada e publicado em formato GeoJSON, através de PostgreSQL em repositórios git.
  Todo o processo de filtragem e publicação é aberto e reprodutível, qualquer um pode auditorá‑lo. Os resultados não sofrem validação, e um mesmo endereço pode ser descrito e repetido por diferentes fontes, tais como a prefeitura, a empresa de água e a empresa de logística.

• Consolidados (ouro): a consolidação consiste em agregar estatisticamente as informações das diversas fontes sobre um mesmo endereço e suas vizinhanças, e aplicar algoritmos de validação. No processo os endereços reconhecidos como duplicados são reduzidos a um só endereço, e os endereços inválidos descartados.
  Obtemos tanto o score de confiabilidade dos dados originais como a posição mais provável do ponto de endereço. Nomes de rua recebem padronização terminológica e a numeração predial pode ser otimizada através de médias, reposicionamentos ou interpolação. Esta base é a utilizada para nossas APIs de busca e geocodificação (em construção)..

Responsabilidades:

• Projeto Digital-guard: responsável por Preserved e Filtered.
• Projeto AddressForAll: define escopo "endereços" e linha de investimento no Digital-guard. Responsável por Consolidated do seu escopo.
• Projeto AFAcodes: define escopo "grades" (ex. população) e linha de investimento no Digital-guard. Responsável por Consolidated do seu escopo.

O armazenamento e processamento final dos dados, todavia, requer uma visão de arquitetura um pouco mais ampla, para dar conta também da sumarização e dos diferentes recursos de storage:

"stable" é uma tabela estável no servidor (de armazenamento quente), "tmp" é uma tabela temporária (para ETL), "ext" é uma tabela externa de armazenamento frio (preservação por ~20 anos). A seguir o modelo de dados centrado no projeto A4A.

Modelo de dados

Nem sempre os dados de lote estão disponíveis, e podem ser abstratos, sem geometria, como no caso dos vários endereços de um condomínio ou um mesmo shopping center.

Vinculos com DG

Modelo do projeto DG: ver versão mais atualzada

Módulo geoterm

resumo de a4a:Convenções/GeoTerm.

Diagrama de classes UML do SQL-schema TermStore, implementado como tabelas e visualizações, na verão "Model1":

A tabela Term é simples: cada termo, canônico ou não, é uma linha da tabela principal. Uma tabela secundária para namespaces, ns, divide os termos em grupos "base" (tema, corpus ou projeto) e seus grupos "auxiliares", para traduções (um namespace para cada idioma) e outros namespaces dependentes.