osm-codes/co_new

Colombian Hierarchical Grid

co_new's Issues

Rever cobertura para acomodar direções entre celulas da cobertura base32

Para que o algoritmo das vizinhanças funcione, é necessário que a maior parte delas sejam naturais da curva Z, demandando um menor número possível de correções pelo algoritmo de direção baseado em string. Sugestão centrando no "9" atual:

A escolha só precisa ser consistente na base32... Ideal centrar em S conforme ilustrado abaixo,

... Mas aqui repetimos outro erro, que é a alternancia entre grades par e impar com relação ao número de dígitos:

Interface ainda não aceita URN Lex na raiz

exemplo http://osm.codes/urn:lex:br;rio.grande.sul

Esclarecer a lacuna de mar territorial

Apenas explicar na documentação que o buffer do mar territorial pode variar de largura, de modo que a remoção do pequeno trecho não é significativa. E, principalmente, é "alto mar", não compromete a demarcação nem a fronteira com outros países. Abaixo a ilustração com rótulos base32 das células vizinhas da lacuna.

Lower the grid a few kilometers

The X quadrant of coverage is the top candidate for removal, in a good example of how minor tweaks can lead to big gains.

Limits and adjustments

By shifting the grid downwards, we would leave out one end of the C quadrant:

The limit for the maneuver (shifting) is a little more than ~10 km.

Conclusion:

1. We can eliminate X quadrant, shifting ~1 km.
2. We must to check the T quadrant, if it is possible to shift more, something from ~10 km to ~20 km.
3. The Y quadrant will remain.

We can assume that the limit is 15 km on C quadrant:

Checked

The T quadrant, and the ~20 km of "leak": seems that will be not possible to remove this quadrant,

---

Notes

At Y quadrant, ~30 km of "leak":

Click the image to check the values (must round to the integer part). The red box shows the general limits — from which we can also calculate the height and width.

Right and left sides:

• at right side the quadrants 5 and 8 are tight, but the sea has no address to be represented by the grid-cells, and no "political border conflict".
• at left side, the S quadrant has a good distance-gap, ~30 km.

Não mostrar código base32 absoluto

O código base32 absoluto causa grande confusão pela mudança de dígito na indexação. Na popup do exemplo, CO-RIS-Dosquebradas~15NTJ, melhor expressar:

• Municipio: RIS-Dosquebradas
• postal code: 15NTJ
• grid code: (base16h code)
• area, side, etc. ok

A visão do código absoluto só é util como "evidência de teste" para comprovar que mudanças territoriais não afetariam a geocodificação, exceto seus prefixos nas zonas impactadas por mudança. Precisa aparecer na interface apenas quando solicitada.

Nas explicações precisaria de destaque, 15NTJ na verdade tem 1 como "cover-index code" e 5NTJ como "base32 location suffix". Só este último que não corre risco de sofrer impacto nas mudanças territoriais.

¿Existe un SRID estándar?

¿El "Sistema de Proyección Único para Colombia" también es un estándar internacional?

Por ejemplo, EPSG:3115 seems not parece que no, pero confirmes aquí Luis que no existe.

Si no existe: defina un SRID pseudoestándar en esta biblioteca pública,
https://github.com/AddressForAll/pg_pubLib-v1/blob/main/src/pubLib05pgis-extraSRID.sql

---

(original English deprecated)

The "Sistema de Proyección Único para Colombia" is also an international standard?

For example EPSG:3115 seems not, but please confirm here that it not exists.

If not exists: please define a pseudo-standard SRID at this public library,
https://github.com/AddressForAll/pg_pubLib-v1/blob/main/src/pubLib05pgis-extraSRID.sql

Municipios ou areas sem cobertura

Os municípios Colombianos a seguir não constam na base de dados e, assim, não estão cobertos.

Muzo: https://www.wikidata.org/wiki/Q1431785
Marapí: https://www.wikidata.org/wiki/Q1574705
San Pablo de Borbur: https://www.wikidata.org/wiki/Q1575910

Motivo provável: dado ruim no OpenStreetMap na época da importação. Hoje, parecem estar com as geometrias corretas.
Próxima atualização trará esses dados.

A area https://www.openstreetmap.org/relation/1554330 não está coberta. Não pertence a nenhum município.

