osm-codes/spec

OSM.CODES specifications and abstract models

spec's Issues

The geo:osm64:code for OSM's backward compatibility

Few users, but stil in use, since 2009, the https://wiki.openstreetmap.org/wiki/Shortlink it is in the Geohash history. Base64 encoded Geohash.

The "geo:" resolver specification

Complementing issue #4 about Geo URI protocol. The URL template http://osm.codes/geo:${code} is the web service endpoint for resolutin of the Geo URI. It returns a simple JSON with main information about the geographic location pointed by it. Canonic point representation, alternative representation and metadata about the point and/or its context.

The use of the geo: prefix seems redundant, but it is important here for dissemination of the Geo URI concept. Production example, http://osm.codes/geo:-23,-46.6

Use this issue to suggest and discuss the specification of the complementary endpoints. Illustrative examples:

Endpoint at http://osm.codes/	Type	Description
geo:${code}	GET	default web service. Suggest info
geo:${code}/f2c	GET	"free Geo URI to canonic", returns the canonical official Geo URI of the input Geo URI (can be the same).
geo:${code}/info	GET	"information about", returns the full JSON about the input Geo URI.
geo:${code}/info/.xhtml	GET	same as info endpoint, but in XML format (for AJAX direct rendering web page).
geo:${code}/info?${parameters}	GET or POST	same as info endpoint, but sending more input parameters by GET or POST. Parameters to specify output or to complement the request (ex. location context)
geo:${code}/f2u	GET	"free Geo URI to default URL ", returns the link to be redirected by default (e. g. link to OpenStreetMap).
geo:${code}/f2us	GET	"free Geo URI to all URLs ", returns the all links, like BING, PlusCode and OpenStreetMap. See e.g. geohack list of URLs
geo:${code}/f2us?${parameters}	GET or POST	Same as f2us endpoint, but qualifying the type of URL that need (e.g. map with BBOX) and/or filter (e.g. only BING).
...	...	...

The A2B endpoint labels and resolver functionalities was suggested since 1997 with the RFC 2169.

---

Alternative formats to discuss:

• string with canonic Geo URI;
• simple key-value JSON some basic informations;
• GeoJSON with a point, uncertain region or grid cell;
• JSON-LD with full metadata.

The geocode extension of the Geo URI

Use this issue to discuss the (current) white paper 2 of the OSMcodes foundations.

PS: to edit or comment the OSMcode's white paper 2, use this link.

---

[white paper 2]
Expanding the Geo URI (RFC 5870) to incorporate geocodes

ABSTRACT: The Geo URI (internet standard RFC 5870) is a compact sequence of characters that identifies a geographic location, with the syntax that starts with the 'geo' prefix followed by latitude and longitude coordinates. However, there are, nowadays, more compact and human-readable conventions to express the same geographic location, such as Geohash or OLC (Open Location Code) geocodes. This proposal describes a simple extension for the “geo:x,y” part of the schema, the sub-schemas “geo:x” (where x is an official geocode) and “geo:type:x” (where type is a label like "ghs" for Geohash or "olc" for OLC), in order to include new syntactic and semantic conventions in the Geo URI.

NOTE: in the https://osm.codes site and other applications, the use of the full protocol syntax is not necessary, the most important in the white paper is the consensus about the use of geocodes, its syntax and semantic conventions.

Algoritmo de localização da via mais próxima de um ponto

O problema estritamente geométrico é conhecido no jargão GIS como "K nearest neighbours" (KNN), e encontra-se bem apresentado em postgis.net/workshops/knn (archive).

Basta fazermos alguns testes com os dados que temos em mãos, ajustar parâmetros e então eleger o algoritmo mais adequado. Sugere-se criar antes um conjunto de "testes canônicos" para cada grupo (ex. vias rurais do estado de São Paulo), que ficam sendo tanto o referencial para ajustes e seleção de algoritmos, como um primeiro conjunto de testes de regressão a ser usado durante o desenvolvimento da solução final.

Após experiência com dois ou mais grandes grupos (ex. vias rurais e urbanas) pode-se avaliar se é necessária a parametrização (ajustes diferentes para grupos diferentes) ou não.

