Geo URI estendida

Expansão do protocolo Geo URI conforme [KrJeBo2020]. O Geo URI é um conceito central nas convenções adotadas pela Metodologia AFAcodes.

Definição

A incerteza é o "tamanho do ponto", u=5 nos diz que é um círculo com raio de 5 metros.

Na sua definição mais simples, dada pela RFC 5870, a Geo URI permite apenas a expressão das coordenadas de latitude e longitude, e o acréscimo do valor da incerteza.

Sintaxe:   Exemplo:	Simples geo:x,y geo:-23.5504,-46.634	Com incerteza i geo:x,y;u=i geo:-23.55,-46.63;u=15
	Coordenadas de latitude e longitude em graus decimais, incerteza em metros.

A sua expansão trouxe o conceito de geocódigo para dentro da Geo URI:

Sintaxe:   Exemplo:	com jurisdição j geo:j~g geo:BR-SP-ITU~37J	Com tipo t geo:t:g geo:olc:588MC8QV+C
	Na jurisdição (que inicia pelo código de 2 letras do país) o geocódigo é aquele fixado por autoridade local, ou adotado como padrão internacional; na opção com tipo, o usuário que escolhe o padrão de geocódigo que deseja adotar.

O texto da Geo URI (geo:etc) é expresso em chats, e-mails, documentos, URLs, APIs, etc. ele permite o entendimento padronizado e a ativação de ferramentas de localização geográfica (ex. ativação por QR code). A "resolução dos geocódigos", pela ferramenta ou uso de API, é a chave para a sua ativação.

O AFAcodes já resolve todos esses tipos:

Simples	Com incerteza	Com jurisdição	Com tipo
geo:-23.22341,-47.41321	geo:-23.22341,-47.41321;u=100	geo:BR-SP-ITU~37J7	geo:olc:588JQHGP+
geo:-15.789283,-47.8795	geo:-15.789283,-47.8795;u=32	geo:BR-DF-Brasilia~FRRS	geo:ghs:6vjynmxj

Analogia com expansão do protocolo HTTP

Aplicativos e navegadores Web recuperam páginas e outras informações provenientes de um endereço de IP na rede, através de protocolos tais como o HTTP e FTP. Mas o número de IP, com seus 12 ou mais dígitos, apesar de ter sido utilizado nos primórdios da Internet, era horroroso para humanos.

Hoje a interação humanos-Web é quase que integralmente mediada pelo nome de domínio, muito mais amigável e mnemônico. Analogamente, e dentro do mesmo ecossistema de normas da internet (RFC), o protocolo Geo URI, ainda pouco popular apesar dos seus 10 anos de idade, opera com um código difícil de se lembrar, que é o par numérico de latitude e longitude. A localização Geo URI do Marco Zero da Cidade de São Paulo, por exemplo, é determinada por geo:-23.550385,-46.633956. São 16 dígitos numéricos e, com sinais e pontuação, 21 caracteres ao todo para serem lembrados.

A solução, muito mais racional para o problema da Geo URI é a ampliação do seu escopo para aceitar geocódigos eficientes padronizados, como o Geohash, OLC e outros. O exemplo acima no padrão OSMcodes seria geo:BR-SP-SaoPaulo~MCG.BM, com apenas "MCGBM", 5 caracteres, para se memorizar.

A tabela comparativa abaixo completa a analogia entre os dois protocolos Web:

	Domain Name no protocolo IP	Geocódigo no Geo URI
