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
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: |
Simplesgeo:x,y geo:-23.5504,-46.634
|
Com incerteza igeo: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 jgeo:j~g geo:BR-SP-ITU~37J
|
Com tipo tgeo: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
) pode ser 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~37JS | 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 AFAcodes 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 IDgeo:id:{t}:{x} geo:id:via:BR+123456
|
Geo Tokengeo: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 OpenStreetMap), 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
...