2 402
edições
→Potenciais soluções: adaptando do Fredy para Potenciais soluções
(→Escopo) |
(→Potenciais soluções: adaptando do Fredy para Potenciais soluções) |
||
| (2 revisões intermediárias pelo mesmo usuário não estão sendo mostradas) | |||
| Linha 2: | Linha 2: | ||
== Escopo == | == Escopo == | ||
[[wikipedia:Geographical feature|Objetos geográficos]] de [[Interesse público e curadoria|interesse público]], tais como ruas, pontos de endereço e polígonos de lote, reconhecidos pelas [[Jurisdição|jurisdições]] que reforçam sua definição. | [[wikipedia:Geographical feature|Objetos geográficos]] de [[Interesse público e curadoria|interesse público]], tais como ruas, pontos de endereço e polígonos de lote, reconhecidos pelas [[Jurisdição|jurisdições]] que reforçam sua definição. | ||
. | A relação esperada entre ID (ou nome) e sua resolução, é que o resolvedor retorne uma ''feature'' GeoJSON distinta para cada geo-token. Ou seja, há garantia de unicidade também seria bijetora. | ||
=== | === Tokens sem georeferência única === | ||
Objetos não-georeferenciados (ex. topônimos ou nomes de rua sem georeferenciação), podem ser grosseiramente georeferenciados pelo contexto, adotando um esquema de [[wikipedia:Toponym resolution|resolução de topônimos]], tipicamente municípios e seus quadrantes de cobertura. Nesse caso o comportamento será diferente: muitos IDs retornaram a mesma feature de GeoJSON. O status do geo-token fica como "pendente georeferenciação", devido à pendência de unicidade geográfica. | |||
== Problema principal == | == Problema principal == | ||
| Linha 27: | Linha 25: | ||
=== Problema do cartório oficial === | === Problema do cartório oficial === | ||
... | |||
=== Problema da atualização e rastreabilidade === | === Problema da atualização e rastreabilidade === | ||
... | |||
=== Problema do cadastro oficial === | === Problema do cadastro oficial === | ||
Endereços (ex. de correspondência) são caracterizados por um ponto geográfico, mas esse ponto não é eterno nem preciso, e, principalmente, é '''difícil fixar uma "definição oficial" do endereço'''. | Endereços (ex. de correspondência) são caracterizados por um ponto geográfico, mas esse ponto não é eterno nem preciso, e, principalmente, é '''difícil fixar uma "definição oficial" do endereço'''. | ||
| Linha 60: | Linha 58: | ||
== Potenciais soluções == | == Potenciais soluções == | ||
Alternativas para a implementação da Geo-Token: | |||
# '''[[wikipedia:Blockchain|Blockchain]]''': aproveita a natureza descentralizada e a integridade inalterável dos blockchains para registrar e rastrear cada endereço e suas alterações subsequentes. Como as geo-tokens não são criptográficas, elas seriam consideradas dados, que por sua vez podem ser registrados na forma de dataset ao invés de um dado por token do blockchain. Conforme a natureza mais lenta (dados frios) ou mais rápida (dados quentes), existem diversas soluções: | |||
#* [[wikipedia:Blockchain#Sidechains|Sidechain]]: para realizar operações com dados quentes, por sua rapidez e barateamento, é a mais indicada. | |||
#* Side-git: numa arquitetura sidechain, mantemos o blockchain principal e substituimos a sidechain por um git. Isso barateia e simplifica ainda mais o processo. | |||
# '''Sistema Centralizado''': Sistema mais tradicional que depende de um banco de dados centralizado para armazenar e gerenciar endereços, complementado pelo Token AFA como identificador único. Ainda assim pode-se usar controle de versões como faz a Mediawiki, ou com tecnologias mais sofisticadas, como [arquitetrua kappa](https://milinda.pathirage.org/kappa-architecture.com/). | |||
# '''[[wikipedia:git|''Git'']]''' (Sistema de Controle de Versão): Utiliza a arquitetura e os princípios de controle de versão do Git, permitindo um registro detalhado de cada mudança de endereço e associando-as a um identificador baseado no hash do comprometer-se. | |||
# Ouras: identificadores hibridos, por exemplo geo-token de lote e contador sequencial, para designar o geo-token de um endereço... Existem dezenas de outras alternativas. | |||
Cada uma destas alternativas apresenta vantagens e desafios únicos, e a escolha ideal dependerá do equilíbrio desejado entre segurança, praticidade, escalabilidade e custo. | |||
=== Estado de arte === | === Estado de arte === | ||
Soluções completas similares: | |||
* ... | |||
* https://www.placekey.io/ | |||
* ... | |||
Recursos para a implementação: | |||
* lotes de tokens em baixa maturidade: git | |||
* "gestão a quente" de tokens maduras: arquitetura Kappa suficiente, https://pt.slideshare.net/juantomas/aspgems-kappa-architecture | |||
=== Maturidade da token === | |||
Do ponto de vista econômico e tecnológico, a criação de uma nova ''token'' tem custo, e em geral risco e custo altos enquanto não se torna um padrão com quantidade mínima de jurisdições aderindo. No processo inicial de "maturação da token" tecnologias mais simples que blockchain podem ser adotadas. | |||
Para reduzir o custo de teste e desenvolvimento da ''token'' e suas aplicações, recomenda-se iniciar com a tecnologia [[git]]. Ela também pode ser útil para o processo de legitimação dos blocos: enquanto os dados não forem homologados e legitimados como oficiais, podem permanecer em ''git''. | |||