GISサービスでの緯度と経度のタプルの優先順位


144

GISソースコードを扱う場合、緯度と経度の座標タプルを記述する必要があることがよくあります。

例:Googleマップのリンク(123、456):

http://maps.google.com/maps/ms?msid=214518704716144912556.00046d7689a99e95b721c&msa=0&ll=123,456&spn=0.007996,0.026865

どちらが好ましい順序ですか(そしてその理由は?)

  • 緯度、経度

  • 経度、緯度

両方がさまざまなシステムで使用されているのを見てきましたが、他のシステムに固執する証拠を見つけたいと思っています。

標準的な方法はありますか、ある場合、それは何ですか/それらは何ですか?


2
優先順位の代わりに、ケースのコンパイルを確認できます:macwright.org/lonlat
golimar

3
これのlatitude, longitudeために
onmyway133

1
この質問は、プログラミングではなく地理に関するものなので、締めくくります。また、意見に基づく質問でもあります。
TylerH

1
@MikkoOhtamaa違いは、特定の技術仕様に必要な順序(オフサイトのドキュメンテーション情報の要求と同じようにトピックから外れる可能性が高い)ではなく、「推奨される」方法についての質問ではないということです。 【で一般的に ]。あなたが尋ねた人と使用の目的/コンテキストに基づいて好ましい変更は何ですか?ここでの答えが示しているように、どちらの順序にも実質的なフォローがあります。その後、プログラミング関係の問題はまだ完全に対処されていません。
TylerH

1
@MikkoOhtamaaスタックオーバーフローに関するGISの質問に問題はありません。これはGISの質問ではありません。それは「緯度/経度をどのように注文すればよいか」という質問です...求めている特定のGISアプリケーションさえありません。この質問はまだ意見に基づいており(「推奨される方法」を尋ねる質問は意見に基づいています)、広すぎます(どのコンテキスト、シナリオ、またはアプリケーションを求めていますか?回答が示すように、これらの基準に基づいて異なります)。プログラミングについてではありません(緯度と経度はプログラミング用語ではなく地理用語です)。
TylerH

回答:


210

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


6
なぜこれがうまくいくのを述べているSO.comの回答として私はめったに見ません。「MongoDBがそれを使用しているため」これらの回答からがらくたを打ちます。
Mikko Ohtamaa

1
あなたのリンクはあなたに同意しません。EPSGデータベースでは、4326は(緯度、経度)軸順の地理的CRSにマップされます。ただし、フィールドのほとんどのソフトウェアはEPSG:4326を(経度、緯度)軸順の地理的CRSとして理解します。これは、従来のOGC仕様がそのように設計されているためです。
アーロン・マクバー

7
私の回答の最初の2文:EPSG:4326は、座標の順序は緯度、経度でなければならないことを具体的に述べています。多くのソフトウェアパッケージは、依然として経度、緯度の順序を使用しています。それはまったく同じではありませんか?
シェーン

5
他の誰かがGoogleマップで問題があり、それにKMLファイルを提供している場合、順序は経度/緯度です。KMLファイルのドキュメントにこれが記載されていません!!
Turnerj 14

2
「KMLファイルのドキュメントにこれが記載されていません」は正しくありません。developers.google.com/kml/documentation/kmlreference#point "経度、緯度、高度の浮動小数点値(この順)で構成される単一のタプル。"
tmcw 2018年

28

優先される順序は慣例によるものlatitude, longitudeです。これは、ここで 報告されているように、おそらく国際海事機関によって標準化されたと思われます。Googleは、マップ地球でもこの順序を使用しています。のアルファベット順を考えると、この順序を覚えていますlatitude, longitude


12
KMLファイルを除きます。座標はlng、lat、altとして保存されます。おそらくそれがx、y、zに変換できるためです
Wouter van Nifterick 2013年

23

正しい順序は、従来の数学(つまり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).

経験則:タプルとは何かを知っていて、プログラミングしている場合は、、を使用する必要がlonありlatます。私も自分のエンド・ユーザーが出力を表示することを好むだろう(パイロットや船の船長が言う)場合、これが適用されると言うでしょうlatlon。必要に応じてUIで順序を切り替えることができますが、データの大部分(シェープファイル、geojsonなど)は通常のデカルト順序になります。


4
私はここにいくつかの意見の相違を見ます:私は2つの選択肢を選びます-多すぎます!
Mikko Ohtamaa 2011

6
読者は、ISO 6709は、どのUIでも常に[lat、lon]形式を使用する必要があることを明示的に示しており、推論されているように、単に個人的な好みの問題ではないことに注意してください。
Iain Collins

9

