◻️ 🖤 🏳️ Yandex.Maps APIのObjectManager。マップに10,000個のマークをすばやく描画し、すべてにブレーキをかけない方法 👨🏽‍🌾 🕴🏻 ⏸️

Yandex.Maps APIを使用する開発者には、多くの場合、地図上に多くのオブジェクトを表示するタスクがあります。本当にたくさん-約10,000。さらに、このタスクは私たち自身にも関連しています-Yandexで薬局を探してみてください。一見したところ、「しかし、実際に問題は何ですか？持って行って見せてください。」しかし、これを開始するまで、問題が実際に車全体であることを理解することはできません。

うらやましいほどの規則性を備えた多数のタグに関する質問は、クラブと技術サポートに寄せられます。これらの人々は誰ですか？地図に10個以上のタグを表示することに興味がある人はいますか？この投稿では、問題の全体を詳しく見て、開発者がマップ上に多数のオブジェクトを最適に表示するのに役立つツールがAPIにどのように登場したかを説明します。

ほとんどの場合、データをマップにバインドする情報サービスが問題に直面しています。たとえば、bankomator.ruサイトは、銀行のATMの場所をユーザーに伝えます。

不動産リソースも多くのデータに苦しんでいます。顕著な例はCian.ruです。

最近まで、Yandex内では、APIを介して複数のポイントを表示するためのさまざまな「ハック」とトリックを関連チームにアドバイスしていました。鮮やかな例は、Yandex.Real EstateおよびYandex.Taxiです。

ポイント1.問題自体は何ですか？

タスクの重大度を感じるには、それを解決しようとする必要があります。まず、サービスのページに地図を表示する方法を理解しましょう。簡単なスキームを考えてみましょう：

クライアント（iPhoneのSafariなど）は、サーバーにindex.htmlページを要求します。このページは、次のコードを含むドキュメントです。

<head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <script src="//api-maps.yandex.ru/2.1/?lang=ru_RU" type="text/javascript"></script> <script type="text/javascript"> ymaps.ready(init); function init () { var myMap = new ymaps.Map('map', { center: [55.76, 37.64], zoom: 10 }); } </script> </head> <body> <div id="map"></div> </body>

次に、タスクを複雑にします。 Zenitファンの住所を保存するデータベースがあります。そして、これらのファンの住所を地図上に表示したいと思います。

「正面」の問題の解決策：

データベースから選択し、10億のアドレスを取得します。
10億個のアドレス全体を含む配列をindex.htmlファイルに追加します。
このファイルをクライアントに転送します。
クライアントでは、配列のデータを並べ替えて、各要素のマップ上にラベルを描画します。

あなたがプロジェクトマネージャーであり、開発者がそのようなソリューションを実証している場合、おそらくあなたは灰色に変わるでしょう。あなたは彼にあなたの価値判断を与えるでしょう。わいせつな言葉を削除する場合、次の点を強調できます。

index.htmlファイルの重量が数MBに増加し、ユーザーのページが数秒間開きます。
モスクワのタグのみを表示する必要がある場合、なぜデータベース全体をクライアントに転送するのですか？
人が10分の1しか見えないのに、なぜ地図にすべてのマークを描くのですか？
通常の方法で約100〜200個のタグをマップに描画すると、マップの速度が低下します。
チャネルが詰まらず、ブラウザがこれらのタグを描画する時間があるように、タグをバッチで徐々にロードできますか？

思考には2つの方向があります。

ユーザーに表示されるデータを決定し、必要なものだけを要求できるようにする必要があります。
これが必要になったら、最適に描画する必要があります。

百年前、APIはYandex.Map APIで開発され、これらの問題（アクティブエリアのテクノロジー）を解決しました。詳細については、開発者ガイドをご覧ください。

簡単に説明すると、サーバー上のタグに加えてタグのテキスト説明を含む透明な画像を生成します。クライアントは、マップの表示領域を監視し、マップの現在の表示領域に必要なデータを要求できます。

たとえば、ホットスポットを使用すると、maps.yandex.ruに渋滞が描かれます。サイトbankomator.ruは、同じテクノロジーを使用して作成されました。

この技術にはいくつかの重大な欠点があります。
1. 非常に複雑なサーバー側。 このような写真とその幾何学的な説明を生成するモジュールを自由に作成してみてください。すべて理解できます。

2. 絶対的な柔軟性。 マークをホバーするときにマークを「上げる」ことはできません。クライアント上のラベルの外観をすばやく変更することはできません。要するに、くしゃみの場合は、サーバーに画像を再生成するように依頼する必要があります。

