a4a:Convenções/Dados: mudanças entre as edições
Sem resumo de edição |
m (→Diagramas) |
||
| (8 revisões intermediárias pelo mesmo usuário não estão sendo mostradas) | |||
| Linha 1: | Linha 1: | ||
{{A4a info}} | {{A4a info}} | ||
Os dados do projeto AddressForAll e seus "projetos irmãos" foram organizados conforme a visão do fluxo de dados mais geral: | |||
Os dados | |||
[[Arquivo:Fig.u2.en.png|centro|580px|semmoldura]] | [[Arquivo:Fig.u2.en.png|centro|580px|semmoldura]] | ||
| Linha 7: | Linha 6: | ||
Em termos de processo e valor agregado, podemos descrever os dados da seguinte forma: | 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. | * '''Preservados''' (''bronze''): os dados e licenças do [[DG|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 | * '''Filtrados''' (''prata''): por terem origem diversa, os dados Preservados precisam ser filtrados e padronizados. O [[A4A|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.<br/> 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. <br/> 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).. | * '''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. <br/> 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: | Responsabilidades: | ||
* [[DG|Projeto Digital-guard]]: responsável por '''Preserved''' e '''Filtered'''. | |||
* Projeto Digital-guard: responsável por '''Preserved''' e '''Filtered'''. | * [[A4A|Projeto AddressForAll]]: define escopo "endereços" e linha de investimento no Digital-guard. Responsável por '''Consolidated''' do seu escopo. | ||
* Projeto AddressForAll: define escopo "endereços" e linha de investimento no Digital-guard. Responsável por '''Consolidated''' do seu escopo. | * [[OSMC|Projeto AFAcodes]]: define escopo "grades" (ex. população) 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'': | 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'': | ||
| Linha 23: | Linha 21: | ||
[[Arquivo:Fig.u3.en.png|centro|800px|semmoldura]] | [[Arquivo:Fig.u3.en.png|centro|800px|semmoldura]] | ||
A seguir o modelo de dados centrado no projeto A4A. | "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== | ==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. | :<small>Tabelas documentadas em [[a4a:Convenções/Dados/SQL]].</small> | ||
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. | |||
<!-- 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.--> | |||
[[Arquivo:A4a-UMLclass-addressEtc.png|centro|semmoldura|580px]] | [[Arquivo:A4a-UMLclass-addressEtc.png|centro|semmoldura|580px]] | ||
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 | |||
[[Arquivo:DG-UMLclass-v1.png|centro|semmoldura|580px]] | |||
=== Módulo geoterm === | === Módulo geoterm === | ||
| Linha 37: | Linha 57: | ||
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. | 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: | |||
* https://yuml.me/ | |||
* https://mermaid.live/edit | |||
Edição atual tal como às 20h27min de 22 de abril de 2024
 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: