ArcCatalog dice que las referencias espaciales ' no coinciden entre el dataset de entidades y la clase de entidad con el mismo sistema de coordenadas.

El mismo sistema de coordenadas no siempre es un sistema de coordenadas idéntico . Me he encontrado con situaciones en las que algunas operaciones y herramientas de geoprocesamiento pensarán que las clases de entidad no comparten un sistema de coordenadas común porque el nombre descriptivo de la proyección es diferente («Yukon Albers» vs «Albers – personalizado») aunque los parámetros son idénticos, o debido a posiciones decimales diferentes (falso norte 500000.00 vs 500000.0000).

Lo que suelo hacer es asegurar que los sistemas de coordenadas Feature Dataset (y F.class) se creen con nuestro archivo .prj estándar colocado en la parte superior de C:\path\to\ArcGIS\Desktop10.0\Coordinate Systems (hace que la CS esté disponible con menos clics) y / o copiando la CS de una plantilla de clase de entidad maestra almacenada en algún lugar siempre a mano.

En parte como respuesta a esto problema, también tengo un conjunto de datos de características vacío (D:\s.gdb\_template) a través del cual canalizo todos nuestros datos como un filtro de primer paso antes de hacer cualquier otra cosa con ellos. Entre un sistema de coordenadas común, esto también garantiza que la precisión y el dominio espacial, etc. sean idénticos.

Actualización: Consulte la respuesta de Andy sobre el uso de Python, solo 2 líneas, para copiar el sistema de referencia espacial del dataset de entidades de una clase de entidad de plantilla. Esto funcionó para mí en ArcCatalog 10.3 cuando el método interactivo de definir el SR mediante la selección de una clase de entidad para importar uno no funcionó.

Comentarios

• No ‘ t estos pequeños cambios en el bonito nombre de letra impresa o las posiciones decimales que mencionas estarán presentes en el archivo .prj que ‘ s exportó con la opción Guardar como ? Si es así, ¿por qué los archivos prj diferentes no muestran nada? Me preguntaba si pequeñas diferencias en la resolución x, y podrían estar causando el conflicto también.
• Podría ser el archivo .prj creado con » Guardar como » no es exactamente el mismo que el almacenado internamente. Utilizo un conjunto de datos de características » filter » para garantizar una resolución espacial común, etc.
• I ‘ agregaré una faceta adicional a esto: a veces, los conjuntos de datos de otras fuentes se generarán como que contienen valores M y Z cuando en realidad no tienen M o Z.’ he descubierto que algunas herramientas de ESRI detectan que el sistema de coordenadas Z vacío no coincide, a pesar de que los sistemas de coordenadas X / Y realmente coinciden exactamente.

Esta es una explicación más que una respuesta.

Nosotros (Esri) realizamos pruebas bastante estrictas de los nombres y valores del sistema de referencia de coordenadas. La prueba «es igual» no devolverá un error al comparar 500000.00 y 500000.000000, pero podría fallar si una es realmente 500000.0 y la otra 500000.00000005. Estamos trabajando en agregar alias para los nombres para que «es igual» pase más.

Como mencionaron mindless.panda y matt wilkie, las diferencias podrían estar en los otros valores de una referencia espacial. La referencia incluye el sistema de referencia de coordenadas y los valores de almacenamiento / procesamiento. Para el almacenamiento: xy, z, y resolución y extensión de la medida. Para el procesamiento: xy, z, y valores de tolerancia de medición. Cualquier diferencia en estos puede causar un error no igual.

Comentarios

• Su respuesta es muy apreciada. Realmente me gustaría ver que el manejo de errores, particularmente en lo que se informa al usuario, mejore en ArcGIS. Más Se necesitan errores informativos, con la opción de obtener información aún más detallada si lo desea. Nuevamente, gracias a ESRI por tomarse el tiempo para responder.
• Apoyo la propuesta para brindar más información sobre los errores. las últimas dos semanas he tenido el mismo error (Error code: 999999: Error executing function. Description: This is a generic error for which the cause of the error does not have an appropriate error ID. ) debido a una serie de problemas. Este es un furioso mensaje para recibir ya que no puedo hacer nada excepto intentar ejecutar lo que hice una segunda vez para ver si el error se repite, o renunciar y usar otro método (o software, que es cada vez más el caso).

Esto es lo que hice para resolver el problema (usando arcpy en ArcGIS 10.0) –

Esto supone lo siguiente:

• FGDB – C: \ gisdata \ Test.gdb
• Clase de función – C: \ gisdata \ Test.gdb \ bldg

Puede modificar sus rutas y nombres de objeto en el código y pegarlo en la ventana de Python en ArcCatalog.

