ディゾルブ機能はジオプロセシングの効率を向上させますか？

大量のラインデータセット（> 140,000フィーチャ）があります。必要な時間または（より重要なことに）使用されているメモリのいずれかに、処理上の利点があります。

• 実行中に溶解させ、実行する前に、データをバッファに？
• 2つのIdentity操作への入力でDissolveを実行する方法

通常、すべてのジオプロセシングが完了するまで待ってから、最後に1つのディゾルブを実行します。しかし、私は誰かの非常に古いスクリプトをデバッグしており、彼が理由で繰り返しすべてを溶解していたのか（Arc 9.3に戻っている）、それとも代替案について考えていなかったのかは不明です。（同じスクリプトがジオプロセシングツール間でデータを繰り返し投影するため、ロジックにはすでに疑問があります。）

メモリの使用が主な関心事である場合、多くの小さな（頂点数が少ない）機能は、いくつかの非常に大きな（頂点数が多い）機能よりも好みに合うでしょう。ただし、「機能が多すぎる」と「頂点が多すぎる」と処理速度が追いつかなくなる可能性があります。

2つのフィーチャクラス間のすべてのフィーチャに対してすべてのフィーチャを処理するためにアルゴリズムをどのように構造化する必要があるかを考える場合、多重にネストされたループ（FC1とFC2のフィーチャ、およびFeature1とFeature2の頂点）で作業しています。描画などの操作では、多くの場合、描画リクエストの数は各リクエストの頂点よりも重要ですが、テーマオンテーマの操作では、主要なアルゴリズムは各F1 / F2ペアの頂点の数に基づいている可能性があります、 " ビッグO表記 "の "O（N * M）"（操作を完了する時間は、関係する頂点の数の係数に関連しています）で、両方のデータセットの大きなフィーチャの場合、 O（N ^ 2）は、これまでに完了したジョブについて心配させます。

大規模な機能（ロシア、カナダ、米国、オーストラリア、ブラジル、ノルウェーなど）を5度グリッド（フィッシュネット）でオーバーレイして、中間処理の機能の複雑さを軽減することに成功しました。頂点が制限された1：15m COUNTRIESレイヤーでのポイントインポリゴン操作は、元のテーブルよりも100〜1000倍高速に実行されます（機能カウントが20倍増加するだけです）。ただし、特に誤った境界が存在する場合は、1対多および多対多の関係を正しく処理するために、処理ロジックで注意する必要があります。

また、小さい機能を使用する場合の節約には「利益の減少」という側面もあります。90、45、30、20、15、10、5、3、2と交差するパフォーマンスをテストすることで、5度グリッドに落ち着きました。 1度グリッド。フィーチャの総数が膨らむにつれて、処理時間が驚くほど増加しました。

そこです、価値がおそらくと他の（均衡RAMの利用上の一つのアプローチにコミットする前に、実際のデータ（テストサブセットを単純化していない）での動作のためにいくつかのテストを行うための努力であるので、より多くの頂点を持つ少数の特徴は、より効率的な時間は、実行時）。

注：最新のハードウェアでグリッド作成演習を再実行し、30度のオーバーレイで最適なパフォーマンスを得たため、小さすぎる機能のリスクが高まり、生産データでの評価の重要性が高まりました。

溶解操作は、通常、特に共有境界の有意な長さを有する層に、層内のフィーチャ、アーク及びノードの数を減少させます。バッファリング操作中に費やされる時間はノードの数に大きく依存するため、Dissolveで前処理すると、実行時間（およびメモリ要件）が大幅に削減される可能性があります。あなたのケースでそれが価値があるかどうかは、（データレイヤーに応じて）ノード数を減らすことができる範囲と、バッファリングと比較したDissolve操作の効率に依存します。私の経験では、Java Topology Suiteを使用すると、Dissolve操作は、Dissolveのパフォーマンスはライブラリによって大幅に異なりますが、バッファリング。他の考慮事項は、Dissolveがトポロジエラーの影響を強く受けることです。レイヤーにエラーが含まれている場合は、Dissolve操作の前にベクタークリーニングを実行する必要があります。これにより、ワークフローランタイムが増加します。