Google Web Mercator：あいまいな座標系

2014年10月1日に、米国国立地理空間情報局（ NGA ）は、さまざまなマップベースのWebサービスで使用されるWebメルカトル座標系を批判するレポートを公​​開しました。 このドキュメントには、問題の詳細な説明とNGAパートナーへの推奨事項が含まれていました。 この文書は大きな反響を受けましたが、この報告書に基づくすべての記事がその正確さと読み書き能力によって区別されたわけではありません。 これは、たとえば、協会のGIS Webサイトの記事に当てはまります。用語の重大な誤りにより、文盲と見なされる可能性があります。 Webサービス開発者はこの座標系に最も頻繁に直面するため、問題を理解することは理にかなっていると思います。

何言ってるの？

はじめに、いくつかの定義があります。これがないと、詳細を明確にすることはできません。 Webメルカトルは多くの人に知られているメルカトル図法に似ていますが、Webメルカトル図法は単なる投影ではなく座標系であることを理解することが重要です。 GIS Association Webサイトの記事の読者を誤解させるのは、この用語の不一致です。 投影法と座標系の違いは、投影法は、地球のモデルの複雑な形状が平面上で展開する方法にすぎないことです。一方、座標系には、地球の複雑な図を近似するモデル（楕円体または回転楕円体）の数学的な定義も含まれます



この図では、赤は投影メカニズム（この場合は円筒形）にのみ適用されるものを示しています。 ここに描かれているものはすべて、一般的な座標系を指します。

次に、この問題の原因となるのは、表面の非常に近似したモデル（上図の点線の球体、座標λ、φが決定される）であり、これについては後で説明します。

物語

誰が最初で誰がいつ起こったのか、はっきりとは言えません。 しかし、私の知る限り、Webメルカトル座標系を使用し始めた最初の主要なプロジェクトはGoogleマップサービスであり、これは2005年に起こりました。 その後、開発者は、地図作成データの操作に必要な計算を簡素化するタスクに直面しました。最も可能性のあることは、座標系で楕円体の代わりに球体を使用することでした。 興味深いことに、ジェラルド・メルカトル自身が同じ幾何学的表現から進んで、地図を平面に投影する独自の方法を作成したのは、少し遅れて住んでいたニュートンだけが、遠心力により地球が回転楕円体の形をしているという仮説を提案したためです、ボールではありません。 したがって、Google開発者はある意味で16世紀に戻りました。

このアプローチに対する批判が専門家のサークルで聞かれるのはこれが初めてではありません。 2005年以来、座標系の分野の標準化企業であり、その識別子のレジストリ（EPSGコード）を保持している欧州石油調査グループ（EPSG）は、明らかな幾何学的欠陥を理由に、独自の公式コードをWebメルカトルシステムに割り当てることを拒否しました。 したがって、ネットワーク上では、非公式のコード（EPSG：900913、EPSG：102113など）を介してこのシステムへのリンクを見つけることができます。 ただし、2008年には、システムの人気が高まるにつれて、この組織はコードを放棄して割り当てなければならず、さらに大きな無政府状態が生じないように、なんとか明確に指定する必要がありました。 システムを定義する最初の試みは完全には成功しませんでしたが、最終的には公式のSRID EPSG：3857が割り当てられました。

代数

投影法は数学の研究の対象であるため、数式から始めて、次にそれらに図解を与えます。 厳密に言えば、メルカトル図法に基づく座標系の実装と、ある場合には球体、別の場合には楕円体との違いを理解するために、良好な三角法を取得する必要さえありません。 式の外観は著しく異なります。
楕円体のメルカトル図法の平面への投影は、次のように定義されます。

x = a×λ
y = a×ln [tan（π/ 4 +φ/ 2）×（（1-e×sinφ）/（1 + e×sinφ））^（e / 2）]

ここで：
xとyは直交座標であり、
λ-楕円体上のラジアン単位の経度、
φ-楕円体上のラジアン単位の緯度、
aは、楕円体の半長軸の値です。
eは、楕円体の離心率（長軸と短軸の比）です。

楕円体の代わりに球体が使用される場合、Webメルカトル座標系で起こるように、縦座標（Y軸）の式は次のように縮退するため、すべてがはるかに単純になります。

