a4a:Convenções/Dados: mudanças entre as edições
Sem resumo de edição |
Sem resumo de edição |
||
Linha 29: | Linha 29: | ||
[[Arquivo:A4a-UMLclass-addressEtc.png|centro|semmoldura|580px]] | [[Arquivo:A4a-UMLclass-addressEtc.png|centro|semmoldura|580px]] | ||
=== 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": | |||
[[Arquivo:A4A-geoTerm-UMLclass.png|centro|semmoldura|680px]] | |||
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. | |||
=== Vinculos com DG === | |||
Modelo do projeto [[DG]]: ver versão mais atualzada | Modelo do projeto [[DG]]: ver versão mais atualzada | ||
[[Arquivo:DG-UMLclass-v1.png|centro|semmoldura|580x580px]] | [[Arquivo:DG-UMLclass-v1.png|centro|semmoldura|580x580px]] |
Edição das 09h18min de 3 de novembro de 2023
![]() Documentação integrante do projeto AddresForAll |
Países: ... |
Os dados dos projetos 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:
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.
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.
Vinculos com DG
Modelo do projeto DG: ver versão mais atualzada