masat999's posterous

Google Static Mapの活用(移動・マーカー)

今開発中のアプリと連携してGoogle Static Mapをサイト上に表示する仕組みを実装しているところで、地図を移動する時のロジックを調べてました。ズームレベルと移動距離の関係ってどこかに仕様無いのか?

ありました。ドンピシャな答えをまとめてくれてる人がいました。

Google Static Mapsの画像はズームレベル0のとき、幅256ピクセルで経度360度分を表示し、高さ256ピクセルで緯度170度分(画像は南緯・北緯ともに85度 までの模様)を表示します。ズームレベルが1になると4倍ズームになるので表示できる範囲が半分になり、256ピクセルで経度180度分、緯度85度分を 表示します。

これを計算式にすると以下のような感じになります。
[東へ移動したときの中心経度]=
(180 + [元の中心経度] - [画像幅] / 256 * 180 / 2^[ズームレベル]) mod 360 - 180
[南へ移動したときの中心緯度]=
(90 + [元の中心緯度] - [画像高さ] / 256 * 85 / 2^[ズームレベル]) mod 180 - 90

すばらしいです。この場を借りてお礼申し上げます。

ちなみに、アプリ上からGPSで取得した緯度・経度はDBに保存して、Static Map上のマーカーとして表示しています。当然のことですが、データが蓄積すると全てデータを取得することは不可能になるので、”今いる場所から半径○○メートル以内”且つ”最新○○件”のデータを取得するようにしたいと思っています。

そこで問題なのが、単純なクエリーだと範囲は長方形状になり、円ではないということです。そこはあえて妥協したくないので、これも調べてみました。内容が濃いのでリンク参照してください。

Geo/Spatial Search with MySQL

リンク先で言っていることは、要はストアドプロシージャ使えってことです。統計上133倍速くなるそうです。が。これだけのためにストアド書くのもどうなんだろうなぁ…と立ち止まる。

DB側は単純クエリーで長方形のレンジだけ絞って、残りの円から外れるものはSQLの外でフィルタすれば良くないか?乏しいリソースなんだから何でもかんでもDBにやらせてボトルネックが集中するのは良くないよ!と心の声がつぶやくのです。ロジックは分散するけどリスクを議論するほど大きなシステムでもないですし。

ってことでやるべき事のベクトルは定まりました。後は実装してiPhone版もそろそろ手をつけてみなきゃ。
そういえばデザインもそろそろ上がってくるはずなんだけど、どうなってんだ?

Filed under: google api
0 comments

Leave a comment...

To Posterous, Love Metalab
Web Toolbar by Wibiya