Por qué Intersect da el ERROR 999999: Error al ejecutar la función Topología inválida [Demasiados puntos finales de la línea]?

Question

Estoy intentando ejecutar un proceso de Intersección en arcgis 10 sp 3 con 2 conjuntos de archivos (aspecto y pendiente) de hasta un MDE de 1m a través de un área de 65,000sq km. El aspecto tiene 9.930.384 registros y la pendiente tiene 31.435.462 registros (aproximadamente 12GB en total en 2 bases de datos de archivos).

He ejecutado la geometría de reparación unas 3 veces y ahora los conjuntos de datos no informan de ningún error (cada vez ha tardado más de 30h).

Ahora tengo

Ejecución (Intersect): Intersect " D:\SCRATCH\Projects\106\data\7_asp_Merge.gdb\asp_HghstRez_M_rep #" D:\SCRATCH\Projects\106\data\working\working.gdb\AsSl_Int TODOS # INPUT Hora de inicio: Sun Oct 23 02:19:10 2011 Características de lectura...

Procesamiento de baldosas...

ERROR 999999: Error en la ejecución de la función.

Topología inválida [Demasiados puntos finales de lineseg].

Fallo en la ejecución (Intersect).

Falló el dom 23 oct 04:09:12 2011 (Tiempo transcurrido: 1 horas 50 minutos 2 segundos)

¿Es realmente un problema de topología o de tamaño de archivo?

He intentado utilizar la herramienta ArcINFO SPLIT pero falla incluso con más de 1TB de espacio libre en la unidad y en un conjunto de archivos más pequeños provoca bordes dentados. No puedo utilizar DICE ya que las áreas de intersección entre el asp y la pendiente deben ser exactamente las mismas. Tengo entendido que en los conjuntos de datos grandes, ESRI fragmenta (automáticamente) los conjuntos de datos. ¿Hay alguna otra información que pueda proporcionar para resolver el problema?

Las especificaciones de las máquinas superan el mínimo de ESRI -tenemos 16 GB de RAM, Intel Xeon, Windows 7, 64 bits, 2 discos de 1 TB y más de 1,2 TB libres en las unidades. Todos los archivos utilizados en el proceso están en las unidades locales.

---

Acabo de encontrar esta explicación (2 de julio de 2012) que da muchos consejos útiles para resolver los problemas.

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

Answer 1

Muy pocas celdas contiguas en un MDE detallado tendrán valores idénticos de pendiente y aspecto. Por lo tanto, si las características de entrada representan áreas contiguas de pendiente y aspecto comunes, deberíamos esperar que el resultado de este procedimiento de intersección tenga, en promedio, casi una característica por celda.

Originalmente había 65.000 * 1000^2 = 6,5 E10 celdas en el MDE. Para representar cada una de ellas se necesitan al menos cuatro pares ordenados de coordenadas enteras de 4 bytes o flotantes de 8 bytes, es decir, de 32 a 64 bytes. Esto supone una necesidad de 1,3 E12 - 2,6 E12 bytes (1,3 - 2,5 TB). Ni siquiera hemos empezado a tener en cuenta la sobrecarga de los archivos (una característica se almacena como algo más que sus coordenadas), los índices o los valores de los atributos, que podrían necesitar 0,6 TB (si se almacenan en doble precisión) o más (si se almacenan como texto), además del almacenamiento de los identificadores. Ah, sí a ArcGIS le gusta mantener dos copias de cada intersección alrededor, duplicando así todo. Puede que necesites 7-8 TB solo para almacenar la salida.

Incluso si tuviera el almacenamiento necesario, (a) podría utilizar el doble (o más) si ArcGIS está almacenando en caché los archivos intermedios y (b) es dudoso que la operación se complete en un tiempo razonable, de todos modos.

La solución es realizar las operaciones de cuadrícula utilizando estructuras de datos de cuadrícula, no estructuras de datos vectoriales. Si la salida vectorial es absolutamente necesaria, realice la vectorización después de todas las operaciones de la red se han completado.

Answer 2

Mi experiencia con el uso de la herramienta de división y la geomtría de reparación. A mí me funciona porque en el que trabajé estaba usando una capa vectorial que convertí de raster a vector. Intenté primero con la herramienta de división y me dio el error. Así que tuve que utilizar la geomtría de reparación y depende del tiempo que se ejecute. Tuve que hacer esto dos veces porque cada vez que usted hizo cualquier cambio o editar, usted todavía tiene que volver a ejecutar repaire geomtry antes de hacer la división. funcionó para mí.

Por cierto, he ejecutado repair geomtry en ambas capas: shapefile y geodatabase de archivos. Le sugiero que ejecute reparar geomtry durante la noche.