Exibindo coordenadas e entradas como LatLon ou LonLat?

Estou tentando entender se esse é um problema para outras pessoas ou todas as entradas / saídas devem ser rotuladas para que o usuário não fique confuso e apenas siga em frente?

Eu acho que quase todo mundo o pronuncia como "LatLon".

Quem começou?

É porque está em ordem alfabética em comparação com "LonLat"?

Mapeando Lat e Lon para o plano cartesiano Lon é "x" e Lat é "y", portanto, como dizemos "(x, y)", deve ser dito como "LonLat". E agora para exibição de informações.

A barra de status em um aplicativo de mapeamento deve exibir La, Lo ou Lo, Lat?

Deve apenas ser rotulado como uma maneira e deixar o usuário lidar com isso?

E mesmo com a entrada, qual é o caminho certo para solicitar os campos?

O formato do KML é Lon, Lat, Altitude. Enquanto outros aplicativos são Lat, Lon e, portanto, devem ser muito vigilantes ao converter formatos.

Existe um padrão?

Você deve dar uma olhada no padrão ISO 6709. Aqui está a entrada da Wikipedia: ISO 6709

O item principal é que a ordem deve sempre ser a latitude longitude.

A latitude vem antes da longitude

[edite agora que tenho uma cópia do 6709: 2008]

Para troca de dados, use DD, mas para compatibilidade com versões anteriores, sexagesimal é válido.

Há uma seção chamada "As coordenadas de latitude e longitude não são únicas", completas com a figura.

Há uma redação muito forte sobre a ordem de coordenadas para exibição (não intercâmbio). Ele diz que os navegadores tradicionalmente usavam a ordem de longitude de latitude e que a alteração da ordem poderia comprometer a segurança. Use sexagesimal, símbolos de direção em vez de +/-, etc. Os valores Z seguem a longitude. Os valores da grade / planar devem usar a ordem especificada na definição do CRS.

34 ° 05'09,76 "N 117 ° 02'01,23" W 829,1m

(Hah! Comecei a escrever uma amostra e escrevi automaticamente o valor da longitude primeiro)

Representar uma posição em um globo requer não dois, mas três valores, que na Terra são geralmente representados por (latitude, longitude, elevação). Os computadores geralmente trabalham em espaços cartesianos, assim como nossos mapas em papel, que são mais fáceis de entender como coordenadas (x, y), daí o conflito.

A ordenação seguiu alguma convenção histórica para coordenadas esféricas, que mapeiam as coordenadas geográficas da seguinte maneira:

geographic spherical   symbol
---------- ---------   ------
longitude  azimuth       φ
latitude   inclination   θ 
elevation  radius        r

A ordem comum de (r, θ, φ) (um padrão ISO na comunidade de física, embora não seja estabelecida em outro lugar ) simplifica para (θ, φ) quando você assume que estamos trabalhando em uma esfera unitária e, portanto, (latitude, longitude).

Como um GIS é implementado em um ambiente que usa coordenadas cartesianas no restante do sistema, ficamos com um pouco de conflito . Eu acho que a questão principal é deixar claro o que você está usando e cumpri-lo.

Pessoalmente, prefiro as unidades cartesianas por causa de sua semelhança em outros lugares e, embora as conexões acadêmicas com coordenadas esféricas não devam ser esquecidas, não é a opção pragmática ao implementar novos sistemas. O formato (x, y) é usado internamente na maioria dos formatos de arquivos espaciais, como WKT, Shapefiles, GeoJSON e similares - mas se você estiver apresentando dados para um público leigo, o que é certo depende do que é mais fácil para eles entenderem .

As duas respostas anteriores já cobrem a história, aqui estão apenas meus dois centavos sobre os padrões:

Para fins de troca de dados, a ordem das coordenadas é determinada pela escolha do CRS , conforme promovido pelo OGC em sua Nota de orientação da política de pedidos do eixo .

Se você observar atentamente, qualquer EPSG CRS especifica a ordem dos eixos, que devem ser respeitados em qualquer carga útil marcada para usar o CRS. Por exemplo, qualquer coisa que publique dados em epsg: 4326 (WGS 84 geográfico 2D) deve ter coordenadas expressas como (lat, lon). Você pode verificar o registro EPSG (pesquise o código 4326 e procure em Ellipsoidal CS / Axes).

Outra maneira amplamente usada de especificar o CRS é o Projection WKT (seção 7; também disponível aqui ), que também prescreve o pedido. Por exemplo

...
AXIS["Lat",NORTH],
AXIS["Lon",EAST],
...

Os parâmetros do AXIS são opcionais, no entanto, e os padrões, de acordo com esta especificação, são

AXIS["Lon",EAST],AXIS["Lat",NORTH].

isso torna toda a questão bastante confusa, porque significa que muitos arquivos .prj por aí referenciando epsg: 4326 ( por exemplo, o de spatialreference.org ) que não especificam explicitamente a mesma ordem de eixo que o EPSG, mas mesmo assim referencia o Código EPSG, estão em conflito com a nota de orientação do OGC.

Este é um problema comum, aqui está outra discussão anterior:

• Por que alguns sistemas de coordenadas definem o eixo x como norte e outros como leste?

Há uma discussão muito exaustiva em http://wiki.osgeo.org/wiki/Axis_Order_Confusion

@wwnick forneceu as informações acima como um comentário a uma pergunta duplicada

Isso representou um grande problema para mim durante anos no AutoCAD 2D, agravado pelo fato de o autocad ler ângulos no sentido anti-horário com 0 graus, começando na posição 90d. Por um tempo, gostei de acreditar que o havia resolvido alterando o UCS de modo que x se tornasse norte e leste. Enquanto eu continuava produzindo planos de propriedades 2D, nunca consegui enfrentar meu erro: o eixo z estava apontado na direção errada.

É claro que o texto da minha dimensão costumava ser lido da direita para a esquerda, mas achei que era um preço pequeno a pagar pela leitura correta dos ângulos e mais ao ponto, colocando x e y em seus lugares intuitivos (conforme Northing / Easting, Lat./Lon convenções). Então me formei no Autocad Civil 3d e tentei executar o truque novamente e fiquei cara a cara com a linha de fundo: y é norte / lat ex x é leste / longo. Aceite isso.