x = a×λ
y = a×ln [tan（π/ 4 +φ/ 2）]

同意して、はるかにシンプルで短いように見えます。これが、Google開発者が求めていることです。 これにより、クライアントおよびサーバーアプリケーションで地図作成資料を操作する際の数学的操作の数を大幅に減らすことができます。

ジオメトリと地図作成

数式をまったく使用しなくても、簡単な図解が問題の本質をよく示しています。 まず、メルカトル図法を構築する原理は、楕円体または回転楕円体の表面上の任意の点が、この楕円体が配置された円柱に投影されるため、垂直軸が一致し、表面が1本の線に沿って接触することです（最も一般的なケース）、または2つに交差しました。 （上の図を参照）。 さらに、条件付き投影光線は楕円体の中心を出て、ポイントPでその表面と交差し、ポイントP 'で円柱の表面に落ちます。そこで、地球の表面上の対応するポイントが転送されます。 地球の実際の表面が最初にその形状に近い楕円ではなく、理想的な球体に投影された場合、円柱に投影されたとき、地球の表面の同じ開始点は線から異なる距離にあると想像するのは簡単です楕円体の場合よりも垂直軸に沿った赤道。

災害の規模を説明しようとします。 MODIS Aquaによって作成されたNASA EOSDISアーカイブから、ロシアの中央連邦地区の自然色の衛星画像を、2014年9月21日にピクセルあたり250メートルの解像度で撮影しましょう（この日-明確だったため、より美しくなります）-これが背景になります。

さらに、 Overpass Turboリクエストを使用して、OpenStreetMapデータベースからGeoJSON形式でモスクワ地域の管理境界をアンロードします。 リクエストコード：

<osm-script output="json" timeout="25"> <union> <query type="relation"> <has-kv k="name" v=" "/> <has-kv k="boundary" v="administrative"/> <bbox-query {{bbox}}/> </query> </union> <print mode="body"/> <recurse type="down"/> <print mode="skeleton" order="quadtile"/> </osm-script> 

次に、グローバルマッパーを使用して、モスクワ地域の境界のデータを地理的投影からメルカトル楕円体WGS84の投影に変換します。 そして、座標系が正しく認識されない状況をシミュレートするには、結果のデータをコピーし、座標系の定義を手動でWebメルカトルに変更します。 実際には、逆の状況がより可能性が高くなります。WebメルカトルのデータをWGS84 /メルカトルのデータと間違える可能性があります（Webメルカトルには多くの名前があり、その一部は「WGS84」であるため）私たちの模倣では、シフトの方向のみが異なります。 結果のデータをグローバルマッパーにダウンロードし、100キロメートル単位でグリッドをオーバーレイして、何が起こったかを確認します。



マップ上の緑のアウトラインは必要な場所であり、赤のアウトラインはシフトされています。 このシフトの大きさは19.6キロメートルです。 これは、この座標系を使用するすべてのマップサービスにこのようなエラーが存在することを意味するものではありません。 ただし、このシステムでデータを取得し、正しいアカウンティングなしで他のデータと結合しようとすると、それ自体が現れます。 この場合、地理座標への誤った逆変換が適用され、エラーが発生します。

ナビゲーション

一部の地図投影法には、ナビゲーションの問題を解決するために重要な特別なプロパティがあります。 メルカトル図法はその1つです。これは、海図および航空ナビゲーションマップの作成に広く使用されているためです。 これは、この投影の適合性などの幾何学的特性により可能です。 この場合、ライン間の角度の値が保存されるため、十分に大きなサイズのオブジェクトの形状がこのマップに保存されます。 ナビゲーションの場合、これは、地図を見て、子午線を基準に目的のポイントへの方向（地理的な北への方向）を計算し、磁気コンパスに沿ってこの方向に移動するか、北の星への線に対して一定の角度で移動して、適切な場所にいることを意味することを意味します。 この経路は「 ロクソドローム 」と呼ばれ、地球の表面上の2点間の最短経路ではありません。最新のナビゲーションデバイスでは、「最短経路」である「 オルソドローム 」に沿った経路を計算できますが、メルカトル図法は拒否されません。緊急時にGPS受信機やその他の電子機器に頼らずに、ナビゲーションに即興のツールを使用する機会。

