2 391
edições
Sem resumo de edição |
(→Potenciais soluções: adaptando do Fredy para Potenciais soluções) |
||
(12 revisões intermediárias pelo mesmo usuário não estão sendo mostradas) | |||
Linha 1: | Linha 1: | ||
''' | '''Geo-tokens''' são [[osmc:Convenções/Identificadores inteligentes|identificadores inteligentes]] de escopo geográfico (identificam localizações ou seus metadados), com capacidade de registro cartorial e a capacidade de se manterem atualizados (com rastreabilidade das versões precedentes). Essas duas capacidades requerem que o ID seja também um [[wikipedia:Non-fungible token|token não-fungível]] (em inglês: non-fungible token, '''NFT'''). Daí o nome "NFT geográfico", reduzido para "token geo" ou geo-token. | ||
== 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. | |||
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 == | ||
Para o governo municipal, '''garantir o "endereço oficial"''' dos imóveis do município. Para o cidadão, que necessita demonstrar certificado de endereço ou localizar com confiabilidade endereços vizinhos, ele também requer um "endereço oficial garantido". | |||
A garantia só é possível quando todas essas condições são satisfeitas ao fornecermos um identificador único do endereço: | |||
# '''Integridade''' cartorial e jurídica: uma vez registrado o ID e seus metadados, não podem mais ser adulterados, e ficam "gravados na pedra", não se perdem. Por ter valor de cartório, a data, licença, etc. são juridicamente válidas. | |||
# '''Perenidade''': o endereço e seu identificador único precisam ser "eternos enquanto durem". | |||
# '''Auto-suficiência''' mínima: com apenas o ID é possível localizar razoavelmente o ponto, sem demandar consulta a uma base de dados central. | |||
# '''Versionamento''': o ID não precisa ser imutável, podem ser atribuídos novos IDs e os velhos apontarão para os novo. | |||
# Situação corrente: qualquer que seja a versão, por mais antigo que seja o ID, o sistema resgata a sua situação corrente. | |||
# '''Rastreabilidade''' completa: | |||
#* dos dados originais: permite resgatar a [[wikipedia:Data_lineage#Data_provenance|proveniência dos dados]] de endereço, saber qual foi a origem e confirmar sua integridade, data, licença, etc. | |||
#* dos dados correntes: metadados mais atuais (cadastro atualizado). | |||
#* dos histórico de modificações: demais metadados, entre original e corrente. | |||
=== Problema do cartório oficial === | |||
... | |||
=== Problema da atualização e rastreabilidade === | |||
... | |||
=== 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'''. | |||
A localização do endereço de um lote pode sofrer diversas imprecisões e modificações, que podem ser classificadas em dois grandes grupos: | |||
* Problemas maiores: | |||
** '''Inconsistência ponto-endereço''': a descrição "rua e número" incompatível com o ponto (comum nas prefeituras). | |||
** '''Sem descrição''': apenas o ponto existe, numa rua sem nome conhecido, numa casa sem número conhecido (comum no OSM). | |||
** '''Localização inválida''': o ponto cai num corpo d'água, no meio da rua ou outro local inválido (quando de problemas de SRID e similares). | |||
** '''União ou desmembramento de lote''': no desmembramento o antigo endereço se torna dois, na união dois antigos endereços podem deixar de existir e surgir um novo. | |||
* Problemas menores: | |||
** '''Ponto longe da rua''': em lotes ou construções maiores é comum aferir o endereço pelo centroide, e este se localizar muito longe da rua. | |||
** '''Esquina''': o ponto cai numa esquina, sem garantia de consistência com nome de rua. | |||
** '''Lote com múltiplos endereços''': parques, shopping-centers, etc. grandes lotes em geral possuem mais de um endereço. | |||
** '''Múltiplos lotes com mesmo endereço''': tipicamente em endereços com complemento "fundos" ou "entrada pela lateral", podem até ser lotes maiores mas as duas entradas muito próximas e a resolução dos dois pontos muito baixa. | |||
Na metodologia AFA-token o endereço nasce como [[osmc:Convenções/Identificadores_inteligentes#ID_de_endereço|identificador inteligente]] (Geo URI de "Point Of Address" na forma <code><nowiki>geo:id_poa:{ID}</nowiki></code>), ou seja, é a localização e um identificador único ao mesmo tempo. Os problemas maiores são solucionados pela rastreabilidade: quem tem o AFA-token antigo chega no AFA-token novo, no pior caso (ex. desmembramento) a duas ou mais alternativas de localização. Nos problemas menores há uma atualização da localização, mas a original ainda é razoável. | |||
=== Exemplos concretos=== | === Exemplos concretos=== | ||
... | |||
== Problemas periféricos== | == Problemas periféricos== | ||
... | |||
=== Exemplos concretos=== | === Exemplos concretos=== | ||
... | |||
== 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''. |
edições