|
|
| Linha 2: |
Linha 2: |
|
| |
|
| == Escopo == | | == Escopo == |
| [[wikipedia:Geographical feature|Objetos geográficos]] com definição de interesse público, tais como ruas, pontos de endereço, polígonos de lote, etc. carecem de um identificador único e independente da aplicação, porém reconhecido pelas [[Jurisdição|jurisdições]] que reforçam sua definição. Os principais recursos de definição desses objetos são os seguintes projetos e respectivos agentes: | | [[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. |
| * Openstreetmap (OSM) e OSM-Foundation: atribui um identificador estável no mapa, porém sem garantia de estabilidade.
| |
| * [[wikipedia:Wikidata|Wikidata]] e [[wikipedia:Wikimedia Foundation|Wikimedia Foundation]]: atribui identificador a cada conceito, mas seus IDs demoram mais que OSM a estabilizar, e não dão conta de todos os objetos geográficos, a curadoria de relevância pode comprometer a completeza.
| |
| * Prefeituras e poderes similares nas sub-jurisdições: são as principais fontes de "dados espaciais oficiais", mas não são todos abertos ou eficientes com seus dados.
| |
| * Outros: orgãos oficiais como as agências de estatística, INDEs, espaciais (ex. NASA fornece dados), etc.
| |
|
| |
|
| Identificadores de objetos precisam ser únicos e em alguns casos, como nas listagens oficiais de endereços, podem "nascer sem georeferência". Para garantir a unidade, completeza e independência dos identificadores foram sugeridas [[wikipedia:Non-fungible token|tokens não-fungíveis]] (em inglês: non-fungible token, '''NFT''') para esses objetos geográficos. As principais demandas levantadas pela AddressForAll com seus parceiros foram:
| | ... Ver página de discussão... |
|
| |
|
| * Vias e rios (georeferenciados no OSM)
| | === Maturidade da token === |
| * Topônimos (sem georeferência direta - apenas jurisdicional)
| | 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. |
| ** Nomes de via (ruas, estradas, ferrovia, etc.)
| |
| ** Nomes de corpos d'água (rios, lagos, etc.)
| |
| * Lotes (sempre georeferenciados)
| |
| * Pontos de endereço (de acesso a lotes)
| |
| ** Georeferenciados: recebem um Geohash clássico ou GGeohash official.
| |
| ** Sem georeferência: recebem hash baseado no token do topônimo e numeração predial.
| |
|
| |
|
| Propomos reuni-las na forma de Geo-tokens.
| | 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. |
| | |
| Potencial solução usando [https://www.w3.org/TR/did-core/ DID]: https://magic.link/docs/dedicated/introduction/decentralized-id
| |
| | |
| PS: existem sugestões (como [https://www.nationalgeographic.com/science/article/how-nfts-work-explainer essa da National Geographic] para as fotos de fotografos selecionados) e iniciativas comerciais (ex. [https://mygeotokens.com/#whitepaper MyGeoTokens]), mas nenhuma cumprindo com o perfil destacado acima.
| |
| | |
| === Meta NFT maturidade git ===
| |
| ....
| |
|
| |
|
| == Problema principal == | | == Problema principal == |