そして、ここでWebメルカトル座標系はだまされています。 メルカトル図法に基づいていますが、地球の表面モデルの究極の簡略化として、一定の半径の球を使用すると、適合性が失われます。 これは、このようなマップで測定された一定の方位角で移動すると、この座標系での角度の歪みのために目的のポイントに到達できないことを意味します。 これはWebサービスにとってそれほど重要ではないように思われます。なぜなら、彼らの心の誰もが緊急時に彼らのために道を開くことはないからです。 ただし、Webサービスの多様性は素晴らしく、開発者の1人がこの予測の方向性を考慮することを保証しないことは保証できません。 この予測で計算すると、誤差が非常に蓄積する可能性があります。 さらに、CACのようなツールは現在非常に人気があり、Webサービスからデータを送信するPlanetであり、ユーザーが次に何をするかを予測することはできません。

この場合の問題の大きさも非常に簡単に測定できます。 背景に同じ写真を撮ってください。モスクワ地域の行政境界線の位置に関する同じデータを撮ってください。 ここで、3本の線が必要です。オルソドローム（地球の曲率を考慮した最短）と、メルカトル/ WGS84およびWebメルカトルシステムに組み込まれた2つのロキソドローム。 これらの路線は、モチリーという面白い名前の入植地から遠くない地域のセレブリャノプルツキー地区の最南端と、タルドムスキー地区の最北端の間に構築します。

オルソドロームを構築します。 次に、その長さ（37 km弱）と子午線に対する初期角度を測定します。 次は最も興味深いです。 ワークスペースをメルカトル図法に再投影し、同じ始点からこの投影図に直線を作成し、測定された角度と長さを307キロメートルに設定します。 同じことを繰り返しますが、座標系はWebメルカトルです。 2つのロキソドロームの準備ができています。 明確にするために、正中線の中心点を見つけ、半分に分割し、マーカーをこの場所に配置します。 UTM 37N WGS84のワークスペースを再プログラムして、マップの角度、比率、その他のプロパティの歪みを最小限に抑えます。



このような規模では、ほとんど何も作成できません。すべての行が実際にマージされます。 ただし、以前に100メートルのステップでグリッドが含まれていた線の中心を詳しく見てみましょう。



マップ上の黒い点が付いた緑の線は、オルソドロームです。 黄色はメルカトル/ WGS84で構築されたロクソドローム、赤色はWebメルカトルでのロクソドロームです。 予想通り、ロキソドロームは最短距離ではなく、直行オルソドロームに対して比較的円弧であるため、オルソドロームから遠ざかりました。 完全になくなった-500メートル以上。 しかし、彼らは私たちをどこに連れてきましたか？



メルカトル楕円体WGS84の投影に組み込まれた黄色のロクソドロームは、正しい魔法のように「魔法のように」目的の地点に戻りました。 これは、この投影法では、最初の方位角を把握し、この角度で常に地理的な北の方向に移動して、目的のポイントに到達できることを意味します。 しかし、赤ではうまくいきませんでした-150メートル以上逃しました。 30万メートルの道に150メートル。 4分の1パーセント。 それはたくさんですか、それとも少しですか？ これは、共形とは見なされず、重要な計算には使用されないのに十分です。

名前、外観、パスワード

Webメルカトル座標系が使用されていると判断することに関する問題は、発明されていません。 「アナキスト」の過去の彼女のために、彼女は非常に多くの名前を持っているので、リストするのは単純に不可能です。 ただし、この座標系の既知の名前とコードの一部のみをリストし、すべてがどれほどひどいものであるかを実証しようとします。

Webメルカトル、Google Webメルカトル、球状メルカトル、WGS 84 Webメルカトル、WGS 84 /擬似メルカトル（ここでの「擬似」はメルカトルだけでなくWGS84です） 、WGS84 Webメルカトル（補助球）、Popular Visualization CRS /メルカトル、WGS84 /シンプルメルカトル。

EPSG：900913、EPSG：3785、EPSG：3857、EPSG：102113、ESPG：102100、EPSG：41001。

