GML、KML、GeoJSON-3109ポリゴンの高速レンダリング？

私はGeoserverと協力して、米国の下位48郡をオープンレイヤーに提供しています（3109ポリゴン-さらに多くの頂点）。郡はpostgisデータベースにロードされます。その量の頂点をクライアントにプッシュしようとするときの開発者の経験に興味があります。

どのWFS形式で最高の結果を達成しましたか？Geoserverへの追加のチューニングが使用されましたか？

タイル化されたWMSの方が高速であることを認識していますが、openLayersを使用してコロプレスマップの動的な変更を許可したいのです。ユーザーがフォームを送信し、Pythonスクリプトが呼び出され、マップdivを再ロードするために新しいレイヤーがopenlayersに返されます。また、オープンレイヤーのポリゴンの複雑さを軽減する前に、これをフル解像度の形式で試してみたいと思います。

たぶん、これはいくつかの新しいアイデアを引き起こします。ユーザーが多くの要素を含むマップを編集できるアプリケーションを実行しています。

すべてのデータをWFSとして送信する代わりに、WMSマップを使用し、ユーザーがクリックするか、選択を描画するときに、選択したアイテムをWFSとしてフェッチします。

更新をサーバーに送り返した後、WMSレイヤーを更新します。

その方法を示すOpenLayersの例がいくつかあります。おそらく少し調整する必要がありますが、OpenLayers + GeoServerは難しい部分を解決します。データはgzipで送信されるため、元の形式はそれほど重要ではありません。それはボトルネックではありません。OpenLayersとGeoServerが、情報を交換するために使用する形式を把握してください。

このアプローチは非常にうまくスケーリングします。接続が遅く、コンピューターが遅い人でも、マップを編集するために使用できます。数百の要素をフェッチするのは非常に迅速であり、編集するために同時にそれ以上必要になることはおそらくないでしょう。

_{最後に、トピック外ですが、クライアント側で地図データを使用する場合：OpenLayersでポリゴンを描画する場合、IE7以前では問題が発生することに注意してください。OpenLayersはクライアント側の描画にSVGを使用します。IE7以前にはサポートが組み込まれていません。これらのユーザーは、古いプラグインをダウンロードする必要があります。他のすべてのブラウザは問題ありません。}

私の意見では、GEOJSONは最適な形式であり、読みやすく、javascriptで使いやすく、一般にGML / KMLよりもサイズが小さくなっています。スタイルに関する情報を含めることもできます。こちらを参照してください。

公式の標準ではありませんが、リーフレットとオープンレイヤーの両方、およびqgisのような多くのgisデスクトップアプリでサポートされています。

GeoJSONを使用することは、システムを高速化するには良いスタートですが、十分ではない場合があります。ズームレイヤーごとに1つずつ、データレイヤーの複数のバージョンの構築を検討し、各バージョンに一般化/単純化の方法を適用する必要があります。クライアントは、選択したズームレベルに応じて、関連するレイヤーを要求する必要があります。これにより、サーバーとクライアント間で交換されるデータの詳細レベルが適切になり、ネットワーク転送とレンダリングの両方が大幅に向上します。さらに進むには、このドキュメントで説明されているように、ベクトルタイルと空間インデックスを使用してシステムを拡張できますが、openlayersおよびgeoserverがそれを処理できるかどうかはわかりません...まだ！

確かに：GMLを忘れてください。

pythonスクリプトを使用して新しいSLDファイルを作成し、リクエストとともにWMSサーバーに送信してください。

ここに例があります。

私はすでに同じような道を2回行っていますが、少数のポイントや本当に単純なポリゴン以外のものをクライアント側でレンダリングするのは良い考えではありません。そのアーキテクチャに自分を縛ると、撤回するのに費用がかかり、プロジェクトでは、さまざまな利害関係者/スーパーバイザーがシステムの能力を確認し始めるにつれて、要件の変更またはデータ量の増加が見られる可能性があります。ブラウザベースのクライアント側のレンダリング方法は拡張できません。

動的レンダリングが必要な場合は、2番目の@iantのアプローチを使用します。以前に、ここでは異なるが関連する問題の多くのオプションについて説明しました。また、クライアント側のレンダリングを支援するためにポリゴンの一般化を使用しましたが、それは間違いなく役立ちますが、ユーザーがさらにズームインするときに非一般化ポリゴンをプルダウンしたい場合など、より困難な問題を生成します。

たとえば、すべてのクライアントのハードウェア、ブラウザのバージョン、プラグインを知っているなど、既知のプラットフォームで作業している場合でも、これらのクライアントにどのような負荷がかかっているかはわかりません。この種のアプローチでは、ユーザーエクスペリエンスをスムーズに保つためにブラウザーが大量のCPU時間を取得できることが必要です。