[ユニオン (Union)] や [インターセクト (Intersect)] などのフィーチャ オーバーレイ ツールのパフォーマンスとスケーラビリティーを向上させるには、適応的再分割法と呼ばれる処理ロジックが使用されます。 このロジックは、仮想メモリーの空き容量の範囲内でデータを処理できない場合に開始されます。 仮想メモリーの空き容量を超えないように処理をすると、パフォーマンスが向上します。そのためには、マップ範囲全体を一度に処理するのではなく、要素に分割して要素ごとに処理を進め、徐々に全体を処理します。 マップを分割してできるこのような個々の要素を「タイル」といいます。タイル間にまたがるフィーチャはタイルのエッジで一時的に切断されますが、処理の最終段階で元どおりにつなげられます。 これらのタイルのエッジに作成された頂点は、出力フィーチャに残ります。 処理対象のフィーチャのサイズが非常に大きく、分割された要素の処理時に、仮想メモリーの空き容量が不足しているためにフィーチャを元の状態に戻せない場合には、タイル境界も出力フィーチャクラスに残される場合があります。
適応的再分割法の処理ロジックは、仮想メモリーの空き容量とデータの複雑性に応じて動的に変化します。 同じオーバーレイ処理を同じコンピューター上で実行しても、メモリーの空き容量が多少変化すると、異なる方法でデータがタイルに分割されることがあります。
適応的再分割法の処理ロジックを最適化するには、タイルの並列処理を追加します。 並列処理を有効にすると、異なるコアで処理される各タイルがシステム上の仮想メモリーの空き容量をすべて共有します。 つまり、複数のタイルを一度に処理するには、順次処理する場合よりも各タイルのサイズを小さくする必要があります。 適応的再分割法の処理ロジックでは、並列処理中に同時に処理されるタイルが仮想メモリーの空き容量の合計を超えないように、各タイルのサイズが追跡されます。 並列処理は、いかなる場合にも高速であるとは限りません。 この場合のパフォーマンスを上げるには、データのサイズと複雑性が並列処理の管理にかかるオーバーヘッドを超えていなければなりません。 並列処理に対応しているツールで並列処理を有効にする方法については、各ツールのドキュメントをご参照ください。
データの再分割がもたらす利点
各ツールは、コンピューターの仮想メモリーの空き容量 (システムも他のアプリケーションも使用していない空きメモリー) 内で処理を実行できる場合に、最適に動作します。 ただし、多数のフィーチャを含むデータセット、複雑なフィーチャ操作を伴う複雑なフィーチャ、または数十万個や数百万個の頂点を含むフィーチャ (あるいは、これら 3 つすべての組み合わせ) を操作する場合、最適に動作しない可能性があります。 タイルを使用しないと、利用可能なメモリが急速に消費され、オペレーティング システムはページングを開始します (二次記憶装置をメイン メモリーのように使用します)。 ページングはパフォーマンスの低下につながり、ある時点でシステムはリソースを使い果たし、処理が正常に実行されなくなります。 タイルはページングを回避するのに役立ちます。 極端な場合、プロセスを完了するためにメモリー管理処理がシステムに渡され、オペレーティング システムがすべてのリソースを自由に使えるようにすることで、処理を完了しようとします。
64 ビットのアプリケーションが主流になり始めた頃、すべての処理が速くなるであろうという印象が普通にありました。 ただし、常にそうなるとは限りません。 64 ビットの処理を実行すると、一度に多くのことができるので、パフォーマンスが上がった印象を受けるかもしれません。 作業量の増加という点から見ると、一部の処理は実行速度が遅くなっています。 また、すべてのデータをメモリーに挿入して処理することで処理を高速化できるという共通認識もありました。 このことは単純なデータには当てはまりますが、大規模で複雑な空間処理には当てはまりません。 オーバーレイ ツールの処理では、すべてのデータをメモリーに挿入し、一度にまとめて解析する処理は、先に説明した 1 つの上位レベルのタイルの処理に相当します。 この処理は、データを広範にタイル化する処理よりも時間がかかります。 パフォーマンスを上げるために、タイル化を縮小できますが、完全に除去することはできません。 64 ビットの処理を使用すると、タイルの並列処理も実行できます。 これにより、あらゆる状況でパフォーマンスの向上がもたらされます。
タイルの処理
すべてのプロセスは、データの範囲全体に広がる単一のタイルで開始されます。 1 つのタイル内のデータが大きすぎて仮想メモリーの空き容量内で処理できない場合、等しい 4 つのタイルに分割されます。 次に、処理がサブタイルで実行され、この 2 番目のレベルのタイルでもデータが大きすぎる場合には、さらに分割が実行されます。 各タイル内のデータが仮想メモリーの空き容量内で処理できるようになるまで、分割が続行されます。 次の例をご参照ください:
すべての入力フィーチャのフットプリントから始めます。
プロセスは全データセットの範囲全体に広がる 1 つのタイルで開始されます。 これはタイル レベル 1 と呼ばれます。
データが大きすぎてメモリーでは処理できない場合、レベル 1 のタイルは 4 つの等しいタイルに分割されます。 これらの 4 つのサブタイルはタイル レベル 2 と呼ばれます。
各タイルのデータのサイズによって、さらに分割されるタイルと、分割されないタイルがあります。
再分割を使用するツール
[解析ツール] ツールボックスに含まれる以下のツールは、大規模なデータを処理する際に適応的再分割法の処理ロジックを使用します。
- [バッファー (Buffer)] - ディゾルブ オプションを使用する場合。
- [クリップ (Clip)] - すべての状況に適用されるわけではありません。 現時点では、内部バッチ処理が多くの状況で使用されています。
- イレース (Erase)
- アイデンティティー (Identity)
- インターセクト (Intersect)
- スプリット (Split)
- シンメトリカル ディファレンス (Symmetrical Difference)
- ユニオン (Union)
- アップデート (Update)
[データ管理] ツールボックスに含まれる以下のツールも、大規模なデータセットを処理する際に適応的再分割法の処理ロジックを使用します。
- ディゾルブ (Dissolve)
- フィーチャ → ライン (Feature To Line)
- フィーチャ → ポリゴン (Feature To Polygon)
- ポリゴン → ライン (Polygon To Line)
適応的再分割法の実行中の進捗状況表示
適応的再分割法の処理ロジックは、処理が実行されているコンピューター上の使用可能なリソースの数に応じて動的に変化します。 解析が完了するまでのステップの数は設定されていません。 タイルの処理中に、メモリーの空き容量内でタイルを処理できない場合があります。 この場合には、タイルが分割され、新しい (分割された) タイルが処理されます。 メモリーの空き容量内で新しいタイルの 1 つが処理できなかったり、新しいタイルがどれも処理できなかったりすることもあります。 実行時間までに必要なタイルの数を効率的に算出する方法が存在しないため、標準のカウント ダウン進捗状況メッセージを提示することができません。 このため、適応的再分割法の処理ロジックを使用するツールに表示されるメッセージと進捗状況バーには、処理中の個々のタイルの進捗状況だけが示されます。
メモリー不足エラーやパフォーマンス低下によって処理が正常に実行されない
非常に大規模なフィーチャ (数百万の頂点を持つフィーチャ) を処理する場合には、適応的再分割法が役に立たないことがあります。 非常に大規模なフィーチャの分割と組み立てを、タイル境界を越えて何度も繰り返すと、非常に大量のメモリーが消費され、フィーチャが大きすぎる場合にはメモリー不足エラーやパフォーマンス低下が発生する可能性があります。 大きすぎるとは、どれくらいの大きさを指すのでしょうか？ これは、処理が実行されているコンピューター上の仮想メモリーの空き容量 (システムも他のアプリケーションも使用していない空きメモリー) によって決まります。 メモリーの空き容量が少ないほど、大きすぎると見なされるフィーチャのサイズが小さく、問題が発生する可能性が高くなります。 あるコンピューター設定ではメモリー不足エラーやパフォーマンス低下を発生させる大規模なフィーチャでも、別のコンピューター設定ではこれらの問題が発生しない場合があります。 別のアプリケーションで使用されているリソースの状況によっても、同じコンピューター上でメモリー不足エラーやパフォーマンス低下が発生したり、発生しなかったりすることがあります。 多数の頂点がある非常に大きなフィーチャの例としては、都市全体の道路の枠や、複雑な河口を表すポリゴンが挙げられます。
大きすぎるフィーチャを処理できる方法がいくつかあります。 おすすめできる方法の 1 つとして、処理の前に大きなフィーチャを小さなフィーチャに分割するための [フィーチャの分割 (Dice)] ツールの使用があります。
また、大規模なフィーチャに対して [マルチパート → シングルパート (Multipart To Singlepart)] ツールを使用する別の方法もあります。 [マルチパート → シングルパート (Multipart To Singlepart)] ツールを実行する前に、フィーチャクラスに一意の識別子フィールドがあることを確認します。これにより、このツールの実行が終了すると、パートごとに、そのパートが属していた元のフィーチャの識別子が割り当てられます。 多数のパートで構成されている大規模なフィーチャがある場合 (数十万個のパートを含む個々のフィーチャなど)、そのフィーチャを単一パートに変換すると、パートを個別に処理できるようになります。 必要な場合は、選択したオーバーレイ ツールを単一パートのデータに対して実行した後で、一意の識別子フィールドをディゾルブして、マルチパート フィーチャを再作成することができます。
過度にオーバーラップしているエリアを処理する場合にも、メモリー不足エラーやパフォーマンス低下が発生することがあります。 たとえば、ポイントの密集度が高いエリアで実行されたバッファー処理の結果に対して [ユニオン (Union)] ツールまたは [インターセクト (Intersect)] ツールを実行すると、過度のオーバーラップが生じます。 バッファー出力で、オーバーラップしている多数のバッファー フィーチャが生成されます。 バッファー フィーチャの密集度が高いエリア内の 1 つのポイントを選択すると、数千個、数万個、数十万個のオーバーラップしているバッファーが返される場合があります。 このバッファー出力に対して [インターセクト (Intersect)] ツールまたは [ユニオン (Union)] ツールを実行すると、それぞれが一意のオーバーラップ関係を表す多数のフィーチャが新しく作成されます。
2 つのフィーチャ レイヤーの例を以下に示します。最初のフィーチャ レイヤーには 10 個のフィーチャが含まれ、2 番目のフィーチャ レイヤーには 1 つのフィーチャが含まれています。
以下の図は、2 つの入力を使用した [インターセクト (Intersect)] ツールの結果を示しています。 入力に関係なく、すべてのフィーチャの交差が計算されます。 その結果、入力に含まれるフィーチャよりも多くなる可能性があります。 この場合、両方の入力に含まれるフィーチャ (11) よりも多くのフィーチャ (167) が出力に含まれています。
大規模かつ複雑なデータセットでメモリー不足エラーやパフォーマンス低下が発生しないようにするには、オーバーラップの複雑性を一部取り除き、オーバーラップ処理を繰り返し実行して、データを処理することが必要となります。 また、ペアワイズ オーバーレイ ツールを実行して、実現しようとしている機能に似た機能を提供しているかどうかを確認することもできます。
注意:
ペアワイズ ツールを使用する際には、提供される機能の違いと出力の違いにより、ワークフローに変更を加えることが必要となる場合があります。 詳細については、各ツールのドキュメントをご参照ください。ツールの処理中に、2 つ目のアプリケーションまたは処理を実行した場合にも、メモリー不足エラーが発生することがあります。 この 2 つ目の処理によって、適応的再分割法の処理で使用する必要のあるメモリーの空き容量の一部が使用されると、実際に使用可能なメモリー以外のメモリーが適応的再分割法の処理で使用される可能性があります。 大規模なデータセットの処理中には、同じコンピューター上でそれ以外の処理を実行しないことをおすすめします。
大規模なデータのデータ形式
エンタープライズ ジオデータベースとファイル ジオデータベースは、非常に大規模なデータセットに対応しています。 非常に大規模なデータセットや複雑なデータセットを処理する場合には、これらのジオデータベースを出力ワークスペースとして使用することをおすすめします。 エンタープライズ ジオデータベースのデータ読み込みポリシーの詳細については、データベース管理者にお問い合わせください。 未計画または未承認のデータの読み込み操作は、実行が制限される可能性があります。