ベクターデータを画像としてエンコードするプロトコルに向けて

これは、GISCloudのようなレンダリングパフォーマンスでベクターポリゴンを作成するというこの質問のフォローアップです。

彼の答えで、八木は地理情報を画像形式でエンコードし、それをブラウザでデコードするための理論的根拠を概説しています。彼は、「現在、これを行うには、自分で転がさなければならない」と述べています。また、彼は現在、このための標準がないことを観察しています。

素晴らしいパフォーマンスが実証されていることを考えると、コミュニティは標準の恩恵を受ける可能性があるようです。私の問題の理解から、それを処理する標準的な方法を実装できるように思えます。それをB-WFSと呼びます。

私の質問は、ベクターデータを画像としてエンコードするための便利なプロトコルはどのようなものでしょうか？複雑になりすぎて有用に取り組むことができないものがありますか、それとも「誰もまだこれをやっていません」というケースですか？

web-mapping vector

— カニスラフス
ソース

私は無知でごめんなさい、多分私はポイントを得られなかったが、カラーテーブルを持つジオティフは仕事をしませんか？

— パブロ

私の無知もごめんなさい;）私はカラーテーブルが何であるかわかりませんが、私はそうは思いません。目標は、対応するメタデータとともに画像を渡すことではありません。あなたが言及したように、それは解決された問題です。目標は、人間が読めるUTF-8よりもコンパクトな形式のメタデータを持つベクトルデータを渡すことです。JavaScriptにはバイナリデータを処理する能力が不十分であるため、回避策は、データをイメージバイナリでエンコードし、HTML 5 Canvasを使用してイメージをデコードし、それをベクターオブジェクトに変換することです。

— -canisrufus

@Pablo（解析ではなく）ネットワークI / OがWeb上のベクトルを処理する際のボトルネックであると仮定し、バイナリエンコードされたベクトルを処理する確立された方法があると、パフォーマンスの良いWebマップを簡単に記述できるはずです。

— -canisrufus

おもしろい、今ではそれを手に入れました...私は今、ウェブマップで作業し始めており、私はまだ基本を学んでいます。ところで、カラーテーブルまたはカラーマップは、ラスタセル値をクラスに関連付けるテーブルです。

— パブロ

@monkutええ、違います。:)一連のベクトルをラスタライズすることは、単にレンダリングすることです。出来上がり。ラスター！この質問で話していたことは異なります。リンクした質問のRagiの答えを読んでください。それが私の意味を説明し始めるはずです。それでもはっきりしない場合は、実際の答えを書くのに時間がかかります。

— -canisrufus

回答:

これは不必要な回避策であることがわかります。JavaScriptのアップグレードの一部であるXHR2では、何も強制せずにバイナリデータのインポートと解析が可能になります。

— カニスラフス
ソース

WFS実装仕様 04-094の9.4節では次のように記述されているため、個別の標準である必要はありません。

その他の出力形式（古いバージョンのGML、非XML、バイナリ、およびベンダー固有の形式を含む）も、outputFormat属性の適切な値が機能ドキュメント[13節]でアドバタイズされる限り可能です。この仕様では、そこにリストされている各出力形式の機能文書に記述的な物語を含めることを推奨しています。

バイナリサポートを追加する最も簡単な方法は、JSONストリームをGZIPすることです。この場合、ほとんどのブラウザで解凍が自動的に処理されます。とはいえ、私はそれを試したことはありませんが、サーバー側とクライアント側の両方で最小限の作業しか必要としないでしょう。

— マージーバイキング
ソース

標準に関するポイントについては+1。ジッピングは、同じ意味でのバイナリエンコーディングではありません。圧縮されたジオイソンと画像にエンコードされたジオメトリの2つのアプローチのパフォーマンスへの影響についての質問は、確かに検討する価値があります。

— -canisrufus

そうです、これはネットワークのボトルネックを減らしますが、クライアントとサーバーにより大きな負荷をかけます。しかし、画像内のベクターデータのエンコードは、ベクターデータの可変長のため、IMOの準最適なアプローチです。また、ベクターデータの性質を難読化しています。より適切なアプローチは、ベクター用とラスタ用の2つの並列データストリームを用意し、それらを異なるサーバーとストレージデバイスで処理し、クライアントで結合することです。

— MerseyViking

ベクトルデータの可変長の問題は、ネットワークが送信パケットを処理する方法と基本的に同じ方法で処理できます。私はその次善のものに同意しますが、JSがバイナリをうまく処理できないという事実によって、私たちはそれに押し込まれているようです。時間があるので、自分で何かを書いて実装します。何かが

— うまくいっ

Ragiは彼の答えでそれを明確に定義したと本当に思います。同意しなかったことに同意します。:)バイナリ形式が全体的に高速なデータ転送形式になる可能性があるという仮説が間違っている可能性があります。違いはごくわずかです。「パフォーマンスへの影響は...調査する価値がある」と私は言いました。明らかに、バイナリ形式を定義してから勝利を宣言することはできません。見えるよ！

— -canisrufus

@MerseyVikingもう一度答えを繰り返さずに、CPUサイクルの観点からこれを説明します（前提条件は時期尚早の最適化に関するものです）。L1キャッシュへのアクセス= 1 CPUサイクル、L2 = 14サイクル、RAM〜250サイクル、ディスク= 41,000,000、ネットワーク（帯域幅に依存するため、親切にしてください）= 240,000,000。I / Oは、ディスクベースまたはネットワークベース（私たちの場合）にかかわらず、桁違いに遅くなります。どのようなスケールでも、負荷をスペクトルの最後の部分から最初の部分に「時期尚早」にシフトしていますか？

— ラギヤーサーバーフム