Referência: precisão de coordenadas conforme latitude

IgorEliezer commented 4 years ago

Pontos principais:

1) O Overpass exporta as coordenadas dos nós com 7 casas decimais (ex.: -49.2582876;-25.4306237); 2) Remover ou adicionar casas do valor latitude tem impacto variável na precisão, pois o comprimento de arco de latitude na linha do equador (latitude 0.0°) é maior que no extremo sul do Brasil (latitude -33,7509025°). 3) Exemplos de comprimento arco de 1º (em km) e de 0.0000001° (em metros) conforme latitude:

0.0° (Macapá) = 111,31949083... km | 0,011131949083 m (~1,11 cm)
-15.7934036° (Brasília) = 107,14367527... km | 0,010714367527 m (~1,07 cm)
-23.5506507° (São Paulo) = 102,10195527... km | 0,010210195527 m (~1,02 cm)
-33.7509025° (extremo sul) = 92.6535775 km | 0,00926535775 m (~0,9 cm) 4) Portanto, no caso da eliminação da 7ª casa de graus decimais levaria a uma perda de precisão de 10x dos valores acima (de 9 a 11 cm). Se da 6ª casa, 100x (92 cm a 111 cm) e assim por diante.

ppKrauss commented 4 years ago

olá @IgorEliezer, boa análise. O levantamento de sensibilidade também assegura que 7 casas está de bom tamanho para os dados brutos do OSM.

Como os mapas oficiais de município não são muito precisos, o erro de centímetros é despresível (podemos chutar que o erro dos limites é da ordem de 10 a 100 metros nos melhores casos). Por outro lado, queremos ir adotando um padrão que seja estável por alguns anos (podemos sonhar com um IBGE mais preciso e disponibilizando seus dados), 6 ou 7 casas está satisfatório para esse horizonte de "futuro melhor".

Que tal a seguinte convenção: os estados da região Sul (PR, SC e RS) ficam com precisão 7 e os demais com precisão 6.

NOTA. O mesmo valeria para a precisão de pontos de endereçamento (idealmente erro da ordem de metro para não interferir em grade quadrada de 3 a 5 metros de lado nas suas células).

Na representação Geohash de endereço, com 10 dígitos já terímaos precisão da ordem de metro. Podemos então deixar todos os estados em 10 dígitos Geohash, ou convencionar 11 dígitos para os estados do Sul e 10 dígitos em todos os demais... Experimente a Praça da Sé (SP/Sampa), Geohash 6gyf4bf1ne neste site.

IgorEliezer commented 4 years ago

Preferiria manter tudo igual, seja 6 ou 7 casas.

Se ao menos houvesse uma significante economia de dados, até justificaria. Não compensa pelas seguintes razões:

Estaríamos adicionando uma inconsistência internamente dentro do projeto e em relação à fonte de dados;
A parte Norte é justamente onde a truncagem/arrendondamento tem mais impacto, pois é onde que o comprimento de arco de latitude é maior.
A parte Norte é muito menos populosa, cerca de 15 a 20% da população.
Não podemos dar sinal que estamos reduzindo precisão, preterindo uma região em favor de outra.

Bateria o martelo para 7 para que tudo seja locável a nível do centímetro, inclusive mobiliário urbano, tais como telefone público, caixa de coleta de correio, lixeira, mastro de bandeira etc. E até pela lei do menor esforço, deixa como está.

Quanto às divisas de municípios, as do IBGE são aproximadas visto que são feitas em mapas de grande escala (e.g. 1:50.000, 1:100.000 e 1:250.000). Um exemplo é a divisa de Laranjal Paulista que revi de forma detalhada conforme levantamento topográfico do IGC-SP na escala 1:10.000 e seguindo a lei. Dá para ver diferença:

E tal como com os endereços, a base geométrica de municípios e eixos de vias poderão passar por um compare+update periódico.

ppKrauss commented 4 years ago

Olá @IgorEliezer Igor, boa analise. As suas afirmações estão corretas: a longitude é a coordenada mais sensível ao número de casas decimais, ou seja, se truncamos ela sofre mais.

Houve um vai-e-vem e algumas duvidas, então postando uma resposta longa abaixo só para ter de onde copiar/colar depois na hora de criar a documentação e justificativas (a comunidade OSM é bem cricri).

