ArcCatalog zegt dat ruimtelijke verwijzingen ' niet overeenkomen tussen feature dataset en feature class met hetzelfde coördinatensysteem?

Het hetzelfde coördinatensysteem is niet altijd een identiek coördinatensysteem. Ik ben situaties tegengekomen waarin sommige bewerkingen en geoprocessing tools denken dat feature klassen geen gemeenschappelijk coördinatensysteem delen, omdat de beschrijvende naam van de projectie verschilt (“Yukon Albers” vs “Albers – custom”) hoewel de parameters identiek zijn, of vanwege verschillende decimale posities (false northing 500000.00 vs 500000.0000).

Wat ik gewoonlijk doe is ervoor zorgen dat Feature Dataset (en F.class) coördinatensystemen worden gemaakt met ons standaard .prj-bestand bovenaan C:\path\to\ArcGIS\Desktop10.0\Coordinate Systems (maakt de CS beschikbaar met minder klikken) en / of het kopiëren van de CS van een master feature class-sjabloon die altijd ergens bij de hand is opgeslagen.

Deels in reactie hierop probleem, ik heb ook een lege feature-dataset (D:\s.gdb\_template) waar ik al onze gegevens doorheen leid als een eerste stapfilter voordat ik er iets anders mee doe. Bij een algemeen coördinatensysteem zorgt dit er ook voor dat de precisie en het ruimtelijke domein enz. Identiek zijn.

Update: Zie Andy “s antwoord over het gebruik van python, slechts 2 regels, om het ruimtelijke referentiesysteem Feature Dataset te kopiëren vanuit een template feature class. Dit werkte voor mij in ArcCatalog 10.3 wanneer de interactieve methode om de SR te definiëren door een feature class te selecteren om er een te importeren niet “werkte.

Reacties

• Zoun ‘ t deze kleine wijzigingen in de mooie afdruknaam of de decimale posities die u noemt aanwezig zijn in het .prj-bestand dat ‘ wordt geëxporteerd met de optie Opslaan als ? Zo ja, waarom laten diffing prj-bestanden niets zien? Ik had me afgevraagd of kleine verschillen in de x, y-resolutie ook het conflict zouden kunnen veroorzaken.
• Het kan het .prj-bestand zijn dat is gemaakt met ” Opslaan als ” is niet exact hetzelfde als degene die intern is opgeslagen. Ik gebruik een feature-dataset ” filter ” om een gemeenschappelijke ruimtelijke resolutie enz. Te garanderen.
• I ‘ Ik zal hier een extra facet aan toevoegen: soms worden datasets van andere bronnen gegenereerd met M- en Z-waarden terwijl ze eigenlijk geen M of Z hebben.Ik ‘ heb geconstateerd dat sommige ESRI-tools detecteren dat het lege Z-coördinatensysteem niet overeenkomt, ondanks het feit dat de X / Y-coördinatensystemen werkelijk exact overeenkomen.

Dit is eerder een uitleg dan een antwoord.

Wij (Esri) testen de namen en waarden van coördinatenreferentiesystemen behoorlijk streng. De “is gelijk” -test retourneert geen mislukking bij het vergelijken van 500000.00 en 500000.000000, maar kan mislukken als de ene echt 500000.0 is en de andere 500000.00000005. We werken aan het toevoegen van aliassen voor namen zodat ‘is gelijk’ meer doorgaat.

Zoals mindless.panda en matt wilkie al zeiden, kunnen de verschillen zitten in de andere waarden van een ruimtelijke referentie. referentie omvat het coördinatenreferentiesysteem en opslag / verwerkingswaarden. Voor opslag: xy, z en meetresolutie en extents. Voor verwerking: xy, z en meettolerantiewaarden. Elk verschil hierin kan een niet-gelijke fout veroorzaken.

Reacties

• uw reactie wordt zeer op prijs gesteld. Ik zou graag zien dat de foutafhandeling, vooral in wat aan de gebruiker wordt gerapporteerd, in ArcGIS wordt verbeterd. Meer informatieve fouten zijn nodig, met de mogelijkheid om desgewenst nog meer gedetailleerde informatie te krijgen. Nogmaals bedankt aan ESRI voor het nemen van de tijd om te reageren.
• Ik steun het voorstel om meer informatie over de fouten te geven. de afgelopen twee weken kreeg ik dezelfde fout (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. ) vanwege een reeks problemen. Dit is een in furiërend bericht om te ontvangen omdat ik niets kan doen behalve proberen wat ik deed een tweede keer om te zien of de fout zich herhaalt, of geef het op en gebruik een andere methode (of software, wat steeds vaker het geval is).

Hier is wat ik deed om het probleem op te lossen (met arcpy in ArcGIS 10.0) –

Dit veronderstelt het volgende:

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

U kunt uw paden en objectnamen in de code wijzigen en deze in het python-venster in ArcCatalog plakken.

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

