¿Por qué Intersect da ERROR 999999: Error al ejecutar la función Topología no válida [Demasiados puntos finales lineseg]?

Estoy tratando de ejecutar un proceso de Intersect en arcgis 10 sp 3 con 2 conjuntos de archivos (aspecto y pendiente) desde un DEM de 1m en un área de 65,000sq km. El aspecto tiene 9,930,384 registros y la pendiente tiene 31,435,462 registros (aproximadamente 12 GB en total en 2 bases de datos geográficas de archivos).

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

Ahora consigo

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 ALL # INPUT Hora de inicio: Sun 23 de octubre 02:19:10 Funciones de lectura de 2011 ...

Procesando Azulejos ...

ERROR 999999: Error al ejecutar la función.

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

Error al ejecutar (Intersecar).

Falló el dom 23 de octubre 04:09:12 2011 (Tiempo transcurrido: 1 hora 50 minutos 2 segundos)

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

He intentado usar la herramienta ArcINFO SPLIT, pero falla incluso con más de 1 TB de espacio libre en la unidad y en un conjunto de archivos más pequeño causa bordes irregulares. No puedo usar DICE ya que las áreas que se cruzan entre el asp y la pendiente deben ser exactamente las mismas. Entiendo que en grandes conjuntos de datos, las grietas de ESRI (mosaicos automáticos) los conjuntos de datos, ¿esto puede presentar problemas? ¿Hay más información que pueda proporcionar para resolver problemas?

La especificación de las máquinas es superior al mínimo de ESRI: tenemos 16 GB de RAM, Intel Xeon, Windows 7, discos de 64 bits, 2 x One 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 ofrece muchas sugerencias útiles para resolver los problemas.

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

Muy pocas celdas contiguas en un DEM detallado tendrán valores idénticos de pendiente y aspecto. Por lo tanto, si las características de entrada representan áreas contiguas de pendiente común y aspecto común, 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 celdas E10 en el DEM. Para representar cada uno de estos requiere al menos cuatro pares ordenados de números enteros de 4 bytes o coordenadas flotantes de 8 bytes, o 32-64 bytes. Es un requisito de 1.3 E12 - 2.6 E12 byte (1.3 - 2.5 TB). Ni siquiera hemos comenzado a dar cuenta de la sobrecarga del archivo (una característica se almacena como algo más que sus coordenadas), índices o los valores de los atributos, que podrían necesitar 0.6 TB (si se almacenan con doble precisión) o más (si se almacenan como texto), más almacenamiento para identificadores. Ah, sí, a ArcGIS le gusta guardar dos copias de cada intersección, duplicando así todo. Es posible que necesite 7-8 TB solo para almacenar la salida.

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

La solución es realizar operaciones de cuadrícula utilizando estructuras de datos de cuadrícula, no estructuras de datos vectoriales. Si se necesita absolutamente la salida del vector, realice la vectorización después de que se completen todas las operaciones de la cuadrícula.

Mi experiencia con el uso de herramientas divididas y reparación de geometría. Funciona para mí porque en el que trabajé estaba usando la capa vectorial que hice la conversión de ráster a vector. Traté de dividir la herramienta primero y me dio el error. Entonces, tuve que usar la geometría de reparación y depende de cuánto tiempo esté funcionando. Tuve que hacer esto dos veces porque cada vez que hiciste algún cambio o edición, aún tienes que volver a ejecutar repaire geomtry antes de hacer la división. Funcionó para mí.

Por cierto, ejecuté la geometría de reparación en ambas capas: shapefile y geodatabase de archivos. Le sugiero que ejecute la reparación de la geometría durante la noche.