MarkerReducer
hiroaki
GMarkerManager が使いづらいので、次のようなライブラリを作りました。ご意見などを伺えればと思いますので、お知らせさせてくださ
い。
MarkerReducer （デモ・ページ）
http://homepage.mac.com/hwat/maps/MarkerReducer/
複数のマーカーが近い場所で重なるようだったら（クリックしづらい状況になったら）、それをひとつの別のマーカーに代表させて表示させておいて、その代
表マーカーをクリックすると、もともとのマーカーが重ならないレベルまでにズーム・インします。
使い方は簡単で、クラスのインスタンスを作ったら、それに GMarker を加えていくだけになります。
var mr = new MarkerReducer( map );
mr.addMarker( new GMarker(...) );
mr.addMarker( new GMarker(...) );
mr.addMarker( new GMarker(...) );
...
...
mr.refresh();
ズームの変化がトリガーになって、マーカーを再配備する仕組みです。
ただ、そのことから、ズームレベルを変えるたびに動的に計算し直すので、マーカーが多いと処理に（実用とならないくらい）時間がかかる事が、おおきな問
題点になっています。デモ・ページでは40個のマーカーを使っていますが、うちのチープなマシンですとこれくらいがせいぜいでした。
計算結果を先に作成しておいたり、キャッシュを持たせたり、というアイデアは持ってはいるのですが、いずれにしても、最初は追加したい数のマーカーたち
を計算にかけなければならないので、どうしても重たくなってしまいます。
よりよいアルゴリズム、高速化のアドバイスなどいただければとても嬉しいです。
どうぞよろしくおねがいします。
takane
>hiroakiさん
>GMarkerManager が使いづらいので、次のようなライブラリを作りました。ご意見などを伺えればと思いますので、お知らせさせてください。
おおっ。やっぱり皆さん大量のMarkerの表示にはいろいろ工夫されてますね。
こういうライブラリがもっと沢山出てくると嬉しいです。
>よりよいアルゴリズム、高速化のアドバイスなどいただければとても嬉しいです。
>どうぞよろしくおねがいします。
ソースコードざっくり読ませていただいただけなのであんまり的確じゃないかもしれないし
そんなこと知ってるよ！ってことかもしれないですが一言。
やっぱりまとめる計算は一回だけになるようにしたほうがいいと思います。
refleshが呼ばれたときは結果からMarkerの表示処理を行うだけですむようにしておくと。
そうすれば、表示処理はGMarkerManagerに任せてさらに処理を軽く何てこともできるでしょうし。
ちなみに、オライリーから出てる「GOOGLE MAPS HACKS」の中でも
似たようなことを取り上げてるんですけど(#Hack 64)
まとめる処理はサーバのプログラムで行って結果をAjaxで取得してます。
Javascriptには重たい処理かも（って身も蓋も無いこと言ってすいません）
あとは、Javascriptの場合ロジック中でハッシュをうまく利用できると結構高速化できます。
私の作ってるDamMapsの場合、クラスタリングは行っていないんですけど
GMarkerManagerみたいなMarkerの表示制御を自前でやっていて
経緯度座標値を元にしたハッシュ値を作成
（DamMapsでは日本国内だけが対象なので地域メッシュ値
http://ja.wikipedia.org/wiki/%E5%9C%B0%E5%9F%9F%E3%83%A1%E3%83%83%E3%82%B7%E3%83%A5
の算出法を元にしたハッシュコードを使ってます）
し、そのハッシュ値を使ってMarkerを格納したり表示判定を行ったり
（当然厳密じゃなくなりますけど、それで大丈夫なくらいにハッシュコードを細かくしてるのでうまく動いてます）
してます。
範囲を比較する処理をハッシュ要素の有無の判定に置き換えることができれば
かなり処理が軽くなると思いますが、結構ややこしいですね。
hiroaki
コメントありがとございます。こんばんは。
動機と言うか経緯を少し話しますと、アイコンが重ならないような、マーカーの配置を計算して、 GMarkerManager のデータとするための
ツールを作ろうと思ったんです。そしたら、そのまま表示もやってしまえばいいなということで、いまの形になりました。
計算して、結果を GMarkerManager に任せてもよかったのですが、そちらに登録したマーカーはふつうのマーカーのようには扱えない、とい
う理由もありました（これはあとで気付いたので、理由も後付けですけども... ）。
ただ任せるとしても、また独自の実装でも、いずれにしても最初には計算が必要になる事には変わりなく、そしてその計算がすこぶる重たいのですよね。一回
計算させた後は、キャッシュさせればいいのですが、その一回が... 。
> ちなみに、オライリーから出てる「GOOGLE MAPS HACKS」の中でも
> 似たようなことを取り上げてるんですけど(#Hack 64)
本は持っていないのですがオンラインのサポートページはブックマークしてあります。でも該当セクションのサンプルは動きませんでした... 。とはいえ
その動作仕組みの想像はできます。が、やはりサーバサイドでの対処は、プラクティスとしては面白いですけども、今回は JavaScript だけでや
りたいので、見送りたいと思います。
> あとは、Javascriptの場合ロジック中でハッシュをうまく利用できると結構高速化できます。
配列との対比でのハッシュ（連想配列）ですね。
配列の操作とかって、じぶんが思っているより、じつは重たかったりするのかもしれません（？） push とか splice とか... 。考えると
なんだか重たそうなイメージがしてきました。これは検証してみればいいので、折りをみてこっそり検証してみたいと思います。
ちなみに、いまのアルゴリズムでは、 addMarker されたマーカーを、ほかのすべてのマーカーと比べて行っているんですが（比べる必要のない
ケースはスキップします）、これは配列をぐるぐる回しているだけなんです。しかしここにすべてが詰まっているといっても過言ではなく、注目すべき所で、
デリケートなところなので、ここを少しでも改善出来れば効果も大きく出る所となっています。
アルゴリズムの全とっかえか、ここの部分のチューニングか... 後者で済めばいいのですが、今は分が悪いといった状況です。
> 私の作ってるDamMapsの場合、クラスタリングは行っていないんですけど
> GMarkerManagerみたいなMarkerの表示制御を自前でやっていて
> （DamMapsでは日本国内だけが対象なので地域メッシュ値http://ja.wikipedia.org/wiki/%E5%9C%B0%E5%9F%9F%E3%83%A1%E3%83%83%E3%...
> し、そのハッシュ値を使ってMarkerを格納したり表示判定を行ったり
メッシュというのも聞きかじった程度しか知らなかったのですが、小さな区画に分かれた小さなエリアごとに、マーカーが複数あるかないか、とかいうアルゴ
リズムを試みた事がありました。メッシュは、いうなれば、そんな感じのことでしょうか。ただその試みは、いまのものとはまったく違うアプローチなので、
実装まではいたっていません。
試みる時は、たぶんゼロから作り直しになりそうですけども、でも試みてみるにこしたことはないですね。うまくハマればいい意味でハマるかもしれませ
ん。 Wikipedia からいろいろ辿って見てみて、少しヒントが浮かびました。（抽象的すぎてスミマセン、じぶんでも具体はまだ浮かんではいない
ので。でもその直感が大事かな、と）。
──やはりひとりで考え込んでいるより、ほかのひとの意見を伺うと、ものの見方が変わったり、ひょんなきっかけが得られたりするので、投稿してみてよ
かったです。
本来ならばざっとしたアルゴリズムの解説くらいするべきかとも思ったのですが、コアなところをいきなりつらつら書いてもどうかなと思ったもので、割愛し
ました。そして、ソースがだらしなくてスミマセン。
もちっと、練りこんで行きたいと思います。