Laut ArcCatalog stimmen räumliche Referenzen ' nicht zwischen Feature-Dataset und Feature-Class mit demselben Koordinatensystem überein?

Das gleiche Koordinatensystem ist nicht immer ein identisches Koordinatensystem. Ich bin auf Situationen gestoßen, in denen einige Operationen und Geoverarbeitungswerkzeuge glauben, dass Feature-Classes kein gemeinsames Koordinatensystem haben, weil Der beschreibende Name der Projektion unterscheidet sich („Yukon Albers“ vs „Albers – custom“), obwohl die Parameter identisch sind oder aufgrund unterschiedlicher Dezimalstellen (falsche Nordrichtung 500000.00 vs 500000.0000).

Was ich normalerweise mache stellt sicher, dass Feature-Dataset- (und F.class-) Koordinatensysteme mit unserer Standard-PRJ-Datei erstellt werden, die oben auf C:\path\to\ArcGIS\Desktop10.0\Coordinate Systems (stellt die CS mit weniger Klicks zur Verfügung) und / oder Kopieren der CS aus einer Master-Feature-Class-Vorlage, die an einem Ort gespeichert ist, der immer zur Hand ist.

Teilweise als Antwort darauf Problem, ich habe auch ein leeres Feature-Dataset (D:\s.gdb\_template), durch das ich alle unsere Daten als Filter für den ersten Schritt durchführe, bevor ich überhaupt etwas anderes mit ihnen mache. Unter einem gemeinsamen Koordinatensystem stellt dies auch sicher, dass die Genauigkeit und der räumliche Bereich usw. identisch sind.

Update: Siehe Andys Antwort zur Verwendung von Python, nur 2 Zeilen, zum Kopieren des räumlichen Bezugssystems des Feature-Datasets aus einer Vorlagen-Feature-Class. Dies funktionierte für mich in ArcCatalog 10.3 Wenn die interaktive Methode zum Definieren des SR durch Auswahl einer zu importierenden Feature-Class nicht funktioniert hat.

Kommentare

• Würde nicht ‚ Diese geringfügigen Änderungen des hübschen Drucknamens oder der von Ihnen erwähnten Dezimalstellen sind in der PRJ-Datei enthalten, die ‚ mit der Option Speichern unter exportiert wurde ? Wenn ja, warum zeigen unterschiedliche PRJ-Dateien nichts an? Ich hatte mich gefragt, ob auch geringfügige Unterschiede in der x, y-Auflösung den Konflikt verursachen könnten.
• Es könnte sich um die mit “ Speichern unter erstellte PRJ-Datei handeln “ ist nicht genau das gleiche wie das intern gespeicherte. Ich verwende einen Feature-Datensatz “ Filter „, um eine gemeinsame räumliche Auflösung usw. sicherzustellen.
• I ‚ fügt dem eine zusätzliche Facette hinzu: Manchmal werden Datensätze aus anderen Quellen so generiert, dass sie M- und Z-Werte enthalten, wenn sie tatsächlich kein M oder Z haben.Ich ‚ habe festgestellt, dass einige ESRI-Tools das leere Z-Koordinatensystem als nicht übereinstimmend erkennen, obwohl die X / Y-Koordinatensysteme tatsächlich genau übereinstimmen.

Dies ist eher eine Erklärung als eine Antwort.

Wir (Esri) testen die Namen und Werte des Koordinatenreferenzsystems ziemlich streng. Der Test „ist gleich“ gibt beim Vergleich von 500000.00 und 500000.000000 keinen Fehler zurück, kann jedoch fehlschlagen, wenn einer wirklich 500000.0 und der andere 500000.00000005 ist. Wir arbeiten daran, Aliase für Namen hinzuzufügen, damit „gleich“ mehr passiert.

Wie mindless.panda und matt wilkie erwähnt haben, können die Unterschiede in den anderen Werten eines Raumbezugs liegen. Ein Raum Die Referenz enthält das Koordinatenreferenzsystem und Speicher- / Verarbeitungswerte. Für die Speicherung: xy, z und Messauflösung und -bereiche. Für die Verarbeitung: xy, z und Maßtoleranzwerte. Jeder Unterschied in diesen Werten kann einen ungleichen Fehler verursachen.

Kommentare

• Ihre Antwort wird sehr geschätzt. Ich würde wirklich gerne sehen, dass die Fehlerbehandlung, insbesondere in dem, was dem Benutzer gemeldet wird, in ArcGIS verbessert wird. Mehr Es sind informative Fehler erforderlich, mit der Option, auf Wunsch noch detailliertere Informationen zu erhalten. Nochmals vielen Dank an ESRI, dass Sie sich die Zeit genommen haben, um zu antworten.
• Ich stimme dem Vorschlag zu, weitere Informationen zu den Fehlern bereitzustellen In den letzten zwei Wochen habe ich den gleichen Fehler (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. ) aufgrund einer Reihe von Problemen erhalten. Dies ist ein Fehler Wütende Nachricht zu empfangen, da ich nichts tun kann, außer zu versuchen, das, was ich getan habe, ein zweites Mal auszuführen, um zu sehen, ob sich der Fehler wiederholt, oder aufzugeben und eine andere Methode (oder Software, die zunehmend der Fall ist) zu verwenden.

Hier ist, was ich getan habe, um das Problem zu beheben (mit arcpy in ArcGIS 10.0) –

Dies setzt Folgendes voraus:

• FGDB – C: \ gisdata \ Test.gdb
• Feature-Class – C: \ gisdata \ Test.gdb \ bldg