A conclusão consensual é simples: arredondar as coordenadas GeoJSON do Brasil inteiro para 6 casas. Fechamos nisso. Vou postar em seguida todos os polígonos para conferirmos.

Ai os pontos de endereçamento, que não são GeoJSON mas Geohash, discutimos amanhã como fica a precisão e facilidade de uso com JOSMS... e também concluimos isso.

NOTA1: troquei Sul com Norte, então inverta a minha sugestão, a proposta seria de ter mais uma casa decimal nas regiões Norte e Nordeste.

NOTA2: antes de gerar outra confusão, sobre coordenadas X e Y, bom retomar nossos padrões. Nas convenções do banco PostGIS e do formato GeoJSON, as coordenadas são x=longitude, y=latitude; no padrão GeoURI e dos aparelhos GPS, segue-se a tradicional x=latitude, y=lingitude. Também bom lembrar das convenções práticas sobre acurácia e precisão em geoprocessamento. Na comunidade OSM a preocupação é a mesma que a sua, com a precisão da longitude, e, neste link da Wiki OSM, descreve-se mais formalmente como cosseno da latitude.

Voltando ao foco,

Podemos dizer então que, pelo padrão GeoJSON, o problema está em truncar a coordenada X... Mas, ao longo do território nacional, quanto de problema teremos?

Aí sim, o problema diminui com a latitude: lá no sul teremos X menos sensível do que no norte... Vejamos um caso real.

O município de Chuí (RS) está na latitude ~33.69° Sul. O município de Uiramutã (RR) está na latitude ~4.6° Norte. Não é grave como na Europa, o cosseno da latitude se mantém próximo de 1 ao longo de todo o Brasil.

Fiz a seguinte consulta SQL no PostGIS:

SELECT municipio, 
       st_distance(pt,pt_dx,true) dm_x, st_distance(pt,pt_dy,true) dm_y, -- em metros
       st_distance(pt,pt_dx) arc_x, st_distance(pt,pt_dy) arc_y          -- em radianos
FROM (
   SELECT municipio, st_point(x,y)  pt,  
          st_point(x+0.000001,y)  pt_dx,  st_point(x,y+0.000001)  pt_dy 
         -- arco de 0.000001 graus, 6a casa decimal
   FROM ( VALUES ('Uiramutã',-60.2791642,  4.6863365),
                 ('Chuí',    -53.4124787,-33.6524136)
   ) as t1(municipio,x,y)
) t2;

municipio	dm_x	dm_y	arc_x	arc_y
Uiramutã	0.11094982	0.11058169	9.99999997475243e-07	9.999999992516e-07
Chuí	0.09275937	0.11091613	1.00000000458067e-06	1.00000000458067e-06

Todos os valores de arco deveriam ser 0.000001, a diferença ajuda a estimar o erro interno do software, que está lá para a oitava casa decimal, e que muda com a latitude. Então, a grosso modo, podemos confiar nas primeiras 6 casas dos resultados métricos (colunas dm_x e dm_y).

Nosso foco é a "diferença em metros" (dm), ou seja, após projeção do arco no plano. A coluna dm_x da tabela já destaca que Uiramutã é mais sensível ao erro do que Chuí. Para estimar o quanto podemos subtrair, "Uiramutã menos Chuí", de onde temos

dm_x_diff = |0.01819045| ~ 0.02
dm_y_diff = |-0.00033443| ~ 0.0003

Conclusão: quando truncamos na sexta casa, a diferença de sensibilidade ao erro entre cidades do norte e do sul, é da ordem de 0,02 metros.

Pergunta que nos fazemos nesta discussão, foco desta issue: nesta ordem de grandeza, valeria usar um critério do tipo
"deixa mais uma casa decimal para a região Norte do país"?

Eu entendo que não, podemos ficar com GeoJSON de em 6 casas decimais no Brasil inteiro e ignorar por hora essa questão de "sensibilidade maior no norte".

PS: é importante 6 casas decimais e não 7 pois, além de não fazer o menor sentido (nem GPS, nem imagem BING, nem mapa IBGE tem essa precisão), poluiria o repositório git com muito mais bytes e muito mais risco de registrarmos um histórico de falsas mudanças (se alguém ao editar ponto ou polígono no OSM muda só 1 cm então não mudou nada).

IgorEliezer commented 4 years ago

Então ficamos tudo com 6 casas.

OSMBrasil / stable

Referência: precisão de coordenadas conforme latitude #21