Ilhas não estão cobertas. Verificações em https://wiki.addressforall.org/doc/dg_talk:Stable#Bugs_de_2023-06 podem determinar qual o identificador da relação no OpenStreetMap.

API e URLs da Colômbia

Caso geral previsto e documentado no projeto WS, ver:

• WS/docs/en/osmCodes-geocode_spec.md

• WS/docs/en/index.md

Tratamento do nome da capital, CO-DC

O geocódigo ISO CO-DC precisa ser implementado como sinônimo de CO-DC-Bogota (canônico) ... Ou o inverso já que DC é mais curto e igualmente oficial.

Introduzir abreviações para os códigos postais e permitir hifem

Está pendente trazer as abreviações da Colômbia e publicar a lista de-para dessas abreviações a cada departamento.

Uma vez legitimadas as abreviações, elas podem ser tratadas como "oficiais do código postal". Assim as referências em nome seriam sempre reduzidas na URL a referências em abreviação.

Quanto ao so do hifem , "-", no lugar de "~", atualmente podemos referenciar cidades através do nome, por exemplo CO-RIS-Dosquebradas-15NTJ ou através de DIVIPOLA (jurisd_local_id), CO-66170-15NTJ, e ambos retornam o canônico (com "~").

Na interface mostrar cobertura municipal indexada por default

A orientação ao contexto já é uma diretiva... Então enfatizar o código indexado será o mais natural a fazer na interface.

Por exemplo em http://osm.codes/CO-ANT-Medellin no modo "with cover" ao invés de mostrar rótulos de grade absoluta,
mostrar já os rótulos de 1 dígito da indexação. Queremos enfatizar o município, o usuário não quer saber de nada fora do município quando o escopo é o geocódigo postal (base32).

• no lugar de 8VR usar 2 ou ~2
• no lugar de 9K2 usar 8 ou ~8
• no lugar de 9K0 usar 6 ... etc

Alias todos os rótulos de geocódigo postal podem ser ~XX e só quando clica aparece CO-ANT-Medellin~XX.

Interface mostra área errada

A escala mostra que o tamanho de lado está correto mas a área tem 2 dígitos a mais.

Interfaces de teste e produção

Ver diretivas gerais do OSM.CODES em osm-codes/WS#12

Cobertura L0 em células 512 kim

Considerando apenas parte continental:

Imagem mostrando grid, com células que compõem a cobertura em 512 kim sendo destacadas.
A referencia do canto inferior esquerdo é 4200000,970000:

Imagem mostrando a cobertura L0 exibindo o código da célula em base16h. A ordem atribuída foi de cima para baixo e da esquerda para direita:

Imagem mostrando as distâncias mínimas e aproximadas entre a jurisdição e os lados mais externos das células que compõem a cobertura:

O código utilizado para gerar view foi:

DROP SCHEMA IF EXISTS newgridco CASCADE;
CREATE SCHEMA newgridco;

DROP VIEW newgridco.jurisd;
CREATE VIEW newgridco.jurisd AS
SELECT *
FROM optim.vw01full_jurisdiction_geom g
WHERE isolabel_ext = 'CO'
;

-- matriz retangular com 3 colunas e 4 linhas.
-- referencia: canto inferior esquerdo,
-- nível: l0 524288 metros
DROP VIEW IF EXISTS newgridco.grid_co CASCADE;
CREATE VIEW newgridco.grid_co AS
  SELECT lpad((j*10+i)::text,2,'0') AS ij,
         (j*10+i) AS ij_int,
        osmc.ij_to_geom(i,j,4200000,970000,524288,9377) as geom
  FROM generate_series(0,3) as j, generate_series(0,2) as i
;

DROP VIEW IF EXISTS newgridco.L0cover_cell512km_new;
CREATE VIEW newgridco.L0cover_cell512km_new AS
SELECT gid,
       ij,
       ij_int,
       lower(vbit_to_baseh(gid::bit(4),16,0)) AS base16h,
       geom
FROM
(
  SELECT ROW_NUMBER() OVER(ORDER BY ij_int/10 DESC, ij_int%10 ASC) as gid,
         ij,
         ij_int,
         geom
  FROM newgridco.grid_co
  WHERE ST_Intersects(geom, (SELECT ST_Transform(geom,9377) FROM newgridco.jurisd WHERE isolabel_ext='CO') )
) r
;

