The GIS Professional Group

「Web メルカトル(ウェブメルカトル)」の由来と真相

2016/2/17 (水)

Googleマップの登場 ~インターネットGISから Web GIS へ~

2000 年代中盤までは「インターネット GIS」とよばれていました。クライアントから要求された範囲を都度サーバー側で地図画像や地図データを生成する処理を行うのがマップ生成の一般的なやり方でした。インターネット GIS を牽引した ArcIMS では、クライアント(利用者)がドラックした範囲をサーバーが受け取り、地図画像を生成してクライアントに戻す、もしくはベクトルデータを送ってクライアントにインストールされた Java の力で描画する、という方法を採ってました。

それに対して、2005年2月に登場した Googleマップ では、あらかじめ地図を数種類の縮尺ごとにタイル形状の画像(タイル画像)で用意しておき、クライアントの要求によって作成済みの地図画像を送るだけで表示する、という画期的な方法を採用することで高パフォーマンスなサービスを実現しました。

タイル画像のデメリットは、タイル間の微妙な縮尺の地図が表示できないことや、地図のレイアウト(シンボル)を動的に変更することができない点にありましたが、このデメリットよりも、高速に地図が表示できて住所検索して場所が分かるという方が圧倒的にメリットが大きかったわけです。

ArcIMS はキャッシュをサポートすることなくリタイアしましたが、ポスト ArcIMS として登場した ArcGIS Server(現 ArcGIS for Server)でタイル画像(キャッシュ マップ サービス)が実装されました。ArcGIS Server は、ArcGIS Engine と共に 2004 年 5 月にバージョン 9.0 としてリリース(米国)されましたが、バージョン 9.1 までは都度クライアントの要求によって地図を描画してサーバーから結果を渡すという ArcIMS とあまり変わらない方式でした(内部のテクノロジは違います)。

当初 Esri は「Googleマップはただの絵だ!」と言ってたそうですが、2005 年の Googleマップ登場から一転して、2006 年 11 月にリリース(米国)された ArcGIS Server 9.2 でタイル キャッシュをサポートするようになりました。結局インターネットで表示する地図は絵で良かったんですね。当時のマシン スペックだとその方が地図描画が圧倒的でした。Googleマップ登場あたりから「Web GIS」と呼ばれるようになってます。

ちなみに、やっとタイル キャッシュが当たり前になった現在ですが、Google は 2013 年にタイル画像方式から次世代のいわゆる「ベクタータイル」方式に移行してしまいました。ちゃんと Esri も追っかけています

2000 年代中盤は「マッシュアップ」という別々のサービスをミックスしてより良い付加価値を与える、というのが流行りだした時期でもあります。そうすると、Googleマップ(一般図)の上に別の GIS サービス(主題図)を重ねて分かりやすい地図にする、なんてことも考えたくなります。

じゃあやってみましょうと、地図を重ね合わせすると、上手くいきません。マイガッ!

Googleマップと重ねられない GIS の地図

Esri のサポート サイトにこのような FAQ が掲載されています。

Google マップに「別の地図」を重ねようとすると「位置が合わない」のです。Googleマップはメルカトル図法で WGS84 って書いてあるんだからそれで投影座標系を定義すれば重なるんじゃないの?と思いたいですが、それで定義しても Google マップと重ならないのです。

地図は「座標系」と呼ばれるもので表現が決まります。「座標系」=「投影法 + 測地系」です。「測地系」とは、超簡単に要約すると「地球の大きさの定義」(実際は+αがある)です。

で、先ほどから何回か登場している「WGS84」が「測地系」と呼ばれるもので地球の大きさが定義されています。

WGS84 楕円体
長半径(赤道半径): 6378137.0
短半径(極半径)  :6356752.314245179
扁平率の逆数        :298.257223563

WGS84 をはじめとして他の回転楕円体も赤道方向に少しつぶれているのが地球の形と定義されています。普通地図は、回転楕円体に基づいて緯度経度を求め、地図投影しています。

Googleマップは WGS84 で緯度経度を求めていますが、地図投影で採用されている回転楕円体は

長半径(赤道半径) 6378137.0
短半径(極半径)  :6378137.0
扁平率の逆数        :0

と、もはや回転楕円体ではなく球体を使っています。GIS に携わっていたら

日本測地系(ベッセル楕円体)から世界測地系(GRS80 楕円体)へ変換すると同一座標で 400m ~ 500m ずれる

と聞かれたことがあるでしょう。Googleマップのちず投影に採用された回転楕円体の大きさをみると、これがいかに大変なことかが分かっていただけるでしょう。

2 つの準拠楕円体を元に地理座標系を作成して、重ね合わせてどれくらいズレがあるのか確認してみます。メルカトル図法による投影座標系にしても構いませんが、差異はないので地理座標系でやってみます。

まず、Web メルカトル座標系に定義されている真の地理座標系(測地基準系)を作成します。ジオプロセシングの [空間参照の作成 (Create Spatial Reference)] ツールで上記の地理座標系(≒測地系)を定義し、名前に "GCS_WGS_1984_Sphere" のような適当な名称を設定します。

次に、WGS84 と "GCS_WGS_1984_Sphere" の地理座標系変換を行うためのパラメーターをジオプロセシングの [カスタム地理座標系変換の作成 (Create Custom Geographic Transformation)] ツールを使用して作成します。違いは回転楕円体の大きさだけなので、メソッドは [GEOCENTRIC_TRANSLATION] (3 パラメーター変換)でシフト量を 0 として重心を一致させます。

カスタム地理座標系変換が作成できたら、GCS_WGS_1984 のデータを投影変換で変換します。

処理が完了するとデフォルトで自動的に結果がマップに表示され、正しい位置関係で重なります。これは一度 ArcMap 上で [カスタム地理座標系変換の作成] ツールを実行すると、データ フレームに対して地理座標系の差異を補正するリアルタイム [地理座標系変換] が有効になるためです。そのため ArcMap を再起動します。

再起動後の ArcMap に 2 つのデータセットをマップに追加するとずれていることが確認できます。ズレの距離は測地線距離で以下のとおりでした。

同一緯度なら東西での差異は見られませんでした。これにより、WGS84 と Google 由来の真の測地系で同一の緯度経度を示すと、実際には 16~21km のズレが生じるということが分かりました。

巨人の手にかかれば地球の大きさも変えられるのか

ただし、Googleマップでは地図上の指定した地点を WGS84 の緯度経度として返すように考慮されているため、楕円体の大きさの違いを認識することはありません。

次のページへ >

  • B!