より多くのクライアント側機能をサポートするOpenLayersの代替案[終了]


14

ポイント機能にクライアント側のレンダリングを理想的に使用し、プラグインが不要なシステムのさまざまなアーキテクチャを検討しています。私はこの質問に答えて開発したこのアプリケーションを使用し、OpenLayersと500で著しく遅れており、1,000を超える苦労を始めています。ランダムに生成された機能にはイベントハンドラーはないようで、すべて同じシンボル体系を使用しています。

私は、最大1,000個の機能、最大10個の異なるシンボル、すべてクリックハンドラーとマウスオーバーハンドラー、および性能の低いプラットフォームを表示する予定です。

特にこのGIS Cloudの例を見て、クライアント側のパフォーマンスが向上することを期待していました-動作が異なることはわかっています(HTML5キャンバスとSVG)が、パフォーマンスの違いは非常に顕著です。

私の主要な質問(あなたがとても親切なら)は:

  1. ランダムポイント生成アプリケーションは、作成/使用した他のOpenLayersアプリケーションのパフォーマンスを代表していますか?
  2. WMSサービス(これを使用する必要があります)をサポートし、Flash / Silverlight /その他のプラグインを使用せずにクライアント側の機能で高速化する、実績のある無料の代替WebマッピングAPIはありますか?
  3. 私が調査すべきことに関する他の提案はありますか?

主にサーバー側のレンダリングに依存することはオプションですが、ユーザー数の拡大とUIの応答性に関する懸念から、私もクライアントもこれを回避したいと考えています。


5年前のデュアルコア、Firefox 8でそのアプリを使用した3 GB RAMデスクトップ(1 GB LinuxディストリビューションISOのダウンロード中)では、1,000ポイントがほとんど瞬時に描画され、苦労することはありません... 10,000は約1.5秒かかります。
-user2856

@LukePinnerは、ただ素早く描画するだけで、スムーズにパン/ズームできるのですか?データを取得してフィーチャを描画することも私にとっては問題ありませんが、問題はマップインタラクションです。
トムファンブ

ipad2でアプリを試したところ、1000ポイントを非常にうまく処理しました。10Kポイントでは、最初にレンダリングするのに数秒かかりますが、その後はかなりうまく処理されます。必要に応じて、OLベクターレイヤークラスを常にサブクラス化し、カスタムクラスを実装できます。一例を挙げてみましょう。
unicoletti

はい、パン/ズームに問題はありません。私の1.6ghz Atomネットブックでは1Kポイントはかなり遅くなりますが:)
user2856

回答:


23

最初の質問への回答はYesです。かなり一般的な構成でOLを使用しています。パフォーマンスを改善するために使用できるトリックがあります。これについては後で説明します。

質問2への回答は多分(特に堅牢性に関して)です。このサイトで代替のリストを検索できます(現時点で思い浮かぶのはLeafletです)。

質問3への回答:測定から始めます:

アプリのローカルコピーを編集して、レンダーがベクターレイヤーのオプションリストで明示的に指定されるようにしました。テスト中、Canvasレンダラーを省略してから、別のページで実験をリロードします。

var pts = new OpenLayers.Layer.Vector("Points", {renderers: ["Canvas", "SVG", "VML"]});

それが過ごしたどのくらいの時間出力しているので、私は、再描画機能にタイマーを追加描画します

function redraw() {
var start = (new Date).getTime();
[...]
var diff = (new Date).getTime() - start;
console.log("redraw completed in "+diff+"ms");

その後、OSX SLでChrome 17とFirefox 8.0.1の両方で、1000および5000の機能を使用していくつかの実行を試みました。驚いたことに、SVGレンダラーはCanvasレンダラーよりも平均で20%高速です!(注:Windowsでは、jsの時間はOSXほど正確ではないため、結果の一貫性が低下する可能性があります)。

これとあなたの言うこと

問題はマップの相互作用です

、私見では、ホットスポットがベクターの機能の処理にあることを教えてくれます。私のアプリで作業しているときに、最近それを見て、サブクラス化して、単純な点には役に立たない複雑なコードをすべて取り除くことにしました。確かに私はかなり乱暴になり、OpenLayers.Geometry.Pointへの依存関係を削除し、私のバージョンはx、y属性を持つ単純なjsオブジェクトで動作するようになりました。

あなたのオプションは、利益/費用の降順です:

最初のオプションは、次のようにベクトルレイヤーに戦略オプションを設定することにより、サーバー側の可視ポイントフィルタリングすることです。

 strategies: [new OpenLayers.Strategy.Refresh({force:true}), new OpenLayers.Strategy.BBOX({ratio:2, resFactor: 3})],

この方法では、クライアント側に描画される機能の数を拡大すると、すべてではなく、その範囲で表示される機能に制限されます。

2番目のオプションとして、カスタマイズされたVector / Rendererの作成を検討できます。カスタムの、短縮された、より高速な実装の例は、こちらの githubページ入手できます。すべての用途に適しているわけではありませんが、私が提案していることを大まかに理解するには十分でしょう。

ユーザーが完全にズームアウトするときの3番目のオプションは、ある種のサーバー側のクラスタリング機能を実装して、近いポイントが単一のポイントにマージされ、描画される機能の数を減らすことです。


詳細かつ徹底的な対応に感謝します。私は、サーバー側のクラスタリングを検討し、キャッシュ戦略と組み合わせて、必要な場合にのみ操作が行われることを期待しています。サーバー側のオプションの1つはMapGuideであるため、ポイントを取得およびクラスタリングするためのアプローチは完全にカスタマイズできます。また、レンダラーオプションを試して、どのような違いが生じるかを確認します。
-tomfumb

1
私のプロジェクトで使用するベクター/キャンバスレンダリーの例へのリンクを追加しました。
ユニコレッティ

すごい単純化された例は大きな違いを生みます。それは本当に印象的です。私は1,000個の機能の苦労から10,000個の機能の飛行に
移行しました-tomfumb

最初の例(swingley.appspot.com)を変更して、OL Canvasレンダラーとポイントの塗りつぶしを使用しました。ズームとパンのパフォーマンスは、実際にはTagCanvasとTagVectorに非常に似ています。また、変更で削除したヒットテスト機能を再実装して、比較パフォーマンスをテストできるようにしました。Tag*アプローチは、ヒットした機能(5000のうち)を特定するのに約20%高速でした。カスタムクラス、および(私のテストで)同様の性能を更新/書き込み中に多大な労力を考えると、私はバニラOLが何ができるかを見ると思う
tomfumb

これは、ヒットテストがすべてのフィーチャを別のキャンバスに再描画するため、更新ごとに2回描画されるためです。
ユニコレッティ

0

UTFGridTileMillを使用すると、かなり良いパフォーマンスで無制限のポイントを表示できます。n個のランダムポイントを表示することは、そのような状況やGISCloudまたは同様の魔法では機能しないような不自然な例ですが、ベクターパフォーマンスのハッキングには通常、完全なデータセットといくつかの前処理の知識が必要なため、TileMillとGISCloudたくさんのタイル。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.