<\/HEAD>
Actualmente estamos en la fase de desarrollo y prueba de la implementación de Parcel Fabric para nuestro condado, y hemos encontrado problemas EXTREMOS de rendimiento para los cuales nadie parece tener una respuesta.<\/P>
<\/P>
Como breve contexto: Ya hemos completado (hace meses) un extenso proceso de limpieza de nuestros lotes – simplificando el trabajo de líneas al eliminar vértices excesivos y planarizando la mayoría de ellos a líneas de 2 puntos (excepto por una minoría de límites de lotes que siguen características naturales como hidro, etc., que se dejaron como linestrings). Esta limpieza eliminó más de 10 millones de vértices innecesarios. Nuestros datos limpios de lotes y subdivisiones fueron luego procesados y cargados en el esquema de preparación proporcionado por ESRI (FGDB) donde se corrigieron todos los errores/problemas de topología, y finalmente se cargaron en un nuevo Fabric (FGDB). Este FGDB fuente del Fabric fue posteriormente cargado en nuestra base de datos Development SDE (ArcSDE 10.3.1 | Oracle 11.2.0.3) mediante la herramienta Copy Parcel Fabric.<\/P>
<\/P>
El primer problema de rendimiento se encontró al intentar registrar el Fabric como versionado. Debido a que el proceso de versionado ejecuta una serie de "análisis" en todos los objetos/tablas del Fabric antes del registro en sí, el proceso parece colgarse – cuando en realidad, simplemente toma mucho tiempo completarse. En nuestro caso, "mucho tiempo" significa que tanto las clases de entidad "Parcels" como "Lines" tardaron 4-5 horas cada una en completarse. Una mirada superficial a las tablas (y sus varios índices creados) reveló que la clase de entidad "Lines" sola tiene 2.9 millones de líneas/registros. Aunque algo alarmante para mí, nadie en ESRI ha sugerido que esto sea excesivo, per se.<\/P>
<\/P>
Después de finalmente registrarlo, comencé algunas pruebas rudimentarias de edición, enfocándome principalmente en flujos simples de trabajo con Parcel Fabric como una división de lote. Inmediatamente, en el punto del flujo donde se activa la herramienta Construction, el cursor/cruz muestra una latencia agotadora, convirtiéndose en un puntero con reloj de arena cuando se mueve por la ventana del mapa (como si estuviera ocurriendo una operación intensa). Si se deja quieto (deteniendo el movimiento del ratón), el cursor vuelve después de 10-15 segundos... pero volverá a convertirse en reloj de arena en cuanto intentes moverlo nuevamente. Si mueves el puntero no responsivo dentro del rango de ajuste (snapping) a una línea de construcción y esperas, se comportará como si estuviera ajustado cuando el cursor regresa. Desde este punto, si mueves LENTAMENTE el cursor a lo largo del elemento ya ajustado, permanecerá como un cursor activo. Sin embargo, si te mueves demasiado rápido o más allá de la tolerancia pegajosa del entorno snap (10 píxeles), el cursor volverá a ser un reloj de arena. Si tienes paciencia suficiente para comenzar a construir una línea durante este tiempo, el mismo comportamiento continuará mientras agregas vértices y ajustas a las líneas correspondientes. Al terminar, puedes construir las entidades construidas como normalmente harías.<\/P>
<\/P>
Después de pruebas adicionales, descubrí que si activo el entorno 'Classic Snapping' que permite controlar qué capas y tipos de entidades en tu TOC están disponibles para snapping (a diferencia del entorno predeterminado más nuevo donde todas las capas están habilitadas para snap todo el tiempo), y desactivo todas las capas para snapping, el problema de rendimiento desaparece. En este punto, el Fabric aún aplica snapping consigo mismo (lo cual es necesario), incluso cuando todas las capas están configuradas para no hacer snap. El momento en que activas la FC Lines, sin embargo, es cuando el rendimiento se detiene abruptamente.<\/P>
<\/P>
Curiosamente, este comportamiento NO ocurre en un FGDB. Esto me lleva a inferir que hay alguna interacción única entre ArcMap, SDE y la base Oracle cuando se trata del intensivo en datos FC Lines. A pesar que ESRI ha proporcionado varias formas adicionales para re-analizar directamente (vía SQL) las tablas del Fabric y regenerar índices espaciales, etc., no se ha logrado ninguna mejora ni nadie ha identificado (mediante SDE Intercept y archivos trace Oracle) algún cuello de botella aparente... Esto NO es un problema I/O ni parece ser un problema con procesamiento SQL tampoco.<\/P>
<\/P>
Vuelvo a mi preocupación sobre la gran cantidad de registros en la clase entidad Lines, pero no tengo forma de comprobar cómo/por qué/si esto es una preocupación válida. ArcMap aparentemente tiene dificultades para interactuar con los datos Lines en tiempo real, pero no hay explicación funcional que pueda ofrecer más allá de mis observaciones. Claramente, FGDB crea su propia marca de índices espaciales y similares sobre esta gran clase entidad, pero funciona sin problemas igual. En contraste, Oracle debería ser aún más robusto, esencialmente ignorando una tabla con apenas 3 millones registros – sin embargo, el rendimiento aquí es pésimo. Por lo tanto, sigo pensando que es algo que hace la aplicación y no simplemente la base datos.<\/P>
<\/P>
Si alguien tiene experiencias similares o conocimientos sobre este problema, ¡se lo agradeceríamos mucho!<\/P>
<\/P>
Gavin<\/P><\/BODY><\/HTML>