A solução do problema pode ser expressa como função PostGIS na Lib complementar, que retorna JSON com ID da via mais provável e score de proximidade:
CREATE FUNCTION lib.point_via_knn(point geometry, type text DEFAULT NULL, city_id bigint DEFAULT NULL) RETURNS JSONb. Pode-se forçar o contexto do ponto (apenas vias de uma cidade ou ajustes para zona rural) caso o algoritmo seja sensível a algum parâmetro.

Variante com restrição sobre o nome da via

Em geral o problema de encontrar a linha mais próxima de um ponto surge no contexto de se consolidar um ponto de endereçameto: as tags addr:street e addr:housenumber são fornecidas junto com o ponto num exemplo típico do OSM. Fora do OSM, numa consulta livre (nome de rua dado com mais liberdade e imprecisão), pode-se supor que addr:street é composto apenas de palavras-chave e addr:housenumber nulo. Devemos supor portanto que o único input adicional (ao problema KNN) é o nome de rua dado por palavras-chave.

... Pendente resolução como extensão do KNN, por exemplo fixando-se um score para o casamento de palavras-chave e ajustando o score conforme grau de confiabilidade da informação de ambos os lados (linhas do OSM podem estar registradas com nomes errados).

Geocode types to be controled and first list of abbreviated names

The "geocodetype" namespace is a set of mnemonical identifiers. Examples accepted and PostgreSQL implementations, all open source and free geocodes:

Geocodes based on regular quadrilateral DGGs (Discrete Global Drid)

geocodetype	name	standard base/alphabet	offer binary code
ghs	Geohash	base32 / 0-9 a-z (except "a", "i", "l" and "o")	yes
olc	Open Location Code	base20 / 2-9 C F-H J M P-R V-X	no
s2	S2 Geometry	base16h / 0-9 a-f G-S	yes
s2b32	S2 Geometry	base32 / 0-9 ?	yes

Geocodes based on regular hexagnal DGGs

geocodetype	name	standard base/alphabet	offer binary code
uh3	Uber H3	?	yes

Mapas estáveis de cada jurisdição

Montando repositórios stable-${countryCode} de cada jurisdição. Pendente discussão dos formatos e organização das pastas, usar o repositório git/osm-codes/osm-stable para algoritmos que traduzam as especificações aqui da spec.

Algortimo para obter a numeração predial

Dado um ponto (geo URI) e o via_id (identificador da via) onde será projetado (por ST_ClosestPoint), retorna-se a metragem da via para aquele ponto de projeção.

A metragem tem como referência o valor de ST_LineLocatePoint, mas não pode ser inferida diretamente disto: a solução do problema requer justamente a convenção de um modelo matemático (polinômio de ajuste) minimamente razoável para manter em cache de cada linha representativa de via.

A obtenção dos dados do polinômio depende da amostragem de numeração predial oficial (ou tabela de dados do odômetro no percurso da estrada), e do grau de sinuosidade da linha (ex. comparação dos ajustes com e sem simplificação de linha).
PS: quanto mais distante do marco zero, maior o peso da amostra na regressão (fit do polinômio) tendo em vista que erros relativos à sinuosidade da linha vão sendo acumuldados.

Convenções

Na modelagem o ideal é ter uma só linestring por via, mas o algoritmo deve comportar também fragmentos de via, ou seja, linestrings que não começam no marco zero. A fragmentação pode eventualmente ser recomendada, como no caso de uma estrada como a Anchieta-SP, que sobe a serra: três polinômios distintos (antes, durante e depois da serra) podem modelar melhor do que ajustando-se um só.

Caso geral da obtenção de ID da via e numeração predial

Complemento do algoritmo requisitado pela issue #1. O caso geral tem solução mais precisa no meio rural, onde a probabilidade de "endereço de esquina" é menor.

Referências e estudos de caso

Caberia uma pesquisa mais detalhada, informalmente o algoritmo de numeração predial e pode ser descrito conforme essa discussão de forum:

(What's the correct way of adding house numbers to buildings?)
It depend on how much information you have.
If you know only first and last numbers (or even only one and direction) - you'd probably use interpolation.
If you know that some address is in some building - put node somewhere in it.
...