As imagens foram geradas a partir do software QGIS. Este pequeno guia mostra como visualizar no QGIS um POSTGIS remoto. O schema utilizado para gerar essa nova cobertura foi newgridco na base dl03t_main.

Issues e wiki's relacionadas ao assunto:

• https://github.com/osm-codes/CO_new/wiki/Estudo-sobre-nova-cobertura
• #6

Usar a fonte FE-Schrift na interface de mapa ou apresentação do geocódigo

A fonte tipográfica utilizada nas placas de carro do Mercosul, FE-Schrift, é comprovadamente mais legível (para humanos e computadores), evitando ambiguidade entre letras. Quando se tratar de geocódigo misto (p. ex. CO-MAG-SantaMaria~3T6L-L1K), usar, como na placa, o prefixo nominal (CO-MAG-SantaMaria) com tamanho de fonte menor (de 50% a 75%).

Abaixo a comparação do uso da fonte apenas no final do geocódigo, e no geocódigo inteiro, com ou sem ponto de separação — tendo em vista que a fonte não oferece representação de letras minúsculas.

Em mapas ou interfaces de apresentação de pontos pode-se adotar a expressão sem o "~", em duas linhas:

Em placas de numeração predial, onde o contexto é certo e conhecido, pode-se omitir o contexto ou fazer uso do geocódigo absoluto, por exemplo BR~123-XY234Z.

Todos os símbolos (glifos) da fonte e seu uso típico nas placas de automóveis do Mercosul:

Caja de cuadrícula, definir

En la secion sobre Proyección adoptada ilustramos la "Caja de cuadrícula", pero no es una proposta final. Es necesario refinar: pendente definir los parametros de la caja:

• El origem, (x0,y0) de la caja.
• El tamaño del lado de lo cuadrado en miles de km

los valores son relativamente arbitrarios, se pueden redondear.

---

La imagen actual es incorrecta, es solo un boceto ilustrativo. Aquí vamos a definir mejor.

Códigos absutos da base16h na interface teste

Os códigos postais e mais populares são base32, já temos por exemplo CO~12345 como geocódigo absoluto da Colômbia. Para se ter acesso a todos os níveis da grade, necessário em aplicações estatísticas e científicas, é oferecida também a base 16h.

Sintaxe: CO+12345

O nível zero da base 16h fará uso de 2 dígitos, representando as coordenadas ij da matriz de células e conforme ordem dos eixos no sistema de coordenadas da projeção.

---

Notas

• ver diretivas deste comentário.
• Planilha da métrica dos níveis
• Simulações da base 16h

Tornar a base 16h padrão nas descrições de coberturas

Inicialmente, coberturas foram definidas em base32.

Ajustar o necessário para base16h ser utilizada. No processo, lembrar da existência de fantasmas.

Mostrar Jurisdição recordata por subdivisão nominal

Exemplo https://osm.codes/CO-ANT-Itagui-O deceria retonar a célula Oeste recortada por Itagui.

Interface de cobertura municipal parou de funcionar

Não funciona com Óbitos nem BR-SP-SaoCaetanoSul mas funciona com Campinas e Medellin... Mas Óbitos e SaoCaetanoSul estão gerando geocódigo curto

Risc of change from old GRS 80 to WGS84?

The GRS80 was adoted by IGAC and implemented in our code as the "official near-equal-area projection of Colombia"... But, as commentd at Wikipedia,

The GRS 80 reference system was originally used by the WGS 84. The reference ellipsoid of WGS 84 now differs slightly due to later refinements.

So, please check with Colômbia (IGAC or other) if some plans to change from the old GRS80 to the modern and most popular WGS84.

Documentar as vantagens sobre concorrentes

Demonstrar cada uma das vantagens

---

• A base32 garante matematicamente maior compressão do que a base20 do OLC
• Preserva a área da célula (e sua forma - retangular ou quadrada) em todo o território nacional da Colômbia.
• Preserva a hierarquia: se células possuem mesmo prefixo então certamente serão vizinhas,
• Os "códigos curtos" contextualizados pelo nome da cidade, são mais curtos no OSMcodes do que no PlusCodes.
• Os "códigos curtos" respeitam as fronteiras exatas de cada município, e em conformidade com dados abertos.
• ...