「実生活」の慣例により、位置を指定する場合、緯度(つまり、北/南)は常に1番目、たとえば20°N 56°Wになります(ただし、標準のデカルト座標系について考える場合、これは通常の慣例に従っていません)グリッド); 同様に、ウィキペディアのすべての座標はこの規則に従います(例:サウサンプトンの場所:http : //en.wikipedia.org/wiki/Southamptonを参照)。混乱を避けるために、特にユニットが含まれていない場合は、緯度をタプルの1番目に指定することを常にお勧めします。


9

個人的には、緯度に続いて経度以外に何も見たことがありません。

また、NとSの代わりに+と-を使用すると、常に+がNで、-がSになります。

+と-をEとWに使用した場合の変動を観察しました。通常、+はEであり、-はWでした。ただし、W経度を扱いすぎている古いアプリケーションでは、+がWであり、-がEであることを確認しました。

うまくいけば、古いアプリケーションを扱う必要がないでしょう。


世界中のアプリケーションで作業しているときに簡単に観察できます。
Daniel Antunes Pinto

経度と緯度の座標の任意のペアをGoogleマップに入力するだけで、それが(long、lat)として解釈されることがわかります(その逆ではありません)。これは、非常に広く使用されているシステムの例です。
cazort 2017

2
@cazortなんらかの理由で、ここでは発生しません。たとえば、オレゴン州ユージーンの私の故郷は、およそ北44.1、西123.1です。maps.google.comで44.1 -123.1と入力すると、ユージーンに行きます。-123.1 44と入力すると、見つからないことがわかります。興味深いことに、123.1 W 44 Nと入力すると、それがわかり、ユージーンに行くので、ある程度の柔軟性があります。また、reference.com / technology /…は、lat / longが優先順序であることを示しているようです。また、その価値があるため、Google Earthでは緯度/経度を使用しています。
テリー


5

したがって、優先順位は個人の好みによって異なります。

緯度が最初に来ました。春分は「太陽が赤道を横切る」日として千年紀の間知られていました。3月にSからNに、9月にNからSに渡ります。唯一の問題は、赤道を0度にするか90度にするかです。0度をとることにより、分点における垂直と正午の太陽天頂の間の角度は、地球上のあらゆる場所の緯度です。素数の緯度、または素数の緯線が効果的に定義されています。

経度は合意によってのみ可能です。英国は経度賞を上げました。英国は、船がどこにいるかを知る必要があり、より良い地図が必要でした。ハリソン(http://www.youtube.com/watch?v=T-g27KS0yiY)が正確な海洋クロノメーターを作成しました。彼らはジェームズクック1770のような地図作成の航海の旅を送りました。そのためイギリスは、グリニッジをマップの000degとして使用することにより、子午線を主張しました。100年の使用期間を経て、本初子午線は1884年に国際的に受け入れられました。

クリストファーコロンバスの時代には、Latitudeが唯一の数でした。戦略は、目的地に向かって左または右に曲がる前に平行線を横断することでした。雲や鳥を監視しています。毎時ノットで速度を測定することは一般的でしたが、電流を考慮していませんでした。おそらく、コロンバスの最大の成果は、西インド諸島から4回家に帰ることでした。それがなければ、彼が発見した土地は地図に追加できませんでした。

Dava Sobelによる「経度」を読む(ISBN:9780007214228)


1
私は彼がプログラム的におよび技術的な参照を意味することを意味すると思います(しかし、私は間違っている可能性があります)。しかし、歴史の授業は面白かった。
jww 2014

1
これは質問とは関係ありませんが、間違いなく興味深いものです。ありがとう:)
Mikko Ohtamaa 14

ただし、マップ座標のみを使用する場合は、X、Yのように経度、緯度の順になることは間違いありません。混乱が存在するのは、何百年にもわたって、あらゆる場所で緯度、経度が言われている(そして聞こえている)ためです。
Antti Haapala 2014

5

ISO 6709では、安全上の理由から、注文を緯度、経度としてリストに標準化しています。上記のグラハムの説明も私には正しいようです。誰かがこの回答は質問に関連していないことを示唆しました-それは絶対にあり、なぜ順序がしばしば緯度、経度として与えられるのかを説明しています。

これは、長いナビゲーターがシステムを使用してきたにもかかわらず、リストされている方法です。これを今変更すると混乱を招き、ISOが示唆するように、潜在的に危険です。ArcMapのようなGISソフトウェアは、x、y座標ペアの一般的な規則であるため、逆にリストします。緯度はy、経度はxなので、Arcはそれらをリストします。


1

経度の次に緯度(経度、緯度)。

メルカトルに投影すると、経度はx方向を定義し、緯度はy方向を定義します。ほとんどのジオメトリライブラリは、この形式の(lon、lat)を厳密に使用します。これは、2D平面の地理座標を考える最も直感的な方法だからです。


3
それで、それが最も直感的な考え方である場合、KMLでlon-latを使用しているのに、なぜGoogle EarthブログがLat-Long Blogと呼ばれるのですか?
シータ

1
基本的に、これはナビゲーターが従来から緯度経度の順序を使用していたため、その順序に失敗すると、ナビゲーションが台無しになる可能性があります。そのため、グーグルはブログに従来の方法を使用し、データ構造には2D平面の順序を使用しています。:同じ質問に対する彼女の答えで@mkennedy答え、このベストをgis.stackexchange.com/questions/6037/...
デヴィッド・
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.