Code for History

"Code for History"はIT技術を歴史学上の問題の解決に使うコミュニティです。強調したいのは、我々にとってIT技術は「手段」であって「目的」ではありません。「目的」は歴史学上の問題を解決する事であって、必要であればITでない手段も活用します。常に最優先なのは、問題を解決することです。

メルカトル図法での同一ズームで表示される領域と実際の同一スケールで表示される領域の比較サービス作りました

発端は、去年のFOSS4G Advent Calendarでのid:usuyu記事

OpenStreetMapでズームレベルを合せて東京と比べると、おおまかにはこんな違いです。「東京にはどんな印象がある?」と聞くと、たいてい「Crazy」と返ってきます…orz。
https://www.evernote.com/shard/s4/sh/50a692a5-99cd-4b9c-be39-ecacb7b191b0/5f87230e229e754b3b1c94d28d75283a/res/e8e03c6d-d25b-4e39-a2bc-5190acc6db46/helto.jpg
Helsinki: http://www.openstreetmap.org/?lat=60.229&lon=24.939&zoom=11&layers=M
Tokyo: http://www.openstreetmap.org/?lat=35.693&lon=139.734&zoom=11&layers=M
 …
以上において、私は、仮にも地図を専門としている人間がやってはいけない、致命的なミスをしております。あえて、そのミスをしました。かなり、致命的です。しかし、これは、こういった地図サービスが一般的になればなるほど、地図に詳しくない方が使用すればするほど、陥りやすいミスです。私がこのミスをすることは許されがたいことですが、もし一般の方がこのミスをしたなら、それは地図サービスのほうが責められることになるかもしれません。
 …
一番最初にあててくれた方、そして、そのミスを起こさないような地図サービスをFOSS4Gで最初に構築してくださった方に、フィンランド土産を差し上げます。

さらにその答えがこちらで、要するにGoogle Maps等で用いられているメルカトル図法では、同じズームスケールでも緯度によって縮尺度合いが異なるにもかかわらず、緯度の大きく異なる2地点の地図をGoogle Maps上の同一ズームスケールで比較している、という事でした。

残念ながらクイズの最初の回答者にはなれなかったのですが、「そのミスを起こさないような地図サービスをFOSS4Gで最初に構築してくださった方」を目指してちょっと頑張ってみました。

当初考えていた方針は2つ、

  • 先の私の記事でも紹介したRouteMeは小数点ズームスケールが扱えるので、これを使って異なる2地点間で同一縮尺になるズームスケールを算出し、連動させて表示させるiOSアプリを作る
  • Google Mapsは小数点ズームスケールは扱えないが、近い整数ズームスケールに正規化して表示し、同一縮尺に当たる範囲をポリゴン矩形で表示する

を考えていたのですが、どちらも問題あって、

  • 前者はiOSアプリになっちゃうので、みんなが気軽に試せるものにならないよね。Appleの審査通すとかメンドイし。
  • 後者は、Google MapsはFOSS4GじゃねえwFOSS4GでOpenLayersとかLeafletとかあるけど、俺今のところ使えないしこれだけの為に覚えるのもアレ。

なのでどうすんべと思ってたところ、id:yellow_73こちらの記事で面白いプロダクトを見つけたので、これを使ってみようと思いました。

これも全く新しいAPIなので、使い方を覚えないといけない点ではOpenLayersやLeafletと同程度にはアレなのですが、OLやLeafletだと覚えた後に実現できるものが本質的解決になってないのに対し、こっちは完全に本質的に解決できるものができるので、これを覚えて作ってみようと思いました。

で、できたものがこちらです。

2つの地球儀が表示されますので、適当に動かしてみて下さい。
全く緯度の異なる場所を表示しても、Google Mapsのように異なる縮尺では表示されず、等しい縮尺で表示されるので、本当に正しい都市の広がり比較ができます。

2012/1/3現在、以下のような機能をつけています。

  • 2つの地球儀の連動ズーム変更
  • 2つの地球儀の連動位置移動(オンオフ可能)
  • ジオコーダで住所を指定しての地点移動機能
  • 地球儀の回転機能(連動位置移動機能と組み合わせれば、一方の地図を北に動かした時にもう一方が東に動く、等も可能)
  • 同一縮尺/メルカトル図法上での同一ズームスケールの切り替え可能(これをオンオフすると、本当の同一縮尺と、メルカトル図法上で同一ズームスケールにした際の表示領域差の比較ができる)

制限事項:

  • 使ってるWebGL Earth側の制限で、中心点の緯度が絶対値85度程度以上になると、下記のような状態になってどうにもこうにも動かせない状態にトラップされます。


こうなったら、ページごとリロードしてもらうか、ジオコーダで脱出後、ズームを動かすと復帰しますので、それで回避して下さい。

  • 2地球儀の連動スクロールは、API標準のナビゲーションは等角航路での移動のようなのですが、連動スクロールは大圏航路での移動になっています。

なので、必ずしもスクロール操作側で東に移動→西に同じ量移動、等操作しても、連動側で元の場所に戻ってくるとは限らないので注意して下さい。

サンプル:

ヘルシンキと東京


正しい同一縮尺で表示したもの。ヘルシンキの中心街っぽい半島?周辺と同程度の広さにあたる東京の範囲は、練馬区から杉並区、港区、台東区程度。

メルカトルでの同一ズームスケール相当で表示したもの。ヘルシンキが東京の和光市三鷹市、品川区、江戸川区程度までの広さを持った実像以上の広域都市に見えるし、逆にヘルシンキ側から見れば、東京が実像以上に過密都市に見える。

マレー半島と日本列島、長さ勝負


正しい同一縮尺で表示したもの。日本列島の方が大きいのは判ったけど、マレー半島も結構大きい。知床半島から関門海峡までくらいはある。

メルカトルでの同一ズームスケール相当で表示したもの。マレー半島が本州より大分小さく見える。

オーストラリアとグリーンランド


正しい同一縮尺で表示したもの。そりゃ腐っても大陸vs島、オーストラリアの方が大分大きい。

メルカトルでの同一ズームスケール相当で表示したもの。グリーンランド、大きいです…。

© Code for History