Poder mnemônico	Muito mais fácil de lembrar que o número de IP, por ser um nome.	Muito mais fácil de lembrar que o número de LatLong, por consumir menos dígitos (e só tantos quantos a precisão exigir). Opcionalmente pode misturar abreviações padronizadas (ex. ISO), fáceis de lembrar.
RFC de origem	RFC 791 de setembro de 1981. Definiu o IP.	RFC 5870 de junho de 2010. Definiu a Geo URI.
Funcionalidade primordial, nos primeiros 10 anos	O ser humano se virava sem os nomes, e não via vantagem em nomes instáveis, estranhos ou difíceis de lembrar.	O ser humano se vira sem o geocódigo, e não vê vantagem se não for geocódigo padronizado (para todos do país e por longo prazo).
Extensão definida depois	Nomes de domínio foram introduzidos pela RFC 882, dois anos depois do IP; mas só mais tarde, no final dos anos 1990, os nomes foram mais amplamente aceitos e adotados.	O uso opcional de geocódigos foi proposto por [KrJeBo2020], em 2020.
Funcionalidade estendida, vantagens	O nome é mais estável, dá a liberdade de trocar o IP sem perder o identificador de interesse humano — e com os IPs dinâmicos isso ficou importante.	O geocódigo relativo a uma pequena área é mais estável do que a coordenada, cuja precisão não é padronizada nem possui significado. No geocódigo é natural por ser proporcional ao número de dígitos. PS: na Geo URI podemos acrescentar incerteza mas ela é pouco intuitiva e mais um custo mnemônico.

Detalhes

...

GPS do smartphone como principal usuário

Uma das principais fontes de localização, principalmente para moradores terem a liberdade de descobrir ou confirmar a localização da porta de casa, é o GPS do smartphone.

Todos os recursos, para a detecção, acurácia, etc. são descritos neste tutorial: http://diveintohtml5.info/geolocation.html

Como "estado da arte para smartphones" temos https://www.zephr.xyz/ que não usa apenas a constelação de satélites, mas também a "constelação de celulares próximos".

Extenções para IDs e geo-tokens

Objetos geográficos 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. Esse identificador também precisa ser reconhecido pelas jurisdições responsável pelos seus dados ou metadados.

Os IDs inteligentes são bons candidatos a ID temporário, quanto por exemplo uma rua ainda não tem nome. No caso de IDs oficiais, o ID precisa ser perene e passível de registrado em cartório, sendo viável a solução de geo-token.

Foi proposta a seguinte sintaxe para IDs e geo-tokens:

Sintaxe:   Exemplo:	Smart ID geo:id:{t}:{x} geo:id:via:BR+123456	Geo Token geo:tk:{t}:{x} geo:tk:poa:BR+f01991
	O tipo t pode ser "via", "lot" (lote), "wb" (water body) etc. O valor x precisa ser consistente com o tipo.

Exmplicando

Os IDs suprem a demanda análoga à da infância, quando ainda não sabemos o nome das coisas: apontamos com o dedo, e com isso conseguimos resolver o problema da comunicação tão bem quanto usando um nome, "é essa rua aqui ó".

Todo ID pode se tornar uma geo-token, é o "batismo oficial do objeto". A geo-token é o ID que fica gravado para sempre no cartório, não será mais esquecido e passa a fazer parte dos "objetos oficiais", reconhecidos pela jurisdição do seu escopo. Se por acaso a posição de referência de uma via ou um endereço precisarem mudar, uma nova geo-token é registtada e associada à geo-token original como sua atualização: nenhuma das duas será perdida, mas quem solicitar a antiga vai obter a nova em retorno.

Nem todo geo-token será, todavia, um Smart ID: tokens podem nascer de metadados, sem obrigatoriedade da georeferenciação. Quando surgir o dado oficial (por exemplo objeto no OSM), uma nova geo-token é registtada e associada à geo-token original como sua atualização: nenhuma das duas será perdida, e a partir da nova token passa a ser georeferenciado.

Por exemplo um endereço postal sem ponto, com nome de rua ainda não-georeferenciado, como a rua pertencente uma certa cidade, portanto retornará GeoJSON de célula grande centrada na cidade.

Por fim as geotokens referentes a datasets, retornam GeoJSON de célula grande referente à área de cobertura do dataset, que no pior caso é uma célula L0 do país (dataset de pontos dispersos por todo país).

Ver também

...