サーバーから送信されたラスター データを表示するレイヤーを実装しようとしています。サーバー プロトコルによって送信されるデータは、広く使用されているブラウザーに組み込まれていません (これは jpeg2000 データです)。したがって、私は自分でデータをデコードし、セシウムに表示させます。
少し複雑な理由：
サーバーはステートフルであるため、クライアントとサーバーの両方がチャネルを維持する必要があります。チャネルは、単一の関心領域に関連付けられています。地域は時間の経過とともに変化する可能性がありますが、すべての時点で、サーバーがチャネルでデータを送信する地域は 1 つだけです。セッションでいくつかのチャネルを使用できますが、チャネルが非常に少ないとサーバーのパフォーマンスが低下します。
関心領域の解像度は均一です (したがって、3D では問題があります)。
サーバーは、データのプログレッシブ送信をサポートしており、使用可能なネットワーク リソースが非常に少ないため、使用したいプロパティ (jpeg2000 の「品質レイヤー」) を徐々に向上させます。
デコードは、CPU 時間の点で重いです。
最初の段階として、レンダリング エンジンによって要求された各タイルのチャネルを作成するだけの ImageryProvider を実装しました。それは機能しましたが、接続が多すぎて、プログレッシブ レンダリングを楽しめませんでした。さらに、パフォーマンスが低かったため、セシウム ビューアのビュー エリア内のタイルを最初にデコードする優先メカニズムを実装することで、問題はほぼ解決されました。
次に、表示領域に応じてチャネルの関心領域を変更する自己レンダリング ラスター「レイヤー」を実装しました。その後、複数チャンネルの問題は解決され、プログレッシブ レンダリングを楽しむことができました。ただし、次の問題が発生しました。
a. デコードされたピクセルを表示するために使用した方法は、デコードされたピクセルを含む単一のキャンバスを表示する画像プロバイダーを実装することでした。画像が更新される (再配置またはプログレッシブ デコード) たびに、古い画像プロバイダーを削除して新しいものに置き換える必要がありました。これは正しい方法ではないと思います。また、古いプロバイダーを新しいプロバイダーに置き換えると、z オーダーが間違っているなどの悪い動作が発生する可能性があります。これらの問題のいくつかは、イメージ マテリアルでプリミティブを使用することで解決される可能性があります。ただし、画像のデータ URL 形式を使用する必要があります。これを行うと、キャンバスからデータ URL への多くの変換が発生するため、パフォーマンスが低下します。
b. ビュー領域をサーバーに送信するために、ビュー領域を理解するための特別なコードを作成する必要がありました (pickEllipsoid および同様の機能を使用)。このコードは、Cesium エンジン内で行われる何かの複製だと思います。さらに、pickEllipsoid が 2D でサポートされていないことをいくつかのディスカッションで見ました。一般的に、自分でそのコードを実装するのではなく、ビュー領域を計算する関数があることを非常に嬉しく思います。
c. 私がそれを実装した方法は、API の問題を引き起こします: 画像プロバイダー (addImageryProvider() メソッドと removeLayer() ) を追加および削除するための Cesium の優れた API とは対照的に、私の実装では、ユーザーは私が彼に公開するメソッドのみを使用する必要があります。 (たとえば、Viewer を引数として受け入れる add() メソッド)。
d. 3D モードでは、解像度が均一でない場合、画像は近接領域で鮮明ではありません。サーバーの動作方法に固有の問題であることはわかっています。指摘してください。
ここで本当に欠けているのは、ImageryProvider のインターフェースよりも強力なプラグインを実装する方法だと思います: レンダリング エンジンからビュー エリアの変更イベントを受け取り、いつ、どのように決定できるかを決定できる自己レンダリング ラスター レイヤーを実装するタイルを更新します。別の代替手段 (これは私にとってはさらに優れていますが、他の人にとっては再利用性が低いと思います) は、ビュー領域内のタイルのリストを ImageryProvider 実装に公開することです。
このシナリオに対処する正しい方法は何ですか?