これは、このシステムがPROJ.4形式でどのように見えるかです。
+proj=merc +lon_0=0 +k=1 +x_0=0 +y_0=0 +a=6378137 +b=6378137 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs
ここで、楕円体aとbの半軸のパラメーターの等しい値に注意を払う必要があります。 それらの平等は、球体を使用することを意味します。 これがメルカトル楕円体WGS84の「正直な」投影である場合、それはEPSG：3395であり、PROJ.4形式では次のように定義されます。
+proj=merc +lon_0=0 +k=1 +x_0=0 +y_0=0 +ellps=WGS84 +datum=WGS84 +units=m +no_defs

もう1つの不快な状況は、WKT（Well-Known Text）形式のこの座標系の定義の存在です。WKTの定義自体は、WGS84楕円体を使用する「公正な」座標系の定義とほぼ一致します。つまり、 SPHEROID["WGS 84",6378137,298.257223563,AUTHORITY["EPSG","7030"]が、 PARAMETER["semi_minor",6378137.0]宣言PARAMETER["semi_minor",6378137.0]または地獄のようなEXTENSION["PROJ4","+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +wktext +no_defs"],AUTHORITY["EPSG","3857"]コンストラクトEXTENSION["PROJ4","+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +wktext +no_defs"],AUTHORITY["EPSG","3857"] 。 このような定義（いくつかのデータを含むPRJファイルの形式）の問題は、このデータを開くソフトウェアが、最初のように矛盾した定義で何を望んでいるかを正確に理解することを誰も保証しないことですオプション。 また、WKTで記述されたすべてと矛盾するPROJ.4形式の文字列を定義に導入することは、だれがこれを一般にサポートするかわからないため、一般に微妙な倒錯です。 最良の場合、プログラムは座標系の定義の読み取り不可能な内容についてエラーを出し、最悪の場合、このビネグレットを解釈しようとし、理解できないものを無視します。これにより、Webメルカトルのデータが「公正な」WGS84のデータとして読み取られるという事実につながりますメルカトル図法。

状況の論理

ここでは、Webメルカトル座標系が価値がないことを証明しようとはしていません。 いいですね そして、まったく同じ結論（米国の軍事基準への準拠が重要である問題を除く）は、NGAレポートに記載されています。 座標系とその機能の違いを理解することは単に重要です。 ウェブメルカトルは、Google、OpenStreetMap、Bing、Yahoo、その他の無数のサービスのほぼすべてで使用されていることを理解することが重要です。 また、ラスターデータの多くのタイルソースを格納するSlippy Map Tiles形式に埋め込まれています。 それは非常に人気があり、それを使用する誰もがそれがどのように設計されているかを考えるわけではありません。 特に、計画されたサービスが単に地図付きの写真を表示するよりも複雑な機能を実行する必要がある場合は、考えてみる価値があります。

結論ではなく、いくつかの興味深い事実

NASA World Wind、Google Maps、Yandex.Mapsなどのサービスが出現する前に、このレポートの新しいラウンドを開始したNGA機関は、利用可能な比較的高解像度の衛星画像（ピクセルあたり10メートル、白黒画像）の唯一のソースでした）NIMA Raster Roamサービス（無料でNIMAはNIMA-National Imagery and Mapping Agencyと呼ばれることもあります）を介して無料でダウンロードできるロシアの領土へ。 これらの画像は、1950年代から衛星によって実施された偵察プログラムの一部であり、1995年に機密解除プログラムに分類されました 。

Yandex.Mapsサービスは、Webメルカトル座標系を使用せず、楕円体WGS84の正直なメルカトル図法、コードEPSG：3395を使用します。 これが最初から何に関連しているのかはわかりませんが、Yandexの従業員のコメントを聞くのは非常に興味深いでしょう。

スカンジナビア諸国のローカルマップサービスはしばしばメルカトル図法をまったく使用せず、これらの国で受け入れられている座標系を優先します。たとえば、ノルウェーの州サービスNorge i Bilderは3つの投影ゾーンUTMとデータムEUREF89を使用します。 これは、北緯では、メルカトル図法が大きすぎる変形を与えるためです。