Sie können Ihre Pfade und Objektnamen im Code ändern und in das Python-Fenster in ArcCatalog einfügen.

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

Nach dem Feature-Dataset erstellt wird, können Sie die Feature-Classes per Drag & Drop verschieben.

Kommentare

• Vielen Dank! Dies funktionierte heute für mich in einer Situation, in der die Verwendung des interaktiven Tools zum Definieren des neuen Koordinatensystems für Feature-Datasets durch Auswahl einer vorhandenen Feature-Class nicht funktionierte (Version 10.3).

Dieses Problem hat mich umgebracht! Nachdem ich eine Reihe von Feature-Classes aus einer CAD-Datei gespeichert hatte, habe ich mehrmals versucht, ihre Koordinatensysteme zu definieren und sie dann in Feature-Datasets zu organisieren. Ich habe versucht, sowohl alle erforderlichen f.classes als auch f.datasets aus der offiziellen WGS_1984_UTM_42N-Projektion von ESRI zu definieren, die Projektion für den Datensatz festzulegen und diese Projektion für die f.classes mit dem Werkzeug Projektion definieren zu importieren. Entweder würden keine f.classes eingefügt, oder 1 würde und die anderen würden nicht einfügen.

Vielen Dank an @Matt Wilkie in in diesem Beitrag Das Tool Feature Class zu Feature Class scheint das Problem gelöst zu haben. Die f.classes werden erfolgreich in den gewünschten Datensatz importiert, auch wenn ich das Koordinatensystem für die betreffende f.class noch nicht definiert habe.

Außerdem habe ich festgestellt, dass die Feature-Class in Geodatabase (mehrere) Skript eignet sich hervorragend zum Verschieben von f.classes in ein f.dataset in großen Mengen, außer dies muss von Geodatabase in ein anderes erfolgen ( nicht in ein f.dataset innerhalb derselben Geodatabase). Dies scheint darauf zurückzuführen zu sein, dass das Skript die f.classes beim Kopieren nicht automatisch umbenennt (oder den Operator nach einem neuen Namen fragt, wie in Feature Class zu Feature Class). Wie von anderen hervorgehoben (der gleiche Thread ist oben verlinkt), handelt es sich bei dem angegebenen Fehler um einen generischen 999999.

I. hatte dieses Problem, als ich einfach eine Feature-Class in ein Feature-Dataset in einer GeoDatabase verschieben wollte. Ich habe mein Feature-Dataset erstellt und sichergestellt, dass es dasselbe Koordinatensystem hat. Immer wieder erhielt ich die Meldung „ xyz konnte nicht eingefügt werden Die räumlichen Verweise stimmen nicht überein“. Die schnellste Lösung bestand darin, den identischen räumlichen Bezug in mein neu erstelltes Dataset aus der gewünschten Feature-Class zu importieren hinein importieren. Im zweiten Schritt des Assistenten „Neuen Feature-Datensatz erstellen“.

Ich weiß nicht, warum sich die räumlichen Verweise unterscheiden.

Kommentare

• Hallo, @Alan! Vielen Dank, dass Sie uns Ihre Erfahrungen mitgeteilt haben. Willkommen auf unserer Website.
• Hallo Alan, der Assistent zum Erstellen neuer Feature-Datasets / Klassen ist nicht ‚ zieht nicht immer alle Speicher- / Verarbeitungswerte, wenn “ Importkoordinatensystem “ verwendet wird.Wir ‚ arbeiten daran, das Problem zu beheben. Ich denke, das ist es, worauf Sie ‚ stoßen.
• Ich ‚ m Dieses Problem wird angezeigt. Selbst wenn ich das Feature-Dataset erstelle und den Importmechanismus verwende und die Feature-Class auswähle, kann ich die Feature-Class ‚ nicht in das neu erstellte Feature-Dataset ziehen / kopieren ohne den oben genannten Fehler.

Ich denke, eine der Nachrichten an ESRI besteht darin, spezifischere Parameter bereitzustellen Unterschiede Debug-Informationen, wenn dieser Fehler auftritt. Dieser Fehler ist auch nach sorgfältiger Kontrolle der räumlichen Bezugssysteme und Projektionen aufgetreten, wie es meiner Meinung nach die meisten GIS-Benutzer tun.

Ich habe das Verfahren zur Verwendung der ArcToolbox-Kopierfunktionen gefunden, um Fehlermeldungen zu beheben, die auftreten, wenn Die Import- oder Kopiermechanismen werden verwendet. Hier sind wir auf die Toolbox-Prozedur „Features kopieren“ angewiesen, um die Referenz- oder Projektionsunterschiede korrekt aufzulösen, bevor die Feature-Class in das Feature-Dataset eingefügt wird.

Ich habe sogar versucht, das Feature-Dataset mit einem im System definierten Projektionssystem zu erstellen Erstellungszeit des Datasets und anschließendes Projizieren von Feature-Classes in das Feature-Dataset mithilfe des ArcToolbox-Projektionswerkzeugs mit derselben Projektion. Der hier beschriebene Fehler wurde weiterhin angezeigt, wenn ich versuche, die Feature-Class in das Dataset zu importieren oder zu kopieren.

Diese Koordinatensystemprobleme werden maskiert, wenn Sie Daten in ArcMap verwenden. Da ArcMap eine On-the-Fly-Projektion durchführt, können einer ArcMap-Karte mehrere Feature-Classes mit jeweils unterschiedlichen Projektionen hinzugefügt werden, ohne dass der Benutzer dies bemerkt. ArcMap warnt vor unterschiedlichen Koordinatenreferenzsystemen.