CLP baseado na coordenada

As coordenadas geográficas e a sua representação em padrões abertos não dependem de qualquer infraestrutura e, portanto, não dependem de empresas ou do governo para a sua existência e uso continuado. O padrão básico se chama Geo URI e vem sendo usado em links da internet (exemplo), na troca de dados (ex. vCard), na telefonia móvel (GeoSMS), no Android, e uma infinidade de outras.

A proposta de um Código Localizador de Portão baseado em coordenada (CLP-coordenada) consiste, a grosso modo, em representar de maneira hierárquica e compacta as coordenadas. Com uma hierarquia que começa na escala do estado, com duas letras, depois o município, representado por uma sigla de 3 letras, até chegar no portão, cuja localização seria representada por um código do tipo Geohash — ou outro qualquer que venhamos a eleger no presente projeto.

As coordenadas geográficas são muito longas. No exemplo, se ficarmos só nos dígitos seriam ao todo 12, os dígitos "228607" da latitude e "479201" da longitude. Difícil decorar e trabalhoso digitar.

O primeiro passo é transformar esses 12 elementos em 8, ao traduzirmos as coordenadas para Geohash, 6GVVVW3D.

O segundo passo, para compactar mais um pouco, é fazer uso do contexto: se já sabemos que estamos localizados em SP e a sigla PIR já diz que é Piracicaba, então o Geohash não precisa dizer que estamos no hemisfério sul, etc. dispensamos o prefixo 6G do Geohash, comum a todos os pontos de Piracicaba. Sobram 6 caracteres: o código PIR-VVV.W3D é mais "palatável" para memorizar ou digitar.

SINTAXE

O código CLP-coordenada é uma sequência de letras (A-Z) e números (0-9), com grupos separados por hífen ("‑"). Essa sequência tem um prefixo e um sufixo, conforme a seguinte regra sintática, onde o prefixo é um código de jurisdição e o sufixo um códido de coordenada gegráfica válido para o interior do territorio da jurisdição:

Por ser um padrão restrito ao território brasileiro, inicia pela sigla BR. As jurisdições "BR-" <uf>, referentes às unidades da federação, são determinadas pelo padrão ISO 3166-2:BR, ou seja, são as tradicionais siglas de estado padronizadas pelo IBGE. Em seguida a última parte do código de jurisdição é o Município.

Como há a opção de usar o CLP para designar porções maiores e menores da hierarquia territorial, a UF e o Município são opcionais. Disso resulta a seguinte regra sintática para a jurisdição:

A designação de município faz uso das siglas de 3 letras do padrão já em uso nos identificadores de estradas. Como o CLP é sensível a contexto de país e UF, o uso do prefixo BR é dispensável no "contexto Brasil" e o uso da UF também dispensável quando as partes usuárias do CLP forem capazes de deduzir com certeza a UF.

DIFERENTES PADRÕES

Comparando os diferentes padrões de geocódigo de grades que os fundamentam. Existe uma imensa diversidade de representações alternativas à Latitude/Longitude, e que podem ser consideradas também "geocódigos". Pode-se classificá-las da seguinte forma:

Um levantamento parcial foi realizado por K. Clemens em 2016, ao analisar as características de geocódigos e de códigos postais em geral. A principal vantagem de um geocódigo baseado em DGG de alta resolução, sobre um código postal comum, é que a capacidade de localizar o ponto desejado.

O CEP 20031-050 do endereço de entrada do Teatro Municipal do Rio, não nos diz onde está, informa apenas que é a rua Evaristo da Veiga. Um código localizador, como por exemplo PlusCode 3RRF+6F, diz exatamente onde está o portão!

Aprendizados com o CEP

Depois de décadas usando o CEP aprendendos que ele tem problemas intríncecos do código, e problemas de operação, do "Sistema CEP" como um todo, por reter patentes e direitos autorais, ser centralizado, etc. Sabemos que precisamos do oposto, queremos códigos livres e descentralizados.

Quanto aos problemas intrínsecos, o principal é a dificuldade de se memorizar. O CEP é tão pouco mnemônico (pouco amigável para memorização) quanto um número de telefone. O uso de siglas já padronizadas, que já estão em nossa memória, seria um grande avanço. Podemos melhorar o CEP substituindo prefixos por siglas. O código de um CEP do Amazonas (AM) pode ser AM150‑088 ao invés de 69150‑088, de um CEP de Tocantins (TO), TO500‑360 ao invés de 77500‑360.

Também aprendemos com o uso do CEP que um código com hierarquia é útil. Se formos substituir o CEP por um novo padrão, o CLP, queremos que ele preserve essa característica de ser um código hierárquico.

