発端は、去年のFOSS4G Advent Calendarでのid:usuyuの記事。
OpenStreetMapでズームレベルを合せて東京と比べると、おおまかにはこんな違いです。「東京にはどんな印象がある？」と聞くと、たいてい「Crazy」と返ってきます…orz。
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標準のナビゲーションは等角航路での移動のようなのですが、連動スクロールは大圏航路での移動になっています。
なので、必ずしもスクロール操作側で東に移動→西に同じ量移動、等操作しても、連動側で元の場所に戻ってくるとは限らないので注意して下さい。
