クライアントでのクラスタリング、または地図上に10,000ポイントを表示する方法

プロジェクトにはいくつかの種類があります
地理情報の出力は
必要：不動産サイト、会社名簿、
アトラクション、掲示板などのカタログ。
これらのサイトでは、goolge API 3およびYandex API 2のプラグインを開発することにしました。

基本的な要件：

1. サーバーでの深いデータ準備なしで接続する機能。つまり、オブジェクトの既存の地理座標のみを使用します。
2. データを準備および送信するためのシンプルなプロトコル。
3. 2つのタイプのラベル（クラスターとグループ）を使用した高速クライアントクラスタリング。 クラスター-近くにあるいくつかのオブジェクト。 クリックすると、クラスターが「開き」ます。つまり、オブジェクトがクラスタリング距離よりも遠いときにズームが増加します。 グループ-1つのポイント（最小距離）にある複数のオブジェクト。 ズームでグループをクリックすると、グループ内のオブジェクトのリストが表示されます。
4. クラスタリングを使用して最大10,000ポイントを表示します。
5. IE7のモバイルデバイス（第1世代のiPad）で表示します。
6. グループクラスターとオブジェクト自体の2つの情報ウィンドウのクライアントでのテンプレート化。
7. ラベルにスプライトを使用します。
8. さまざまな種類のオブジェクトに対して無制限の数の種類のラベル（アイコン）を使用する機能。
9. さまざまなズーム範囲に対して複数のアイコンサイズを使用する機能。

この記事では、このプラグインの実装に使用されたいくつかのアプローチについて説明します。

機能の動作時間の測定は、いくつかのデバイスで実行されました。 便宜上、それらの一部2で書き込みます-Google Chrome 19.0 @ AMD Athlon 64 X2 Dual Core 5600+ 2.8 GHz RAM 2Gb Windows-7 32bitが平均で、Safari @ Apple iPad 16GB 1.0 GHz iOS 5.1.1が最も遅く不機嫌です。

サーバー側

サーバー部分は次の2つの要求で構成されます。

1.カードデータの要求。

ラベルを選択するためのパラメーターを含むリンクがこのリクエストに送信されます。 たとえば、都市= 1および部屋= 1,2。 つまり、1ベッドルームと2ベッドルームのアパートメントで都市ID = 1のみを選択します（不動産サイトの例）。
応答として、マップのjsonパラメーター（マップ、マップの中心とズーム、アイコンパラメーター、クラスタリング距離、スプライトなど）とすべてのポイントに関するデータを含むjsonを含むスクリプトが返されます。 これらのポイントには、オブジェクトID、地理座標、アイコンタイプ、ツールチップラインが含まれます。 非圧縮状態の10,000ポイントの場合、応答サイズは1.2 MBですが、gzip圧縮では350 KBのみです。
頻繁に繰り返されるリクエストは、nginxによって適切にキャッシュされます。

2.オブジェクトの要求。

1つのマーカーをクリックすると、情報ウィンドウにオブジェクトに関するデータがポップアップ表示されます。 AjaxリクエストにはオブジェクトのIDが含まれます。 応答はjsonです。 jsonフィールドの名前は情報ウィンドウテンプレート内のタグと一致する必要があり、後者は受信したコンテンツに置き換えられます。

クライアント部

ポイントデータの解析

受信したデータは次のように処理されます。
1.ゼロズームでのグローバルピクセル座標は、各ポイントに対して計算されます。
2.グローバル座標に基づいて、14番目のズームのタイルIDが計算され、対応するタイルIDの配列にポイントが配置されます。 将来、どのズームでも、必要なタイルのIDを簡単に計算して、それらのすべてのポイントを選択できます。 ポイントサンプリング速度-10,000ポイントの場合、100/350ミリ秒以下。

解析時間10000ポイント-100/650ミリ秒

クラスタリング