A hierarquia garante que dois CEPs, digamos 13165 e 13170, se possuem prefixos iguais, então são vizinhos, estão dentro de uma mesma região, representada pelo prefixo comum, 131 no exemplo.

O CEP com mais dígitos vai representando com mais detalhe uma região do espaço... Mas são 8 dígitos no CEP completo, e ainda assim não representa o endereço exato do portão. Com o CLP podemos fazer melhor,

e justamente por isso, entre outras aplicações, o CLP num futuro distante substituiria o CEP, para num só código, de 7 ou 8 caracteres, chegarmos no portão.

COMPARANDO OS PADRÕES CANDIDATOS

Comparação entre padrões abertos mais difundidos e tecnicamente satisfatórios: Geohash, PlusCode e S2. Outras tecnologias podem vir a ser acrescentadas como opção para se eleger o melhor fundamento para o código CLP.

A seguir comparação se deu em torno de um ponto de controle bem conhecido, na capital do Estado de São Paulo, o Marco Zero (latitude -23.550385, longitude -46.633956). O pedestal do Marco tem aproximadamente 3 metros de diâmetro, as dimensões usuais de um portão urbano.

Códigos em sua extensão completa, sem cortar prefixo de município, e sem qualquer outra adaptação, tal como a base numérica dos seus dígitos: * Nactag (base32): ?? * Geohash (base32): 6gyf4bf1n * PlusCode normal (base20): 588MC9X8+RC * S2 (hexadecimal): 94ce59aaf89

O uso de códigos híbridos, que misturam a designação do município com a coordenada do ponto, é realizado apenas em duas das tecnologias populares analisadas:

Ainda assim o PlusCode não oferece resolução de abreviações, e o MapCode trata BR-SP-SPA como SP, subintendendo que é a capital. Como qualquer uma das tecnologias abertas pode ser livremente adaptada, com a inclusão da sigla de município resultariam nos seguintes códigos:

A seguir cada um dos exemplos será ilustrado pelo mapa fornecido na respectiva infraestrutura.

Geohash

Localização do Marco-zero representada por Geohash: 6gyf4bf1n.

Os dois primeiros dígitos (prefixo 6g) podem ser cortados quando sabemos que o contexto é a cidade de São Paulo, disso resulta o código mais compacto YF4B.F1N. Como demonstrado na apresentação, fazendo uso do conjunto de cobertura (reindexação de 6gyf para 3) fica ainda mais compacto (!), 34B.F1N.

Para completar a ilustração, vejamos a localização de um portão vizinho do Marco, como a entrada da Catedral da Sé, com sua escadaria de ~10m

A assimetria das células que ocorre em certos níveis hierárquicos, como o de 8 dígitos ilustrado acima, tem origem num problema intrínseco do sistema Latitude-longitude, que só seria corrigido mediante projeção (por exemplo projeção cônica resultaria em coordenadas UTM). Com origem na mesma causa, há também o problema das células Geohash perderem precisão com a latitude — crescendo a área da célula conforme nos aproximamos do Equador, ao norte do país. A área das células de 8 dígitos varia de 25,1±0,2 m² no RS; até 26,9±0,1 m² no AM. Nas células de 9 dígitos a variação é de 4,4 m² a 4,8 m².

Para explorar o Geohash com sua grade e um município ao fundo, experirmentar:

Por fim, apesar de ser um sistema inteligente na sua hierarquia, matematicamente ele se baseia num fractal que "dá saltos", a curva de ordem Z, perdendo-se a propriedade de "células vizinhas com prefixos iguais", que o tornou atrativo. No Geohash-Hilbert o problema foi corrigido, assim como no S2 descrito a seguir.

Quanto aos níveis indermediários da hierarquia, é possível expandir o código Geohash para base4, conforme ilustração abaixo do prefix-tree. Através desses níveis intermediários, códigos ligeiramente mais curtos podem ser conseguidos, fazendo uso de um mosaico mais detalhado na cobertura dos municípios.

Resumo das características do Geohash:

Representação numérica:
base32
Célula títipica:
9 dígitos ~5×5 m
Hierarquia:
sim, podendo ser melhor adaptada
Algoritmos de referência:
- código Java (licença Apache2);
- ST_GeoHash() do PostGIS (licença GPL2).
Potencial de adaptação:
médio, pode-se mudar o alfabeto da base, e acomodar o uso de prefixo de município.
Infraestrutura de teste utilizada:
Geohash nativo do PostGIS. Visualização com LeafletJS e sua biblioteca GeoJSON, e boxes Geohash-JS.

OpenLocationCode

Ver "OLC" do PlusCode.

PlusCode

