¿Fusionar los datos editados en la base de datos geodésicos maestra de ArcSDE?

Question

Necesito algunas sugerencias/inspiración para un problema que tenemos.

El problema:

Tenemos una base de datos GIS maestra de ArcSDE. Editaremos estos datos casi exclusivamente fuera de ArcGIS y fuera de ArcSDE. En otras palabras, haremos una exportación de alguna pequeña área y editaremos esto. Luego devolveremos estos datos a otra tabla SDE (base de datos diff). También mantendremos un atributo extra que contiene: añadir, borrar, editar.

Lo que queremos hacer ahora es escribir esta tabla de diferencias al maestro. Mi pregunta es ¿cuál es la mejor herramienta para hacer esto? ¿Usar Arcpy con el cursor, usar FME, o hay otras herramientas de Arcgis para ayudar? Estaba pensando en usar ArcPy y hacer algo como esto:

• simplemente añade todos los objetos con status add (añadir).
• buscar cada identificación con estado borrar y eliminarla
• buscar todas las identificaciones con estado editar y copiar las editadas

¿Cuál crees que sería la mejor herramienta para hacer esto?

• ¿Arco?
• FME
• SQL directo (estamos usando MS SQL)
• otros...

La base de datos principal estará en el rango de unos 500.000 objetos, por lo que el rendimiento es tal vez un problema. En este momento estamos pensando en una operación de sincronización en la que un operador inicia la sincronización y puede esperar a que termine para hacer algunas comprobaciones después de que se complete.

Preguntas adicionales: Necesitaremos sincronizar las dimensiones y las etiquetas también. El problema es que, en la base de datos de diferencias, probablemente no podamos almacenarlas como clases de características de dimensionamiento de Arcgis pero serán símbolos de líneas y puntos con los datos necesarios adjuntos. ¿Podemos usar la misma técnica para transformar y migrar estos datos para que encajen en las clases de dimensionamiento?

Answer 1

Un enfoque que he utilizado con éxito y que parece funcionar bastante bien en FME es crear tres columnas en la clase de características "maestra" en SDE:

1. Un campo que contiene el OID original de la característica (u otra identificación única).
2. (Opcional) Un campo que contiene el nombre de la clase de característica original del rasgo (se utiliza si tiene varias clases de característica de origen que van a la clase de característica maestra)
3. Una columna que contiene un CRC ( Comprobación de redundancia cíclica ) para cada característica. Este valor se genera utilizando el CRCCalculadora transformador. Vea también este Artículo de FMEpedia detallando cómo puede ser implementado.

Luego leí tanto la clase de características de la fuente como la clase de características maestra y me "uní" (usando un FeatureMerger ) en una concatenación de la identificación original y el nombre de clase de la característica de la fuente.

Ahora, dependiendo del puerto en el que la característica salga de la fusión de características, sabrás si es una adición, una eliminación o si la característica existe en ambos lugares.

Entonces sólo tienes que calcular el CRC de nuevo en la función de entrada y compararlo con el CRC almacenado. Si el CRC es diferente, es una actualización. Si es el mismo, la característica no ha cambiado.

Así sabrá si debe actualizar, eliminar, añadir o saltar cada una de las funciones. Sólo ten cuidado de enrutar los flujos correctos (entrada vs. maestro) y no mezcles los geodb_oid ya que querrás usar los OID del maestro para borrar y actualizar. Para las adiciones no importa. Fíjate en el paso AttributeRenamer en el ejemplo de FMEpedia; lo usaron para evitar que la Fusión de características sobrescriba los atributos existentes.

El ejemplo de FMEpedia envía cada tipo de transacción de base de datos (actualizar/borrar/añadir) a escritores separados, pero se puede usar un truco ingenioso para usar sólo un escritor estableciendo el fme_db_operation atribuir a ACTUALIZAR, INSERTAR o BORRAR y establecer el modo de escritura en ACTUALIZAR. Esta técnica se detalla en este Artículo de FMEpedia .

También puede, por supuesto, añadir columnas de marca de tiempo para registrar cuándo se cargó una característica por primera vez y cuándo se modificó por última vez con el TimeStamper transformador.

Nótese que este enfoque probablemente le permitiría saltarse por completo el paso de la tabla "diff", y creo que el FME también soporta muy bien las clases de características de dimensión y anotación, por lo que es de esperar que el enfoque funcione de la misma manera o que sólo necesite pequeñas modificaciones para ellas (nunca las he usado yo mismo).

Answer 2

Si tú Registering as versioned with the option to move edits to base y almacenar sus datos usando el tipo espacial de SQL Server en lugar del binario SDE, entonces podrá editar sus datos directamente usando el SQL Server y ArcGIS verá los cambios.

Luego, puede considerar el uso de técnicas de replicación de SQL Server (como la replicación de fusión) para extraer una copia de los datos a un sitio externo para su edición fuera de línea.

Answer 3

Mi pensamiento inmediato sería usar procedimientos almacenados en MS SQL para lograr esto. No tengo ninguna métrica, pero asumir será de lejos el camino más rápido ya que sería "nativo" Lo que estás pidiendo es bastante sencillo. Sólo un bucle a través de la tabla de diferencias emitiendo declaraciones de sql al maestro db.

Aunque no sé lo suficiente sobre la dimensión del FC, ¡así que no puedo ayudarte en esto! Asumiría que en este caso tendrías que usar ArcPy ya que sabrá cómo almacenar los objetos en la base de datos geológicos. A menos, por supuesto, que averigüe (ingeniería inversa) qué tablas se actualizan cuando se crea una clase de dimensionamiento.