したがって、ユーザーはホットスポットなしで可能な限りスピンしました。タイムアウトを介して、個々のオブジェクトのセットをバッチでクライアントに転送しました。同時に、クライアント上で再び問題が待っていました。クライアントに1000ポイントを渡した場合、それらをどのように描画しますか？

各ポイントから、 ymaps.Placemarkオブジェクトを生成してマップに追加する必要がありました。タグをクラスター化（ ymaps.Clusterer ）に追加し、クラスター化されたタグをマップに追加できます。 10,000ポイントをクラスタリングする場合、まずこれらの10,000ポイントをインスタンス化してから、それらをクラスター化ツールに転送する必要があることに注意してください。つまり、ラベルはクラスターに入るためマップ上に表示されない場合がありますが、それでも初期化には時間がかかります。

これらすべての問題をまとめると、次のことを可能にするモジュールを作成することにしました。

クライアント上に多数のポイントをすばやく簡単に描画します。
クライアント上のポイントを操作するときは、不要な初期化を避けてください。
厳密にオンデマンドでクライアントにデータをアップロードします。

そしてそれをやった。 ~~私たちはアザラシです。~~

ポイント2.ラベルをすばやく描く

ラベルをすばやく描画する方法を学習するには、現在の既存のソリューションにどのような問題があるかを理解する必要がありました。 ymaps.Placemarkオブジェクトができることを見てみましょう。

彼は地図に描くことができます。
彼には独自のplacemark.balloon.マネージャーがいplacemark.balloon.
彼には独自のplacemark.hint.ヒントマネージャーがありplacemark.hint.
彼には、ラベルをドラッグアンドドロップして、座標placemark.editorを修正できるエディターがあります。

さらに、ラベルは、環境のあらゆる変化に動的に対応します。オプション、データ、地図投影の変更、地図の縮尺の変更、地図の中心の変更などです。これが私たちの強力な目印です。

しかし、開発者が多くの同じタイプのラベルを地図上に表示するだけの場合、このソフトウェアのパワーはすべて必要ですか？そうです、必要ありません。

したがって、最初の洞察はこれでした。ただし、ラベルのすべての補助モジュールを1つの共通コンポーネントに配置し、個々のオブジェクトごとに、レンダリングを直接担当するプログラムエンティティのみを作成します。

2番目の洞察は、不必要なソフトウェア初期化の問題について考えたときに生じました。このような写真の領域のどこかで、上の話を思い出します。

不要なソフトウェア初期化を取り除きたいと思い、天才を思いつきました。座って、今啓示があります：不要なソフトウェアの初期化が気になる場合は、それらをしないでください。
オブジェクトに関するユーザーデータ（実際はJSON）を保存することを決定し、オブジェクトのプログラムエンティティは、オブジェクトをマップに描画する必要がある場合にのみ作成されます。

これらのアイデアといくつかの開発を組み合わせた後、多数のポイントオブジェクトを表示する新しいAPIモジュール-ymaps.ObjectManagerが生まれました。

オブジェクトのJSON記述は、このマネージャーの入力に送られます。
マネージャーは、どのマークがマップの表示領域に入るかを分析し、マークを描画するか、これらのマークをクラスター化して、マップに結果を表示します。

マップ上にラベルとクラスターを描画するために、マップ上のラベルの表示のみを担当するymaps.Placemarkオブジェクト（つまりymaps.overlay。*）の一部のみを取得しました。バランやヒントなどのすべてのインフラストラクチャを単一の共通コンポーネントに配置します。

これらの手法により、クライアントで多数のラベルをレンダリングする問題を大幅に改善できました。速度の向上は次のとおりです。

図1.オブジェクトを作成してマップに追加する速度と、それに続く可視部分の非同期描画

1000個のタグを作成してマップに追加すると、すべてのタグが表示されます。
1000個のタグを作成し、クラスタリングでマップに追加すると、すべてのタグが表示されます。
10,000個のタグを作成し、それらをクラスタリングでマップに追加すると、すべてのタグが表示されます。
50,000個のタグを作成し、それらをクラスタリングでマップに追加すると、すべてのタグが表示されます。
50,000個のタグを作成し、それらをクラスタリングでマップに追加すると、500個のオブジェクトが表示されます。
50,000個のタグを作成し、クラスタリングせずにマップに追加すると、10,000個が表示されます。

図2.オブジェクトを作成してマップに追加する速度と、それに続く可視部分の同期描画

1000個のタグを作成してマップに追加すると、すべてのタグが表示されます。
1000個のタグを作成し、クラスタリングでマップに追加すると、すべてのタグが表示されます。
10,000個のタグを作成し、それらをクラスタリングでマップに追加すると、すべてのタグが表示されます。
50,000個のタグを作成し、それらをクラスタリングでマップに追加すると、すべてのタグが表示されます。
50,000個のタグを作成し、それらをクラスタリングでマップに追加すると、500個のオブジェクトが表示されます。
10,000個のタグを作成し、クラスタリングせずにマップに追加すると、2000個が表示されます。
5,000個のタグを作成し、クラスタリングせずにマップに追加すると、1,000個が表示されます。

重要なお知らせ。 これらの統計はすべて、最新のブラウザーに有効です。 IE8はこれらのブラウザーには含まれていません。したがって、彼にとって数字ははるかに悪くなりますが、大多数にとってそれは重要ではないと思います。

オブジェクトの作成とレンダリングを直接加速することに成功し、これに加えて、ソフトウェアエンティティの初期化を可能な限り最適化しました。これで、たとえば、クライアント上で50,000ポイントをクラスター化でき、マップでの作業が快適になります。

開発者ガイドでモジュールの詳細を確認し、サンドボックスでモジュールの実例をご覧ください。

そこで、クライアント上でポイントをすばやくすばやく描画してクラスター化する方法を学びました。次は？

ポイント3.データの最適なロード

Zenitファンの例を覚えていますか？クライアントでデータをレンダリングする問題は解決しましたが、このデータの最適なロードに関連する問題は解決しませんでした。典型的なAPIユーザータスクの収集を開始しました。研究の結果によると、私たちは2つの典型的なケースを受け取りました：

サーバー上のユーザーは大量のデータを持っているため、クライアントで表示したいが、必要に応じてデータをロードしたい。
開発者は、サーバー上でデータを準備し（サーバークラスタリングを実装するなど）、この処理の結果をクライアントで表示したいと考えています。

どちらのモジュールも基本的にObjectManagerの実装に基づいていますが、ダウンロードしたデータのロードとキャッシュのアルゴリズムには多くの違いがあります。

その結果、ユーザーがカードを操作すると、ユーザーはデータベースからデータを受け取ります。ある時点で、データのすべてまたは必要な部分がロードされ、サーバーリクエストは送信されなくなります。

データはpr-treeのクライアントに保存されるため、大量のデータであってもサンプルは非常に迅速に作成されます。

次に、オプション2について説明します-クライアントでのサーバークラスタリングの結果の表示。サーバー側のラベルクラスタリングを作成したとします。また、クライアントからの要求に応じて、クラスターとクラスターに含まれない単一のラベルを提供できるスクリプトを作成しました。

RemoteObjectManagerインスタンスを作成し、この素晴らしいスクリプトへのパスを登録するだけです。 RemoteObjectManagerは、 LoadingObjectManagerとほぼ同じように機能します。違いは、ズームを変更するたびにサーバーにデータを再要求することだけです。

データはサーバー上でクラスター化されるため、サーバーとサーバーのみが、どのデータが必要で、どのデータを現時点でマップに表示する必要がないかを知ることができます。したがって、オブジェクトに関する情報は、最初のズームが変更されるまでのみクライアントに保存され、その後すべてが再度要求されます。

クラスターラベルの説明がサーバーから送信される場合、クライアント上でこれらのラベルはAPIからインフラストラクチャ全体を取得します-クラスターに特別なアイコンが描画され、すべての標準的な動作が動作します。

ポイント4.サーバー実装に関する考察

このセクションでは、クライアント部分の設計時に想定したサーバー上のデータの保存および処理の概念をリストします。単純なものから複雑なものに移りましょう。

1.サーバー上のオブジェクトに関する情報の静的ファイルへの保存

クライアントコードはデータに対してのみ動作します。タイルは、マップ上の特定の番号付きエリアです。タイルの番号付けの詳細については、ドキュメントをご覧ください。

マップの特定の領域がページに表示されると、クライアントモジュールはこの表示領域にあるタイルを計算し、必要なデータの存在を確認し、必要に応じてデータの要求を送信します。

クライアントモジュールには、新しいタイルごとに個別にリクエストを送信する設定があります。なぜこれが貴重なのですか？はい、サーバーへのクライアント要求オプションの有限数を取得します。

ズーム= 0、タイル= [0、0]
ズーム= 1、タイル= [0、0]
ズーム= 1、タイル= [0、1]
ズーム= 1、タイル= [1、0]
ズーム= 1、タイル= [1、1]
ズーム= 2、タイル= [0、0]
...

リクエストは事前にわかっているため、リクエストに対するレスポンスも事前に生成できます。サーバー上で何らかのファイル構造を整理しましょう。

次のコードがファイルに保存されます。

 myCallback_x_1_y_2_z_5({ "type": "FeatureCollection", "features": [ { "type": "Feature", "id": 0, "geometry": { "type": "Point", "coordinates": [55.831903, 37.411961] }, "properties": { "balloonContent": " ", "clusterCaption": " 1", "hintContent": " " } }, ... ] }

このようなファイルをクライアントにロードすると、ファイルに登録されているJSONPコールバックが呼び出されます。データはLoadingObjectManagerの腸に落ち、必要に応じてキャッシュおよびレンダリングされます。

その結果、サーバー上のデータセットを使用して静的ファイルを保存するだけで済み、クライアントパーツはいつそれを要求して表示するかを自ら決定します。

2.静的ファイルからの動的応答生成

上記のソリューションの重大な欠点は、クライアントからサーバーへのデータに対する多数のリクエストです。タイルごとに個別にデータを要求するよりも、複数のタイルの直後に要求を送信することをお勧めしますが、タイルのグループに対する要求を処理するには、既にサーバーコードを記述する必要があります。

この場合、データは引き続き別のファイルに保存できます。クライアントが特定の長方形の領域でデータのリクエストを受信すると、複数のファイルの内容を1つの回答に接着してクライアントに送り返すだけで十分です。

3.データベースを使用した動的応答生成

私たちの意見では、最も確実な方法は、地理参照データにインデックスを付けることができる何らかのデータベースを使用してサーバー部分を実装することです。空間インデックスをサポートしないデータベースの場合、空間キーの概念を使用して自分で同様のインデックスを作成できます。

一般に、地理参照データをサーバーに保存してクラスタリングすることは、別の議論のトピックです。そのため、別の機会にそれを議論します。

このリポジトリには、node.js + mongo.dbで記述されたサーバーグリッドクラスタリングを使用したサーバーパーツの実装例があります。誰かが役に立つかもしれません（デモ）。

おわりに

新しいモジュールの比較表。

モジュール	メリット	欠点
オブジェクトマネージャー	クライアント上のオブジェクトのクラスタリングを許可します。レンダリングは、マップの可視領域に収まるオブジェクトに対してのみ行われます。オブジェクトが表示されたときにフィルターすることができます。すべてのデータ処理はクライアント側で実行されるため、サーバー側を実装する必要はありません。	サポートはタグでのみ動作します。データは、すべてのオブジェクトについて一度にダウンロードされます（マップの表示領域に該当しないものも含めて）。オブジェクトのクラスタリングはクライアント側で行われます。
LoadingObjectManager	クライアント上のオブジェクトのクラスタリングを許可します。マップの表示領域のデータのみをロードします。アップロードされたデータを保存します。オブジェクトごとに、データは1回だけダウンロードされます。オブジェクトが表示されたときにフィルターすることができます。	サポートはタグでのみ動作します。オブジェクトのクラスタリングはクライアント側で行われます。サーバー側を実装する必要があります。
RemoteObjectManager	サーバー側のデータクラスタリングを使用します。オブジェクトデータはサーバーに保存されます。毎回、データはマップの表示領域に該当するオブジェクトに対してのみロードされます。	サポートはタグでのみ動作します。倍率を変更すると、データは再びダウンロードされます（データが既にダウンロードされているオブジェクトでも）。独自のクラスタリングを実装する必要があります。サーバー側を実装する必要があります。

現時点では、ポイントフィーチャを使用した作業のみをサポートしています。ポリゴン、ポリライン、その他の美しい形状のサポートは計画内にあり、将来のリリースで提供される予定です。

これらのモジュールの使用を検討する場合マップ上に多くのポイントフィーチャを描画する必要があるほとんどすべての状況。

便利なリンク：

写真付きの最も詳細な開発者ガイドはtech.yandex.ru/maps/doc/jsapi/2.1/dg/concepts/many-objects-docpageです。
サンドボックスの例-tech.yandex.ru/maps/jsbox/2.1/object_manager
RemoteObjectManagerのサーバー部分の実装例を含むgithubプロジェクトはgithub.com/dimik/geohosting-serverです。
Yandex.Map API Developers Club。質問があります-clubs.ya.ru/mapsapi

Yandex.Maps APIのObjectManager。 マップに10,000個のマークをすばやく描画し、すべてにブレーキをかけない方法