sr = arcpy.Describe(r"C:\gisdata\Test.gdb\bldg").spatialReference arcpy.CreateFeatureDataset_management(r"C:\gisdata\Test.gdb", "MyFeatureDataset", sr) 

Después del dataset de entidades Cuando se crea, puede arrastrar y soltar las clases de entidad.

Comentarios

• ¡Gracias! Esto funcionó para mí hoy en una situación en la que usar la herramienta interactiva para definir el nuevo sistema de coordenadas del dataset de entidades mediante la selección de una clase de entidad existente no funcionó (v10.3).

¡Este problema me estaba matando! Después de guardar un montón de clases de entidades de un archivo CAD, intenté varias veces definir sus sistemas de coordenadas y luego organizarlos en conjuntos de datos de entidades. Intenté definir todas las f.classes y f.datasets necesarios de la proyección oficial WGS_1984_UTM_42N de ESRI, así como configurar la proyección para el conjunto de datos y luego importar esa proyección para las f.classes usando la herramienta Definir proyección. O no se pegaría ninguna f.classes, o 1 lo haría y las otras no.

Muchas gracias a @Matt Wilkie en esta publicación , la herramienta de clase de entidad a clase de entidad parece haber resuelto el problema. Importa con éxito las f.classes en el conjunto de datos deseado, incluso si aún no he definido el sistema de coordenadas para la f.class en cuestión.

Además, encontré que el Clase de entidad a geodatabase (múltiple) La secuencia de comandos funciona muy bien para mover f.classes a un f.dataset de forma masiva, excepto que esto debe hacerse desde una geodatabase a otra ( no en un f. dataset dentro de la misma geodatabase). Esto parece deberse a que el script no cambia automáticamente el nombre de las f.classes cuando se copian (o pide al operador un nuevo nombre, como en Feature Class a Feature Class). Sin embargo, como lo señalaron otros (el mismo hilo vinculado arriba), el error dado es un 999999 genérico.

I tenía este problema cuando simplemente deseaba mover una clase de entidad a un dataset de entidades en una GeoDatabase. Hice mi Feature Dataset y me aseguré de que tuviera el mismo sistema de coordenadas. Una y otra vez recibí «No se pudo pegar xyz Las referencias espaciales no coinciden» El trabajo más rápido que encontré fue importar la referencia espacial idéntica en mi conjunto de datos recién creado de la clase de entidad que quería importar en él. En el segundo paso del asistente «Crear nuevo conjunto de datos de entidades».

No sé por qué difieren las referencias espaciales.

Comentarios

• ¡Hola, @Alan! Gracias por compartir tu experiencia y bienvenido a nuestro sitio.
• Hola, Alan, el asistente para crear un nuevo conjunto de datos de entidades / clase no es ‘ t siempre extrae todos los valores de almacenamiento / procesamiento cuando se usa » sistema de coordenadas de importación «.Estamos ‘ trabajando para solucionarlo. Creo esto es lo que ‘ te estás encontrando.
• Yo ‘ m Al ver este problema, incluso si creo el Conjunto de datos de entidades y uso el mecanismo de importación y selecciono la clase de entidad, todavía puedo ‘ t arrastrar / copiar la clase de entidad al conjunto de datos de entidades recién creado sin el error mencionado anteriormente.

Creo que uno de los mensajes a ESRI es proporcionar un parámetro más específico diferencias de información de depuración cuando se produce este error. Yo también encontré este error incluso después de controlar cuidadosamente los sistemas de referencia espacial y las proyecciones, como creo que hacen la mayoría de los usuarios de SIG.

He encontrado el procedimiento de usar las funciones de copia de ArcToolbox para solucionar los mensajes de error que ocurren cuando se utilizan los mecanismos de importación o copia. Aquí dependemos del procedimiento de la caja de herramientas Copiar entidades para resolver correctamente las diferencias de referencia o proyección antes de introducir la clase de entidad en el conjunto de datos de entidades.

Incluso he intentado crear el conjunto de datos de entidades con un sistema de proyección definido en el tiempo de creación del conjunto de datos, y luego proyectar clases de entidad en el dataset de entidad usando la herramienta de proyección ArcToolbox con la misma proyección, y aún recibí el error descrito aquí cuando intento importar o copiar la clase de entidad en el conjunto de datos.

Estos problemas del sistema de coordenadas se enmascaran cuando usa datos en ArcMap. Dado que ArcMap realiza una proyección sobre la marcha, se pueden agregar varias clases de entidades, cada una con diferentes proyecciones, a un mapa de ArcMap sin que el usuario se dé cuenta. ArcMap advertirá sobre diferentes sistemas de referencia de coordenadas.