Na de feature dataset is gemaakt, kunt u de functieklassen erin slepen en neerzetten.

Opmerkingen

• Bedankt! Dit werkte voor mij vandaag in een situatie waarin het gebruik van de interactieve tool om het nieuwe feature dataset coördinatensysteem te definiëren door een bestaande feature class te selecteren niet werkte (v10.3).

Dit probleem deed me kapot! Nadat ik een aantal functieklassen uit een CAD-bestand had opgeslagen, heb ik een aantal keren geprobeerd hun coördinatensystemen te definiëren en ze vervolgens te ordenen in feature-datasets. Ik heb geprobeerd om alle noodzakelijke f.classes en f.datasets te definiëren vanuit de officiële WGS_1984_UTM_42N-projectie van ESRI, en om de projectie voor de dataset in te stellen en vervolgens die projectie voor de f.classes te importeren met behulp van de Define Projection-tool. Ofwel past er geen f.classes in, of 1 wel en de anderen niet.

Veel dank aan @Matt Wilkie in dit bericht , het Feature Class to Feature Class tool lijkt het probleem te hebben opgelost. Het importeert met succes de f.classes in de gewenste dataset, zelfs als ik het coördinatensysteem voor de f.class in kwestie nog niet heb gedefinieerd.

Bovendien ontdekte ik dat de Feature Class to Geodatabase (multiple) script werkt uitstekend voor het in bulk verplaatsen van f.classes naar een f.dataset, behalve dat dit moet worden gedaan van Geodatabase naar een andere ( niet in een f.dataset binnen dezelfde geodatabase). Dit lijkt te zijn omdat het script de f.classes niet automatisch hernoemt wanneer ze worden gekopieerd (of de operator om een nieuwe naam vraagt, zoals in Feature Class naar Feature Class). Echter, zoals opgemerkt door anderen (dezelfde thread hierboven gelinkt), is de gegeven fout een generieke 999999.

I had dit probleem bij het simpelweg willen verplaatsen van een feature class naar een feature dataset in een GeoDatabase. Ik heb mijn Feature Dataset gemaakt en ervoor gezorgd dat deze hetzelfde coördinatensysteem had. Keer op keer kreeg ik de melding “Plak xyz De ruimtelijke verwijzingen komen niet overeen” Het snelste wat ik vond, was het importeren van de identieke ruimtelijke verwijzing in mijn nieuw gemaakte gegevensset vanuit de feature class die ik wilde importeren. Over de tweede stap van de wizard “Create New Feature Dataset”.

Ik weet niet waarom de ruimtelijke verwijzingen verschillen.

Opmerkingen

• Hallo, @Alan! Bedankt voor het delen van je ervaring en welkom op onze site.
• Hallo Alan, de wizard voor het maken van een nieuwe feature dataset / class is niet ‘ t haalt altijd alle opslag- / verwerkingswaarden op wanneer ” importcoördinatensysteem ” wordt gebruikt.We ‘ werken aan een oplossing. Ik denk dit is wat je ‘ tegenkomt.
• I ‘ m als ik dit probleem zie – zelfs als ik de Feature Dataset maak en het importmechanisme gebruik en de feature-klasse heb geselecteerd, kan ik nog steeds ‘ de feature-klasse slepen / kopiëren naar de nieuw gemaakte Feature Dataset zonder de bovengenoemde fout.

Ik denk dat een van de berichten aan ESRI is om een meer specifieke parameter te geven verschillen foutopsporingsinformatie wanneer deze fout optreedt. Ik ben deze fout ook tegengekomen, zelfs nadat ik zorgvuldig had gecontroleerd voor ruimtelijke referentiesystemen en projecties, zoals ik denk dat de meeste GIS-gebruikers dat doen.

Ik heb de procedure gevonden om de ArcToolbox Copy Features te gebruiken om foutmeldingen te verhelpen die optreden wanneer de import- of kopieermechanismen worden gebruikt. Hier zijn we afhankelijk van de Copy Features toolbox-procedure om de referentie- of projectieverschillen correct op te lossen voordat de feature-klasse in de feature-dataset wordt geïntroduceerd.

Ik heb zelfs geprobeerd de feature-dataset te maken met een projectiesysteem dat is gedefinieerd in de aanmaaktijd van de dataset, en vervolgens feature-klassen in de feature-dataset projecteren met behulp van de ArcToolbox-projectietool met dezelfde projectie, en toch de foutmelding ontvangen die hier wordt beschreven wanneer ik probeer de feature-klasse in de dataset te importeren of te kopiëren.

Deze problemen met het coördinatensysteem worden gemaskeerd wanneer u gegevens in ArcMap gebruikt. Omdat ArcMap on-the-fly projectie uitvoert, kunnen meerdere feature klassen, elk met verschillende projecties, aan een ArcMap map worden toegevoegd zonder dat de gebruiker het merkt. ArcMap waarschuwt voor verschillende coördinaatreferentiesystemen.