Intersectがエラー999999を返す理由：関数の実行中にエラーが発生しました[トポロジが無効です[lineegエンドポイントが多すぎます]]

65,000sq kmの領域全体で最大1mのDEMから2つのファイルセット（アスペクトとスロープ）を使用して、arcgis 10 sp 3でIntersectプロセスを実行しようとしています。アスペクトには9,930,384個のレコードがあり、スロープには31,435,462個のレコードがあります（2つのファイルジオデータベースで合計約12GB）。

ジオメトリの修復を約3回実行しましたが、データセットでエラーが報告されなくなりました（毎回30時間以上かかりました）。

今私は得る

実行（インターセクト）：インターセクト "D：\ SCRATCH \ Projects \ 106 \ data \ 7_asp_Merge.gdb \ asp_HghstRez_M_rep＃" D：\ SCRATCH \ Projects \ 106 \ data \ working \ working.gdb \ AsSl_Int ALL＃INPUT開始時間：日Oct 23 02:19:10 2011読書機能...

タイルを処理しています...

エラー999999：関数の実行中にエラーが発生しました。

トポロジが無効です[lineegエンドポイントが多すぎます。]

（交差）の実行に失敗しました。

2011年10月23日04:09:12に失敗（経過時間：1時間50分2秒）

これは本当にトポロジの問題ですか、それともファイルサイズの問題ですか？

ArcINFO SPLITツールを使用しようとしましたが、ドライブに1TBを超える空き容量があっても失敗し、小さいファイルセットではエッジがギザギザになります。ASPとスロープの間で交差する領域は完全に同じである必要があるため、DICEを使用できません。大規模なデータセットでは、ESRIがデータセットをクラック（自動的にタイル化）することを理解しています。これにより問題が発生する可能性がありますか？問題解決のために提供できる情報はありますか？

マシンの仕様はESRIの最小要件を超えています。16GBのRAM、Intel Xeon、Windows 7、64ビット、2 x One TBディスク、ドライブに1.2 TB以上の空き容量があります。プロセスで使用されるすべてのファイルはローカルドライブにあります。

この説明（2012年7月2日）を見つけただけで、問題の解決に役立つヒントがたくさんあります。

http://blogs.esri.com/esri/arcgis/2010/07/23/dicing-godzillas-features-with-too-many-vertices/

— ジョージC
ソース

Windowsオペレーティングシステムのファイルサイズ制限は2 GBです。（XPでは/ 3GBで3GB）。大規模なデータセット「タイリング」リソース

— SPILLED

Mapperzが送信したリンクからの重要な情報：「エンタープライズジオデータベースとファイルジオデータベースにはこの制限がないため、非常に大きなデータセットを使用する場合の出力ワークスペースとして推奨されます。」

— RyanKDalton、2011年

傾斜角とアスペクトラスターはありますか？もしそうなら、空間アナリストはいますか？

— Kirk

@Mapperz、それはファイルシステムに依存します。FATは2ギガバイトに制限され、FAT32は4ギガバイトとNTFSはに応じて無制限である：microsoft.com/resources/documentation/windows/xp/all/proddocs/...

— blah238

Georgeのラスター計算では、一般的なセルサイズ（1mなど）にリサンプリングするか、異なるパッチを個別に処理できます。30mの解像度で計算された勾配またはアスペクトは、1mの解像度で計算されたものと正確に比較できないため、多少の検討に値します。この計算の目的に関する情報がない場合、一般的なアドバイスをすることは困難です。

— whuber

回答:

詳細なDEMのほとんどの連続したセルは、勾配とアスペクトの両方の値が同じになります。したがって、入力フィーチャが共通の傾斜と共通のアスペクトの隣接する領域を表す場合、この交差手順の結果は、平均して、セルごとにほぼ1つのフィーチャを持つと期待できます。

DEMには元々65,000 * 1000 ^ 2 = 6.5 E10セルがありました。これらのそれぞれを表すには、4バイト整数または8バイト浮動座標、または32-64バイトの少なくとも4つの順序付けられたペアが必要です。これは1.3 E12-2.6 E12バイト（1.3-2.5 TB）の要件です。ファイルのオーバーヘッド（機能は単なる座標以外に保存される）、インデックス、または属性値も考慮していません。これらは、0.6 TB（倍精度で保存する場合）またはそれ以上（保存する場合）テキスト）、さらに識別子のストレージ。ああ、そうです。ArcGISは、各交差点の2つのコピーを保持して、すべてを2倍にすることを好みます。出力を保存するためだけに7〜8 TBが必要になる場合があります。

必要なストレージがあったとしても、（a）ArcGISが中間ファイルをキャッシュしている場合、これを2倍（またはそれ以上）使用する可能性があり、（b）とにかく、操作が妥当な時間内に完了するかどうか疑わしいものです。

解決策は、ベクトルデータ構造ではなく、グリッドデータ構造を使用してグリッド操作を実行することです。ベクトル出力が絶対に必要な場合は、すべてのグリッド操作が完了してからベクトル化を実行してください。

— whuber
ソース

多くの悲しみをもって受け入れられました。30m、10m、1mのデータセットを組み合わせる代わりに、asp + slp + vegの交差/スコアリングを各データセットで個別に実行し、それらをマージしています。

— GeorgeC

空間分割戦略を使用することで、プロジェクトを完成させることができました。処理に7時間かかり、クラッシュすることもあるデータセット。6つの部分に分割すると約100分で処理され、その後マージに10分かかりました。これに約40分を追加してモデルを変更し、最小の入力で（反復ごとに）複数のパーツを効率的に処理します。基本的に、（少なくとも）処理時間の半分を節約できます。そのため、通常200時間近くかかっていたプロセスは、50時間未満で約15時間の「実際の」作業（データの分割方法の決定、モデルへの変数の入力など

— だけでした

分割ツールと修復ジオメトリを使用した私の経験。私が取り組んだのはラスターからベクターへの変換を行ったベクターレイヤーを使用していたので、私にとってはうまくいきました。最初にツールを分割しようとしましたが、エラーが発生しました。だから、私は修理ジオメトリを使用する必要がありました、それはそれがどれだけ長く走るかに依存します。変更または編集を行うたびに、分割を行う前にgeomtryの修復を再実行する必要があるため、これを2回行いました。それは私のために働いた。

ちなみに、シェイプファイルとファイルジオデータベースの両方のレイヤーでgeomtryの修復を実行しました。修復ジオメトリを一晩実行することをお勧めします。

— プローブ
ソース

もう一つ忘れました。このようなことをするたびに、新しいArcMapを開いてこれらのツールを実行することをお勧めしますか？既に開いている一時ファイルを消去して閉じ、ArcMapを開きます。温度を一掃します。それは私の1セントの提案です。

— PROBERT、2011年

ありがとう。geomを3〜4回実行しましたが、データセットでエラーが報告されなくなりました。これは通常は機能しますが、データセットはwhuberの説明のとおりに非常に大きくなると思います...

— GeorgeC

ジョージ、私はそれがあなたのために働いてうれしいです。ええ、私はどのようなwhuberの説明を読みましたが、あなたへの私の質問は、傾斜とアスペクトをマージしましたか？その場合、分割ツールを使用するときに、マージしたこれらのレイヤーを分割するためにどのフィーチャレイヤーを使用しましたか？たとえば、スロープと標高をマージしたレイヤーで分割するには、24クワッド（そのうちの24はそれほど大きくない）を使用する必要がありました。たぶん、マージされたレイヤーで分割できる小さなレイヤーに絞り込んでみてください。

— ＰＲＯＢＥＲＴ

スロープとアスペクトをマージしましたが、機能しましたが、適切なプロセスではありませんでした。交差する必要があり、機能しません。分割するために、全国の100kトポマップグリッドのコピーを取得し、それをASPとスロープに別々に使用しました。このゾーンは30枚のマップシートで覆われています。

— GeorgeC

ジオメトリをクリーンにするために100kの地形図グリッドを実行しましたか？私が尋ねたので、私はいくつかのエラーを検出し、クリーンな修理をしなければなりませんでした。だから、それは私のものでした。それでも問題が解決しない場合は、国の100kをより小さな問題に分割してみてください。それらを3つに分けるように？

— PROBERT、2011年