Intersect neden ERROR 999999 veriyor: İşlev yürütülürken hata oluştu Geçersiz Topoloji [Çok fazla lineseg uç noktası]?

65.000m² alan üzerinde 1m DEM kadar 2 dosya setleri (en boy ve eğim) ile arcgis 10 sp 3 Intersect işlemi çalıştırmak çalışıyorum. Boyut 9.930.384 kaydı ve eğimin 31.435.462 kaydı vardır (2 dosya coğrafi veritabanında toplam yaklaşık 12GB).

Yaklaşık 3 kez onarım geometrisi çalıştırdım ve şimdi veri kümeleri herhangi bir hata bildirmiyor (her seferinde 30 saatten fazla sürdü).

Şimdi anladım

Yürütme (Kesişim): "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 Başlangıç ​​Saati: Paz 23 Ekim 02:19:10 2011 Okuma Özellikleri ...

Fayans İşleme ...

HATA 999999: İşlev yürütülürken hata oluştu.

Geçersiz Topoloji [Çok fazla lineseg uç noktası.]

Yürütülemedi (Kesişim).

23 Ekim'de başarısız oldu 04:09:12 2011 (Geçen Süre: 1 saat 50 dakika 2 saniye)

Bu gerçekten bir topoloji sorunu mu yoksa dosya boyutu sorunu mu?

ArcINFO SPLIT aracını kullanmaya çalıştım, ancak sürücüde 1 TB'ın üzerinde boş alan olsa bile ve daha küçük dosya setinde pürüzlü kenarlara neden oluyor. Asp ve eğim arasında kesişen alanlar tam olarak aynı olduğundan DICE'ı kullanamıyorum. Büyük veri kümelerinde ESRI'nin veri kümelerini (otomatik olarak döşer) çatladığını anlıyorum - bu sorunlara yol açabilir mi? Sorunu çözmek için verebileceğim daha fazla bilgi var mı?

Makinelerin özellikleri minimum ESRI'den daha fazla - 16GB RAM, Intel Xeon, Windows 7, 64 bit, 2 x Bir TB disk ve sürücülerde 1,2 TB'tan fazla boş alan var. İşlemde kullanılan tüm dosyalar yerel sürücülerdedir.

sorunları çözme konusunda birçok yararlı ipucu veren bu açıklamayı (2 Temmuz 2012) buldum.

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

Ayrıntılı bir DEM'deki çok az bitişik hücre hem eğim hem de en boy açısından aynı değerlere sahip olacaktır. Bu nedenle, girdi özellikleri ortak eğim ve ortak yönün bitişik alanlarını temsil ediyorsa, bu kesişim prosedürünün sonucunun, hücre başına ortalama olarak neredeyse bir özelliğe sahip olmasını beklemeliyiz.

DEM'de orijinal olarak 65.000 * 1000 ^ 2 = 6.5 E10 hücresi vardı. Bunların her birini temsil etmek için 4 baytlık tamsayı veya 8 baytlık kayan koordinatlar veya 32-64 baytlık en az dört sıralı çift gerekir. Bu 1.3 E12 - 2.6 E12 bayt (1.3 - 2.5 TB) gereksinimidir. Hatta dosya yükünü (bir özellik yalnızca koordinatlarından daha fazlası olarak saklanır), dizinleri veya kendilerinin 0,6 TB (çift kesinlikte saklanırsa) veya daha fazlasına ihtiyaç duyabilecek öznitelik değerlerini hesaba katmaya başlamıyoruz bile metin) ve ayrıca tanımlayıcılar için depolama alanı. Oh, evet - ArcGIS , her kavşağın iki kopyasını etrafta tutmayı ve böylece her şeyi ikiye katlamayı seviyor . Çıktıyı depolamak için 7-8 TB gerekebilir.

Gerekli depolama alanına sahip olsanız bile, (a) ArcGIS ara dosyaları önbelleğe alıyorsa, bunun iki veya daha fazlasını kullanabilirsiniz ve (b) yine de işlemin makul bir zamanda tamamlanacağı şüphelidir.

Çözüm, vektör veri yapılarını değil, ızgara veri yapılarını kullanarak ızgara işlemleri gerçekleştirmektir. Vektör çıkışı kesinlikle gerekliyse, tüm ızgara işlemleri tamamlandıktan sonra vektörleştirmeyi yapın .

Bölünmüş takım ve onarım geomtri kullanma deneyimim. Benim için çalışıyor çünkü üzerinde çalıştığım rasterden vektöre dönüşüm yaptığım vektör katmanını kullanıyordu. Önce aracı bölmeye çalıştım ve bana hata verdim. Bu yüzden, onarım geomtry kullanmak zorundaydım ve ne kadar sürecek bağlıdır. Bunu iki kez yaptım çünkü her değişiklik ya da düzenleme yaptığınızda, ayrılmadan önce repaire geomtry'yi yeniden çalıştırmanız gerekiyor. benim için çalıştı.

Bu arada, her iki katmanda da geomtry onarımı yaptım: shapefile ve file geodatabase. Bir gece tamir geomtry çalıştırmanızı öneririm.