Yandex API 2のネイティブClustererなど、いくつかのクラスターをテストしました。それらのいずれも、いくつかの理由で私に適していませんでした。 まず、クラスターのみが存在し、グループは存在しません。 クラスターをクリックすると、ズームは最大まで増加しますが、リストは表示されません。 リストを取得するには、もう一度クリックする必要があります。 これが、YandexのClustererの配置方法です。 Google Maps v3用のMarkerClustererにもこのタイプのマーカーはありません。
第二に、クラスターはグリッドによって計算されます。グリッドは高速ですが、多数のラベルを持つクラスターが「グリッド上」に配置され、見苦しくなります。
その結果、独自のClusterizeクラスタリングが作成されました。 その中で、クラスタリング方法は非同期ハイブリッドです。タイルのデータを要求すると、次のことが起こります。
-タイルは4つのサブタイル（グリッド）に分割され、各サブタイルは距離によってクラスター化されますが、クラスター自体はセルの中央ではなく、「折りたたまれた」ポイントの領域の中央に配置されます。
-受信したポイントとクラスターはタイルに収集され、再びクラスター化されます。 この時点で、すでにいくつかのポイントがあります。
-受け取ったポイントは、隣接するタイルを考慮して「間引かれ」ます（既にクラスター化されている場合）。 つまり、タイトルのマーカーと重なる境界線上の境界線タイルにクラスターまたはマーカーがある場合、これらのマーカーはクラスターに結合されます。 これにより、タイルの境界にマーカーが「付着」しないようにします。
クラスタリング速度は非常に高いことが判明しました。10,000のうち、60/500ミリ秒で580ポイントを取得します。 まったく問題ありません。

マーカーアイコン

スプライトを使用してアイコンを表示します。 アイコンの種類の数に制限はありません。 例では、単一マーカー+クラスターおよびグループアイコンに7種類のアイコンを使用しています。 2つのバージョンの例2の各タイプのアイコンは、14を超えるズームでは大きく、14未満では小さいです。クラスタリング距離は17ピクセルであるため、小さいアイコンは小さいスケールできれいに見えます。

情報ウィンドウのテンプレート

マーカーをクリックすることにより発生します：
1.マーカーがクラスターの場合-クラスターは「開示」にズームされます。


2.マーカーがグループの場合、このグループのオブジェクトのリストが表示されます。

3.単一のマーカーがデータをロードし、情報ウィンドウを表示します

マーカー出力。

マーカーを表示するには、Google API 3とYandex API 2を使用しました。
データを保存および処理し、タイルをクラスター化し、キャンバスを描画するモデルと、必要なAPIをロードしてマーカーを表示するいくつかのコントローラーを作成しました。

Google API 3-ネイティブコントローラー

このコントローラーは、ネイティブのGoogle Api 3機能とクラスタリングのクラスタリングを使用します。
Google API 3はすばやく読み込まれ、可能であればキャンバスを使用して、タグのスプライトをサポートします。
例
長所
少量のコード
CANVASへの自動切り替え
スプライトのサポート
短所
ズームを変更するときの遅くて不器用なレンダリング
つまり、各マーカーに対して4つのオブジェクトが作成され、ズーム10〜12でDOMがクラッシュします

カード出力速度10,000ポイントおよびクラスタリングによる10ズーム

Google API 3-キャンバスコントローラー

コントローラーはキャンバスを使用して各タイルをレンダリングし、クラスタリングをクラスター化します。
このコントローラーでは、タイルはキャンバス上に非同期でレンダリングされます。 レンダリング速度がわずかに向上することを除いて、ネイティブ関数と比較して特別な利点はありません。
例
長所
少数のDOMオブジェクト
ネイティブコントローラよりも最大50％高速なレンダリング速度
スプライトのサポート
短所
ズーム変更時の点滅
IEではサポートされていません

カード出力速度10,000ポイントおよびクラスタリングによる10ズーム

Google API 3-fullcanvasコントローラー

コントローラーはキャンバスを使用して、マップの可視部分全体をレンダリングします。
クラスタリングクラスタリング。
キャンバスキャンバスは、マップの表示部分のサイズに合わせて使用​​され、移動ごとに描画されます。
例
長所
DOMオブジェクトの最小数
ネイティブコントローラーと比較して最高100％の最高レンダリング速度
スプライトのサポート
IE 6のFlashCanvasサポート
ズーム変更時の美しいアニメーション
短所
つまり、100％のページスケールでのみ動作します（バグ）