Localização do Marco-zero representada por PlusCode: 588MC9X8+RC, com célula de ~10×10m. A definição do código (padrão OpenLocationCode - OLC) se encontra em OLC Definition. Há uma sutil distinção entre o algoritmo OpenLocationCode, opção em foco no presente estudo, e a API Google denominada PlusCodes, já na sua versão 2.0 desde outubro de 2018.

Os quatro primeiros dígitos (prefixo 588M) podem ser cortados quando sabemos que o contexto é a cidade de São Paulo, disso resulta o código mais compacto C9X8+RC.

Grade principal sem hierarquia: com células de 1/8000° esferoradianos (áreas de ~100 m²), nesta grade o endereço vizinho do Marco-zero (Editora UNESP a menos de 100 m do Marco-zero) apresenta código F928+27, totalmete distinto.

Para variações na precisão do endereço, existe a hierarquia da grade secundária, subdividindo em mais 20×20 células, com a adição de mais dois dígitos depois do sinal "+". Desse modo C9X8+RC4 é uma célula com ~2,5 metros de lado, e C9X8+R ~200 metros. Devido ao "salto", sem possibilidade de precisão intermediária, o PlusCode deixa de contemplar a escala do portão rural, da ordem de 15×15m nos requisitos do CLP.

Resumo das características do PlusCode:


Representação numérica:
base20
Célula títipica:
10 dígitos ~10×10 m
Hierarquia:
não, subgrade de 3 níveis insuficiente
Algoritmo de referência:
código Python e outros, todos licença Apache2
Potencial de adaptação:
baixo, pode-se mudar a base para 32, e acomodar o uso de prefixo de município.
Infraestrutura de teste utilizada:
Código Python do algortimo de referência, adaptado para a base32 do CLP e para o PostGIS.

Problemas do PlusCode

O PlusCode é baseado no OpenLocationCode, que é livre, mas não é apenas o OpenLocationCode... É um serviço de resolução de códigos contextualizados por nome de cidade: este serviço é uma caixa preta, e não tem licença livre. Quando o contexto não é derivado de um padrão aberto e soberano (controlado pela jurisdição), dizemos que o contexto é composto de "palavras mágicas".

Exemplos de problemas típicos de contextualização. O prédio da prefeitura do município de Altamira (PA) está localizado no PlusCode contextualizado QQVJ+6F, que é um código PlusCode usual de 6 caracteres mais nome da cidade.

Como o munípio de Altamira é muito grande, requer mais contextos, como o "Altamira, distrito de Forlaleza"... Ou seja, a estratégia do código curto sai do padrão e o Google cria arbitrariamente o componente de código "Fortaleza". Ver por exemplo este ponto é contextualizado por duas palavras, o nome de município (Altamira), e a palavra mágica Fortaleza.

Por fim, a maior parte das localizações em meio rural de Altamira ficam até mesmo sem contextualização, nem a palavra Altamira comparece. Exemplos:

S2geometry

Localização do Marco-zero representada por tecnologia S2: 94ce59aaf89f, com célula de ~2×2m. A representação pode ser adequada para base32, 3MHP.9IW0.9 (9 dígitos).

O sistema de referência conhecido como "S2 Geometry" é na verdade uma biblioteca para indexação espacial em grandes bancos de dados, descrita em S2geometry.io. As células da grade hierárquia, com identificadores de 64 bits (S2geometry/Cell_ID) são em geral expressos fora da base de dados como números hexadecimais, mas essa escolha é indiferente.

O site com recursos para demonstração, utilizado na ilustração abaixo, não faz parte da "distribuição oficial".

O S2 pode ser considerado uma evolução do Geohash, pois resolve dois problemas sérios para um país de escala continental como o Brasil:

A implementação de referência da biblioteca S2 é escrita em C++ (mesma linguagem que o PostGIS) e portada para Go, Java e Python. Conforme anunciado, a biblioteca existe desde ~2011 quando uma versão inicial do código foi posta a público, mas somente em dezembro de 2017 o código passou a ser atualizado e distribuído de de forma mais ampla e confiável.

Resumo das características do S2geometry/Cell_ID:


Representação numérica:
base16
Célula títipica: level-21
12 dígitos ~2×2 m
Hierarquia:
sim, podendo ser melhor adaptada
Algoritmo de referência:
código C++ (licença Apache2).
Potencial de adaptação:
bom, pode-se adotar base32 e acomodar o uso de prefixo de município. Forma e área das células estável em todo o território nacional.
Infraestrutura de teste utilizada:
Wraper da versão S2geometry Python adaptado para PostGIS, https://github.com/AfieldTrails/s2-postgis

COMPARANDO NÃO-CANDIDATOS

Alguns algoritmos/tecnologias são muito ruins e por isso devem ser descartados do estudo comparativo. Um desses algoritmos foi apelidado de algoritmo ingênuo e, apesar de não ser candidato, é uma referência importante, estabelecendo o critério de "mínima performance". Ou seja, nenhum "algoritmo candidato a CLP-coordenada" pode ser pior do que o ingênuo.

