a4a:Convenções/Dados
 Documentação integrante do projeto AddresForAll |
| 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.
Todos os projetos seguem as convenções gerais SQL do Instituto, baseadas em versões modernas de PostgreSQL e PostGIS.
Modelo de dados
- Tabelas documentadas em a4a:Convenções/Dados/SQL.
O projeto A4A tem como principal produto os dados consolidados, de modo que fica mais evidente as demandas em dados filtrados a partir dos consolidados. A principal entidade da modelagem de um endereço é o lote, aqui representado pela classe abstrata Lot (também conhecido como "parcela"). Apenas países e locais com maior maturidade digital oferecem polígonos e relacionamentos dos lotes, por isso Lot é uma classe abstrata e LandLot não é uma entidade obrigatório.
Um lote típico será associado a um endereço pontual (classe Address com seu DoorPoint quando fornecido), podendo haver mais de um. Por exemplo endereço principal e entrada de serviço, ou endereço separado para medição de água e luz, etc. No caso de parques, condomínios, fábricas e shoppings são usuais os múltiplos endereços.
Endereços, anda hoje na grande maioria dos países, são oficialmente fixados a partir de um identificador público (com placas) de um objeto maior, via ou quadra, e sua localização dentro desse objeto maior, conhecida como "número de porta" (house number). A posição precisa como ponto geográfico (classe DoorPoint) não é obrigatório, mas é o objetivo maior do projeto AddressForAll.
A noção de município, trazida pela classe City, é estabelecida pelo nível jurisdicional que garante algumas propriedades:
- é um namespace dentro do qual os nomes de via não se repetem;
- é a menor jurisdição com algum controle (autonomia) sobre os atributos do endereço: batiza os nomes de rua e controla a numeração predial oficial (por exemplo marco-zero de cada via). Eventualmente será autonomia também para alterar a recomendação nacional, como no Brasil onde há a liberdade, no município, de adotar outros sistemas de nomenclatura de via e sistemas de numeração de porta.
As Vias, assim como no OpenStreetMap, são necessariamente truncadas pelas bordas do município. Por isso basta o relacionamento Via-City, ficando a consistência com a relação Point-City a cargo da validação espacial.
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.
Tipos de layer
- resumo de dg:AsIs feature types
Ver ftid ...
Diagramas
... ver sup:Figs/UML onde concentrando docs das figs. Padrao: