レンダラ プラグイン作成のベストプラクティス

レンダリングプラグインのコードはブラウザで実行されるため、最適化されたコードを記述し、パフォーマンスの問題に特に注意することが重要です。 お使いのプラグインがパワフルなマシンでうまく動作する場合、他のパワーの低いユーザーのマシンでは不安定に動作する可能性があります。

上記のいずれかの状況でレンダラ プラグインが適切に動作するように適切に最適化されていることを確認するには、次の点を確認してください。

• レンダラ プラグインは、妥当な時間でデータを準備します。
• 同時に開くことのできるタイルの数が十分にあります。

また、レンダラ プラグインの開発中は、以下の手順に従ってください。 これらの方法を使用すると、データの視覚化に関連する最も一般的なパフォーマンスの問題を回避できます。

データ インスペクター ライブラリコンポーネントの使用方法に関する開発者への一般的な推奨事項の詳細については、「開発者のためのベストプラクティス」を参照してください。

生成された GeoJSON に存在するフィーチャーが多すぎます

特に大規模なデータセットの場合は、すべてのデータをグラフィカルに表現しないようにしてください。 そうしないと、レンダラ プラグインによって、レンダリングするには大きすぎる GeoJSON が生成されることがあります。 すべての種類のユーザーが、異なるマシンで異なるブラウザを使用することがあります。 Safari 、 Chrome 、 Firefox の最新バージョンですべてのテストを行って、ローエンドのマシンで試してください。 レンダリングする GeoJSON 機能の数を制御し、ブラウザによって割り当てられるメモリの上限を超えないようにすることをお勧めします。

マップ上にレンダリングされたオブジェクトの数が多いと、同じ領域に多数のオブジェクトが重なっている可能性があるため、データの視覚的な分析も困難になります。 このため、ユーザーが車両 ID などの機能識別子を指定して、この機能に関連するオブジェクトのみをレンダリングできるように、コード内に変数を作成することをお勧めします。 このようなフィルタリングアプローチは、分析機能とパフォーマンスの両方を改善するのに役立ちます。

GeoJSON のプロパティに追加されたデータが多すぎます

GeoJSON tooltipおよびdescription情報プロパティにデータの詳細情報を追加しすぎないでください。 ツールチップの概念では、短い文字列のみが表示され、詳細情報 description プロパティを表示するために使用されます。 それでも、大量のデータをに追加 description しないことをお勧めします。

デコードされたパネルの出力を使用 して、 GeoJSON の機能、ジオメトリ、およびプロパティをより詳細に分析します。 機能のプロパティに含まれるすべてのデータを含むレンダラ プラグインによって生成された GeoJSON 全体が Web ワーカーを通過する場合、ブラウザに割り当てられているリソースのほとんどが消費されます。 そのため、この機能の追加情報が多すぎると、ブラウザがクラッシュする可能性があります。

また、説明で HTML が使用されないようにすることをお勧め InfoPanelします。キー値オブジェクトを使用することをお勧めします。キー値オブジェクトは、によってテーブルとして表されます。

GeoJSON 機能に多数の基本情報がある場合は protobufRef 、プロパティを使用して、プラグインによって生成された GeoJSON 機能を対応するソースデータオブジェクトにマップします。

データ処理中にコストのかかる操作が多すぎます

レンダラ プラグインによってローカルで処理される必要があるデコード済みデータのメガバイト ( またはギガバイト ) になる可能性があるため、データ処理操作を常に最適化してください。 ループ、繰り返し、データ変換、およびデータの書式設定を過度に使用しないでください ( 文字列化、置換操作にはコストがかかりすぎます ) 。

公開前にレンダラ プラグインのプロファイルを作成して、弱点を見つけて最適化します。

パフォーマンスが中程度のマシンでプラグインをテストして、ブラウザがクラッシュしないようにします。 現在、同時にレンダリングできるタイルの最大数は 64 です。

非同期 GeoJSON プラグインの注意事項

getGeoJSONAsync レンダリングプラグインで非同期機能を実装する場合は、ランタイムエラーが発生した場合にプロミスが常に拒否されるようにする必要があります。 そうしないと、約束が解決も拒否もされない場合、プラグインの実行が停止し、プラグインでランタイムエラーに関する通知がユーザーに送信されなくなります。

ES6 async/await 構文を使用することをお勧めします。 これにより async 、 main getGeoJSONAsync 関数から呼び出された関数のいずれかの内部にスローされた例外は、常にその約束を拒否します。 async/await構文 sugar よりもPromise構文を使用する場合は、エラーが発生した場合にこれらの約束が常に拒否されるようにする必要があります。 try/catch 考えられるエラーを追跡するために使用します。