ArcCatalog indique que les références spatiales ne correspondent pas ' entre le jeu de données dentité et la classe dentités avec le même système de coordonnées?

Le même système de coordonnées nest pas toujours un système de coordonnées identique . Jai rencontré des situations où certaines opérations et certains outils de géotraitement penseront que les classes dentités ne partagent pas un système de coordonnées commun car le nom descriptif de la projection diffère (« Yukon Albers » vs « Albers – personnalisé ») bien que les paramètres soient identiques, ou en raison de positions décimales différentes (faux nord 500000,00 vs 500000,0000).

Ce que je fais habituellement est de sassurer que les systèmes de coordonnées du jeu de données dentités (et de la classe F.) sont créés avec notre fichier standard .prj placé en haut de C:\path\to\ArcGIS\Desktop10.0\Coordinate Systems (rend le CS disponible en moins de clics) et / ou copie du CS à partir dun modèle de classe dentités principale stocké quelque part toujours à portée de main.

En partie en réponse à cela problème, jai également un ensemble de données dentités vide (D:\s.gdb\_template) dans lequel je canalisent toutes nos données comme filtre de première étape avant de faire quoi que ce soit dautre avec eux. Parmi un système de coordonnées commun, cela garantit également que la précision et le domaine spatial, etc. sont identiques.

Mise à jour: Consultez la réponse dAndy sur lutilisation de python, seulement 2 lignes, pour copier le système de référence spatiale du jeu de données dentités à partir dune classe dentités modèle. Cela a fonctionné pour moi dans ArcCatalog 10.3 lorsque la méthode interactive de définition du SR en sélectionnant une classe dentités pour en importer une na pas fonctionné.

Commentaires

• Naurait pas ‘ t ces légères modifications du joli nom en caractères dimprimerie ou des positions décimales que vous mentionnez soient présentes dans le fichier .prj que ‘ est exporté avec loption Enregistrer sous ? Si oui, pourquoi les fichiers prj différents ne montrent-ils rien? Je métais demandé si de légères différences dans la résolution x, y pouvaient également être à lorigine du conflit.
• Ce pourrait être le fichier .prj créé avec  » Enregistrer sous  » nest pas exactement le même que celui stocké en interne. Jutilise un ensemble de données dentités  » filter  » pour assurer une résolution spatiale commune, etc.
• I ‘ Je vais ajouter une facette supplémentaire à ceci: Parfois, des ensembles de données dautres sources seront générés comme contenant des valeurs M et Z alors quils nont pas réellement M ou Z.Jai ‘ trouvé que certains outils ESRI détectent que le système de coordonnées Z vide ne correspond pas, malgré le fait que les systèmes de coordonnées X / Y correspondent exactement.

Ceci est une explication plutôt quune réponse.

Nous (Esri) faisons des tests assez stricts des noms et des valeurs des systèmes de référence de coordonnées. Le test « est égal » ne renverra pas déchec lors de la comparaison de 500000.00 et 500000.000000, mais peut échouer si lun est vraiment 500000.0 et lautre 500000.00000005. Nous « travaillons actuellement sur lajout dalias pour les noms afin que » est égal « passe plus.

Comme mindless.panda et matt wilkie lont mentionné, les différences peuvent provenir des autres valeurs dune référence spatiale. référence inclut le système de référence de coordonnées et les valeurs de stockage / traitement. Pour le stockage: xy, z et la résolution et létendue des mesures. Pour le traitement: xy, z et les valeurs de tolérance de mesure. Toute différence entre ces valeurs peut entraîner une erreur différente.

Commentaires

• votre réponse est très appréciée. Jaimerais vraiment que la gestion des erreurs, en particulier dans ce qui est signalé à lutilisateur, saméliore dans ArcGIS. En savoir plus des erreurs informatives sont nécessaires, avec la possibilité dobtenir des informations encore plus détaillées si vous le souhaitez. Encore une fois, merci à ESRI davoir pris le temps de répondre.
• Jappuie la proposition pour fournir plus dinformations sur les erreurs. au cours des deux dernières semaines, jai eu la même erreur (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. ) en raison dune série de problèmes. message furieux à recevoir car je ne peux rien faire sauf essayer dexécuter ce que jai fait une deuxième fois pour voir si lerreur se répète, ou abandonner et utiliser une autre méthode (ou un logiciel, ce qui est de plus en plus le cas).

Voici ce que jai fait pour résoudre le problème (en utilisant arcpy dans ArcGIS 10.0) –

Cela suppose ce qui suit:

• FGDB – C: \ gisdata \ Test.gdb
• Classe dobjets – C: \ gisdata \ Test.gdb \ bldg