カード出力速度10,000ポイントおよびクラスタリングによる10ズーム

Yandex API 2-「すぐに使える」ネイティブコントローラー

コントローラーはそのままAPI 2を使用します。
クラスタリングもネイティブのClustererです。
新しいYandex API 2では、クラスタリングが既にモジュールとしてAPIに組み込まれています。 クラスタ化ツールの使用-3行のコード。 クラスターアイコンの設定とリスト付きの情報ウィンドウがあります。 この例では、データ処理時間が単に悲惨なため、これを使用しませんでした。
例 （撤回には時間がかかる場合があります！）
長所
すぐに使えるすべての機能
短所
初期処理とクラスタリングが非常に遅い
膨大な数のDOMオブジェクト
クラスタータイプ「ポイント」の欠如
スプライトサポートの欠如。
ズーム変更時の点滅

カード出力速度10,000ポイントおよびクラスタリングによる10ズーム

Yandex API 2-ネイティブコントローラー

コントローラーはAPI 2関数を使用してGeoObjectをホストします。
ソフトウェアは、ラベルテンプレートとクラスタリングのクラスタリングを使用します。
このコントローラーを何度か書き直しました。 ymaps.GeoObjectは現在スプライトをサポートしていません。また、overlay.staticGraphics.Placemarkファクトリはシャドウをサポートしていません。 その結果、アイコンと影という2つのdivで構成されるマーカーのレイアウトテンプレートを作成しました。
例
長所
かなり高いカード準備速度
レイアウトタグによるスプライトサポート
短所
膨大な数のDOMオブジェクト
ゆっくり
すなわち殺す

カード出力速度10,000ポイントおよびクラスタリングによる10ズーム

Yandex API 2-キャンバスコントローラー

コントローラーはキャンバスを使用して各タイルをレンダリングし、クラスタリングをクラスター化します。
Googleキャンバスと同じレンダリングを使用します。 ズームを変更するときにキャンバスがスムーズにアニメーション化されるGooge APIとは異なり、Yandex API 2からこれを達成することはできませんでした（松葉杖で）既に方法を知っています。
例
長所
少数のDOMオブジェクト
高速レンダリング
スプライトのサポート
スムーズな移動効果
短所
ズームを変更するときの「おridge」
IEではサポートされていません

カード出力速度10,000ポイントおよびクラスタリングによる10ズーム

Yandex API 2-fullcanvasコントローラー

コントローラーはキャンバスを使用して、マップの可視部分全体をレンダリングします。
レンダリングは、マップが移動され、ズームが変更されるたびに行われます。
クラスタリングクラスタリング。
Google fullcanvasコントローラーとは異なり、キャンバスは表示領域よりも広くて高くなっています。 したがって、マップの移動はよりスムーズになります。 ズームを変更するときのアニメーションは、個別に作成する必要がありました。
例
長所

DOMオブジェクトの最小数
最高のレンダリング速度
スプライトのサポート
IE 6のFlashCanvasサポート
ズーム変更時の美しいアニメーション
短所
つまり、100％のページスケールでのみ動作します（バグ）

カード出力速度10,000ポイントおよびクラスタリングによる10ズーム


ここで現在の例を見ることができます。

おわりに

fullcanvasコントローラーを使用するのが最も効果的です。 たとえば、FlashCanvasは適用可能ですが、これまでのところ制限があります。
さらに、fullcanvasコントローラーは、WebGLを使用してマーカーをアニメーション化する（たとえば、カーソルの後ろの3dターン）、他のアニメーション効果を作成する絶好の機会です。
情報ウィンドウのテンプレートを使用すると、プロジェクトのデザインをカスタマイズしたり、オブジェクトに関する情報を表示したりできます。
現在までに、プラグインは95％で記述されています。 いくつかのバグをピックアップし、fullcanvasコントローラーでのキャンバスのレンダリングを最適化することは残っています。
これまでに解決されていない唯一の問題は、ieのFlashCanvasのページスケールです。 近い将来、それを克服することが可能になると思います。