LatLonまたはLonLatとして座標と入力を表示しますか？

これが他の人にとっての問題なのか、それともユーザーが混乱しないようにすべての入力/出力にラベルを付ける必要があるのか​​を理解しようとしていますか？

ほとんどの人が「LatLon」と発音していると思います。

誰が始めたの？

「LonLat」と比較してアルファベット順だからでしょうか？

LatとLonのデカルト平面へのマッピングLonは「x」、Latは「y」です。したがって、「（x、y）」と言うので、「LonLat」と言う必要があります。そして今、情報の表示のために。

マッピングアプリケーションのステータスバーにLa、LoまたはLo、Latを表示する必要がありますか？

それはただ一つの方法としてラベル付けされ、ユーザーがそれに対処する必要がありますか？

入力と同じように、フィールドを順序付ける正しい方法は何ですか？

KMLの形式はLon、Lat、Altitudeです。他のアプリはLat、Lonですが、フォーマットを変換するときは非常に注意する必要があります。

標準はありますか？

ISO標準6709をご覧ください。ここにウィキペディアのエントリがあります：ISO 6709

主な項目は、順序は常に緯度経度でなければならないということです。

緯度は経度の前に来る

[今、6709：2008のコピーを持っているので編集]

データ交換にはDDを使用しますが、下位互換性のために、六十進法は有効です。

「緯度と経度の座標は一意ではありません」と呼ばれるセクションがあります。

表示の座標順序（交換ではない）について非常に強力な文言があります。ナビゲーターは伝統的に緯度経度の順序を使用しており、順序を変更すると安全性が損なわれる可能性があると述べています。+/-などではなく、六十進法、方向記号を使用します。Z値は経度に従います。グリッド/平面の値は、CRS定義で指定された順序を使用する必要があります。

34°05'09.76 "N 117°02'01.23" W 829.1m

（ハハ！サンプルを書き始め、経度値を最初に自動的に書きました）

地球上の位置を表すには、2つではなく3つの値が必要です。これらの値は、一般に（緯度、経度、標高）で表されます。通常、コンピューターはデカルト空間で動作します。紙の地図も（x、y）座標として理解しやすいため、競合が発生します。

順序付けは、球座標のいくつかの歴史的な慣習に従い、次のように地理座標にマッピングされます。

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

（r、θ、φ）（物理学コミュニティのISO標準ですが、他の場所で解決されていませんが）の一般的な順序付けは、単位球で作業していると仮定すると（θ、φ）に簡略化されます。経度）。

GISは、システムの残りの部分全体で使用されるデカルト座標を使用する環境で実装されるため、少し競合が残ります。重要な問題は、使用しているものを明確にし、それに固執することだと思います。

個人的にはデカルト単位が好まれるのは、他の場所での共通性のためであり、球面座標への学術的なつながりは忘れられないが、新しいシステムを実装する際の実用的な選択ではない。（x、y）形式は、WKT、Shapefiles、GeoJSONなどのほとんどの空間ファイル形式で内部的に使用されますが、一般の聴衆にデータを提示する場合、正しいのは理解しやすいものに依存します。

前の2つの答えはすでに歴史をカバーしていますが、ここに標準に関する私の2セントがあります。

データ交換の目的で、座標の順序はCRSの選択によって決定されます。これは、OGCのAxis Order Policy Guidance Noteで推奨されています。

よく見ると、EPSG CRSは軸の順序を指定します。これは、CRSを使用するようにマークされたペイロードで尊重される必要があります。たとえば、データをepsg：4326（WGS 84地理2D）で公開するものはすべて、（lat、lon）として表される座標を持つ必要があります。EPSGレジストリを自分で確認できます（コード4326を検索し、Ellipsoidal CS / Axesの下を見てください）。

CRSを指定するために広く使用されているもう1つの方法は、Projection WKT（セクション7。こちらも参照）です。これも順序を規定しています。例えば

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

AXISのパラメータは、本明細書によれば、デフォルト値がオプションであり、そして

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

4326（：それは.PRJの多くはそこに参照EPSGファイルということを意味するので、これは、全体の問題はかなり混乱します例えばspatialreference.org上の1）を明示的EPSGと同じ軸順序を指定し、それにもかかわらず、参照していません。 EPSGコードは、OGCガイダンスノートと矛盾しています。

これはよくある問題です。以前の別の議論は次のとおりです。

• 一部の座標系でx軸を北距として定義し、他の座標系を東距として定義するのはなぜですか？

http://wiki.osgeo.org/wiki/Axis_Order_Confusionで非常に徹底的な議論があります

@wwnickは、上記の情報を重複した質問へのコメントとして提供しました

AutoCAD 2Dでは、autocadが90dの位置から開始して0度の角度を反時計回りに読み取るという事実により、長年にわたって大きな問題を引き起こしていました。しばらくの間、xが北になりyが東になるようにUCSを変更して解決したと信じていました。2Dプロパティプランを作成し続けている限り、実際にエラーに直面することはありませんでした。z軸が間違った方向を向いていました。

もちろん、私の寸法テキストは通常​​右から左に読んでいたが、正しい角度の読み取りのために払うのは少額の価格であると感じ、xとyを直感的な場所に置いた（Northing / Easting、Lat。/ Lonのように） 。規約）。次に、AutoCAD Civil 3dを卒業し、もう一度トリックを実行しようとして、最終結果に直面しました。yは北/緯度、xは東/長です。それを受け入れます。