緯度と経度のタプルを記述する優先順序
GISソースコードを扱う場合、緯度と経度の座標の組を記述する必要があります。
例えば。 Googleマップのリンク（123、456）：
どちらが優先順序ですか（そして、なぜですか？）
緯度、経度
経度、緯度
私は両方がさまざまなシステムで使用されているのを見てきましたが、他のシステムに固執する証拠を見つけたいと思っています。
EPSG：4326は、座標の順序は緯度、経度でなければならないことを具体的に述べています。多くのソフトウェアパッケージは、依然として経度と緯度の順序を使用しています。この状況は、プロジェクトの期限とプログラマーの健全性に想像を絶する混乱をもたらしました。
提供できる最良のガイダンスは、ソフトウェアスタック内の各コンポーネントの予想される軸の順序を完全に認識することです。 PostGISはlng/latを期待しています。 WFS 1.0はlng/latを使用しますが、WFS 1.3.0は標準に従い、lat/lngを使用します。 GeoToolsのデフォルトはlat/lngですが、システムプロパティでオーバーライドできます。
問題の履歴と説明に関するGeoToolsのドキュメントは、読む価値があります。 http://docs.geotools.org/latest/userguide/library/referencing/order.html
正しい順序は、従来の数学（つまり、f(x ,y, z)）のように、ほぼすべてのプロフェッショナルなGISアプリケーションでの経度と緯度です。 GeoJSON標準は非常に典型的で簡潔です：
The order of elements must follow x, y, z order
(easting, northing, altitude for coordinates in a
projected coordinate reference system, or longitude,
latitude, altitude for coordinates in a geographic
coordinate reference system).
同じことが、主要なOpen Geospatial Consortium標準（WKTとWKB、およびEWKBなどの拡張）にも当てはまります。同様に、GoogleはLat/Lonで注文を出力して、そのカスタムで育ったユーザー（つまり、計算標準ではなくIMOのようなナビゲーション標準から）に慣れるようにします。しかし、KML標準自体は他のすべてのGISシステムに似ています。
The KML encoding of every kml:Location and coordinate
Tuple uses geodetic longitude, geodetic latitude, and
altitude (in that order).
良い経験則：Tupleが何であり、プログラミングしていることがわかっている場合は、lon、latを使用する必要があります。これは、エンドユーザー（パイロットや船長など）がlat、lonの出力を表示することを希望する場合にも当てはまります。必要に応じてUIで順序を切り替えることができますが、圧倒的多数のデータ（シェープファイル、ジオイソンなど）は通常のデカルト順序になります。
「実生活」の慣例により、位置を指定する場合、緯度（つまり北/南）は常に1番目に与えられます。 20°N 56°W（ただし、標準のデカルトグリッドについて考えると、これは通常の規則に従いません）。同様に、ウィキペディア上のすべての座標はこの規則に従います（たとえば、サウサンプトンの場所を参照してください： http://en.wikipedia.org/wiki/Southampton ）。混乱を避けるために、特にユニットが含まれていない場合は、タプルの緯度を1番目にすることを常にお勧めします。
個人的には緯度に続いて経度以外は見たことがありません。
また、NとSの代わりに+と-を使用する場合、常に+がNで、-がSです。
EとWに+と-を使用すると、変動が見られます。一般に、+はEで、-はWです。ただし、古い経度のアプリケーションでは、W経度を圧倒的に扱っていました。 。
できれば、古いアプリケーションを扱う必要はないでしょう。
したがって、優先順位は個人の好みに依存します！
緯度が最初になりました。 「太陽が赤道を横切る日」として、彼岸は千年紀で知られています。 3月にSからNに交差し、9月にNからSに交差します。唯一の問題は、赤道が0度または90度であったかどうかでした。 0度をとることで、垂直と正午の正午の太陽の天頂との間の角度は、地球上のあらゆる場所の緯度です。プライムラティチュード、またはプライムパラレルは効果的に定義されます。
経度は合意によってのみ可能です。英国は経度賞を出しました。英国は、自分たちがどこにいるかを知るために船を必要とし、より良い地図を必要としていました。 Harrison（ http://www.youtube.com/watch?v=T-g27KS0yiY ）は正確なマリンクロノメーターを作成しました。彼らは、たとえばジェームズクック1770のような地図作成の旅を送りました。したがって、英国はグリニッジを地図の000度として使用して、子午線を主張しました。 100年の使用後、1884年にプライム子午線は国際的に受け入れられました。
クリストファー・コロンブスの時代には、彼らが持っていた唯一の数字は緯度でした。戦略は、目的地に向けて左または右に曲がる前に平行線を横断することでした。雲や鳥を監視しています。 1時間ごとにノットで速度を測定することは一般的でしたが、電流を考慮しませんでした。おそらくコロンバスの最大の功績は、西インド諸島から4回帰国したことです。それなしでは、彼が発見した土地をマップに追加することはできませんでした。
Dava Sobelの「Longitude」を読んでください（ISBN：9780007214228）
他の人がすでに言及しているGeoJSON仕様とは別に、経度、緯度の順序が推奨される、さらには必須である他の実用的なケースがあります-例： MongoDBの地理空間インデックス 。そこで間違った順序を取得すると、転置されたデータセットを再度実行したかのように、クエリは間違った結果を返します。
ISO 6709は、安全上の理由から、注文を緯度、経度としてリストすることを標準化しています。上記のGrahamの説明も私には正しいように聞こえます。誰かがこの答えは質問に関連していないことを示唆しました-それは絶対にあり、順序がしばしば緯度、経度として与えられる理由を説明します。
これは、どのように長いナビゲーターがシステムを使用していたとしてもリストされている方法です。これを変更すると混乱を招き、ISOが示唆するように、潜在的に危険です。 ArcMapなどのGISソフトウェアは、x、y座標ペアの一般的な規則であるため、それらを逆にリストします。緯度はy、経度はxであるため、Arcはそれらをリストします。
経度、次に緯度（経度、緯度）。
メルカトル図法に投影すると、経度がx方向を定義し、緯度がy方向を定義します。ほとんどのジオメトリライブラリは、この形式（lon、lat）を厳密に使用します。これは、2D平面の地理座標を考える最も直感的な方法だからです。