Vous pouvez modifier vos chemins et noms dobjets dans le code et les coller dans la fenêtre Python dArcCatalog.

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

Après le jeu de données dentité est créé, vous pouvez faire glisser et déposer les classes dentités.

Commentaires

• Merci! Cela a fonctionné pour moi aujourdhui dans une situation où lutilisation de loutil interactif pour définir le nouveau système de coordonnées du jeu de données dentité en sélectionnant une classe dentités existante ne fonctionnait pas (v10.3).

Ce problème me tuait! Après avoir enregistré un tas de classes dentités à partir dun fichier CAO, jai essayé plusieurs fois de définir leurs systèmes de coordonnées, puis de les organiser en jeux de données dentités. Jai essayé à la fois de définir toutes les f.classes et f.datasets nécessaires à partir de la projection officielle WGS_1984_UTM_42N dESRI, ainsi que de définir la projection pour lensemble de données, puis dimporter cette projection pour les f.classes à laide de loutil Define Projection. Soit aucune f.classe ne serait collée, soit 1 le ferait et les autres ne le feraient pas.

Merci beaucoup à @Matt Wilkie dans ce message , loutil Classe dobjets en classe dobjets semble avoir résolu le problème. Il importe avec succès les f.classes dans lensemble de données souhaité, même si je nai pas encore défini le système de coordonnées pour la f.class en question.

De plus, jai trouvé que le Classe dentités vers géodatabase (multiple) fonctionne très bien pour déplacer des f.classes dans un f.dataset en bloc, sauf que cela doit être fait de la géodatabase à une autre ( pas dans un f.dataset dans la même géodatabase). Cela semble être dû au fait que le script ne renomme pas automatiquement les f.classes lorsquelles sont copiées (ou demande à lopérateur un nouveau nom, comme dans Classe dobjets en classe dobjets). Cependant, comme indiqué par dautres (même fil de discussion lié ci-dessus), lerreur donnée est un 999999 générique.

I eu ce problème lorsque vous vouliez simplement déplacer une classe dentités dans un jeu de données dentités dans une GeoDatabase. Jai créé mon ensemble de données dentités et je me suis assuré quil avait le même système de coordonnées. Jai reçu à maintes reprises « Impossible de coller xyz Les références spatiales ne correspondent pas » La solution la plus rapide que jai trouvée a été dimporter la référence spatiale identique dans mon jeu de données nouvellement créé à partir de la classe dentités que je voulais importer dedans. Lors de la deuxième étape de lassistant « Créer un nouvel ensemble de données dentités ».

Je ne sais pas pourquoi les références spatiales diffèrent.

Commentaires

• Salut, @Alan! Merci de partager votre expérience et bienvenue sur notre site.
• Bonjour Alan, lassistant de création dun nouvel ensemble de données dentités / classe nest pas ‘ t extrait toujours toutes les valeurs de stockage / traitement lorsque le  » système de coordonnées dimportation  » est utilisé.Nous ‘ travaillons actuellement à le corriger. Je pense que cest ce que vous ‘ rencontrez.
• Je ‘ m voyant ce problème – même si je crée le jeu de données dentités et utilise le mécanisme dimportation et sélectionné la classe dentités, je peux toujours ‘ faire glisser / copier la classe dentités dans le jeu de données dentités nouvellement créé sans lerreur susmentionnée.

Je pense que lun des messages à ESRI est de fournir un paramètre plus spécifique différences dinformations de débogage lorsque cette erreur se produit. Jai moi aussi rencontré cette erreur même après avoir soigneusement contrôlé les systèmes de référence spatiale et les projections, comme je pense que la plupart des utilisateurs de SIG le font.

Jai trouvé la procédure dutilisation des fonctionnalités de copie dArcToolbox pour remédier aux messages derreur qui se produisent lorsque les mécanismes dimportation ou de copie sont utilisés. Ici, nous dépendons de la procédure de la boîte à outils Copier les entités pour résoudre correctement les différences de référence ou de projection avant dintroduire la classe dentités dans le jeu de données dentités.

Jai même essayé de créer le jeu de données dentités avec un système de projection défini au niveau du heure de création du jeu de données, puis projection des classes dentités dans le jeu de données dentité à laide de loutil de projection ArcToolbox avec la même projection, et jai quand même reçu lerreur décrite ici lorsque jessaye dimporter ou de copier la classe dentités dans le jeu de données.

Ces problèmes de système de coordonnées sont masqués lorsque vous utilisez des données dans ArcMap. Étant donné quArcMap effectue une projection à la volée, plusieurs classes dentités, chacune avec des projections différentes, peuvent être ajoutées à une carte ArcMap sans que lutilisateur ne sen rende compte. ArcMap avertira des différents systèmes de référence de coordonnées.