Outras tecnologias são até muito boas, mas já foram de ante-mão barradas por não serem livres: são restritas por patentes ou direitos autorais. O Whats3words por exemplo é um destes casos.

Nactag e código Microsoft

A NACtag não apresenta vantagens técnicas mas é interessante por ser um dos primeiros geocódigos, e por estabelecer direitos autorais sobre algo que até então não se cogitava como passível de tais direitos. A disputa com a Microsoft também ajuda a realçar os riscos envolvidos na adoção de geocódigos não-livres.

Na ilustração a localização do Monumento a Washington nos EUA, nas coordenadas geo:38.88944,-77.03528, com célula NACtag de ~40×30m. É um código opcionalmente hierarquico de 8 dígitos base36 (4 cada coordenada).

Na Wikipedia a NACtag foi registrada como Natural Area Code (NAC), site oficial nacgeo.com.

O algoritmo aliado à utilização pública foi proposto em 1994 por Xinhang Shen, visando a representação mais compacta das coordenadas de latitude e longitude, e entendendo que isso demandaria fixar algumas convenções de interpretação, portanto o estabelecimento de um padrão. Shen optou pela via do licenceamento: ainda hoje (com ultima atualização de 2014) a licença Nactag não é totalmente livre, apreser de se auto-denominar "free licensing".

A NACtag (ou NAC locator) foi também um dos primeiros sistemas de geocódigo a se declarar como substituto de postcodes tradicionais como o CEP, já oferecendo a solução online pelo menos desde 2007.

NOTA SOBRE DISPUTA POR DIREITOS AUTORIAIS

Em 2005 entraram em disputa os detentores de direitos sobre a patente internacional No. WO9607170 (de 1995), entitulada "Compact text encoding of latitude/longitude coordinates", de propriedade da Microsoft, e os priprietários da NAC. A patente da Microsoft é de fato bastante similar e posterior ao registrio de copyright da NACtag, de 1994. Por serem sistemas jurídicos distintos (direitos autorais vs direitos sobre patente), o problema permanece.

A patente da Microsoft emprega o algoritmo equivalente para converter as coordenadas de longitude e latitude em inteiros não negativos e, em seguida, usa um conjunto de caracteres com exatamente o mesmo número de caracteres e as mesmas ordens de caracteres, exceto a remoção da letra "L" e a adição da letra "Y". Por exemplo, longitude -127.8202; latitude 3,436086111 terá as seguintes representações:

O caso destaca que, mesmo com a flagrante ilegalidade da patente Microsoft já demonstrada em 2012, o embrólio jurídico surge como barreira e risco aos protocolos e variantes de geocódigos sub júdice. Neste sentido recomenda-se optar por geocódigos livres e que mais se distanciam de patentes consolidadas.

MapCode

Localização do Marco-zero representada por tecnologia MapCode: BR-SP RR.56 com célula de ~5×5m (a confirmar). É um código não-hierarquico (a confirmar) de 4 caracteres aparentemente base36.

O MapCode está contextualizado pela cidade mais populosa nas proximidades do sinal de quem faz a solicitação, que neste caso é a capital de BR-SP, representada no link pelo código ISO 331.

Mais detalhes sobre o MapCode no seu documento de apresentação e na sua patente. Foi aparentemente um dos primeiros padrões populares a sugerirem a substituição do CEP pelo geocode.

Whats3words

Localização do Marco-zero representada por tecnologia Whats3words: funil.leites.chaves com célula de ~4×4m (a confirmar). É um código não-hierarquico de 3 palavras, cada palavra representa um dígito da base600 ou maior.

É o principal representante da priorização do "legível e mnemônico", ou seja, pretende-se que seja mais fácil comunicar, soletrar ou lembrar de uma sequência de 3 palavras aleatórias, do que de uma sequência de 6 letras aleatórias.

Syllagloble

Localização do Marco-zero representada por tecnologia Syllagloble: det erwi kam oyqo com célula de ~3×5m (a confirmar).

O software Syllagloble é apenas um experimento da empresa "Here". Similar ao What3words, faz uso de 4 sílabas ou palavras curtas, no lugar de 3 palavras longas.


LIETARATURA

As comparações entre tecnologias que solucionam o problema também tem sido realizadas, por exemplo

Na Irlanda hove um concurso entre 2010 e 2011 para selecionar propostas sistema de código postal.[ref] Infelizmente na época as soluções abertas não eram tão difundidas e optou-se por um modelo tradicional que supunha alto custo de manutenção, e portanto com demanda por reimbolso através de licenceamento privado.[ref],[ref]