Jag har en funktionsuppsättning som använder GCS_WGS_1984 som det geografiska koordinatsystemet. Den innehåller några funktionsklasser.

Denna funktionsuppsättning finns i sig själv i en filgeodatabas som innehåller några fler funktionsklasser i roten till gdb. En av dessa är en funktionsklass som kallas ”punkter” som också använder GCS_WGS_1984 som sitt koordinatsystem.

Jag tyckte att det skulle vara trivialt att använda ArcCatalog för att dra funktionsklassen från roten till gdb till funktionsdataset eftersom de har samma koordinatsystem. Tyvärr ger ArcGIS en feldialog som säger:

Failed to paste points The spatial references do not match 

Varför misslyckas detta? Om GCS för funktionsklassen och funktionsdatasetet är desamma, borde det inte bara fungera? Jag har verifierat att detta är fallet via dialogerna samt exportera PRJ-filen för både datamängden och klassen och använder en diff-verktyg för att jämföra de två. De är identiska.

Är den rumsliga referensen för en funktionsklass annorlunda än koordinatsystemet / projektionen?

Försöker du kopiera funktionsklassen till funktionsdataset genom att hålla ctrl medan du drar resultaten i ArcCatalog kraschar varje gång (skam för ESRI).

Jag antar att jag kunde prova alternativa sätt att flytta funktionsklasser. Använd CopyFeatures i datasetet. Projicera från funktionsklassen till en ny funktionsklass i funktionsdatasetet?

Kommentarer

  • Kan du lägga upp filen gdb någonstans var? Radera kanske alla eller några av funktionerna om de är stora, låter som om de skulle kunna reproduceras även med tomma funktionsglasögon.
  • Jag önskar att jag hade tid att köra ner varje liten egendom som jag stöter på med ArcGIS, ofta Jag måste bara leva med det och hitta nästa minst trevliga lösning. Jag använde Datahantering – > Kopieringsfunktion för att kopiera till en ny funktionsklass (temp namnges), borttagen gammal funktionsklass, bytt namn på ny funktionsklass för att matcha gamla. Att använda ArcGIS bör inte ’ inte kräva en examen i programvarutestning. = (
  • ” borde inte ’ t kräver en examen i programvarutestning ” , chat.stackexchange.com/transcript/message/1116371
  • det är bara namnet , de kan matcha men om de har ett annat namn slår det ut det här meddelandet, ignorera det.

Svar

samma koordinatsystem är inte alltid ett identiskt koordinatsystem. Jag har stött på situationer där vissa operationer och geoprocesseringsverktyg kommer att tro att funktionsklasser inte delar ett gemensamt koordinatsystem eftersom projektions beskrivande namn skiljer sig åt (”Yukon Albers” mot ”Albers – anpassad”) även om parametrarna är identiska, eller på grund av olika decimalpositioner (falsk norr 500000,00 vs 500000,0000).

Vad jag brukar göra säkerställer att koordinatsystem för Feature Dataset (och F.class) skapas med vår standard .prj-fil placerad överst i C:\path\to\ArcGIS\Desktop10.0\Coordinate Systems (gör CS tillgänglig med färre klick) och / eller kopiering av CS från en mall för huvudfunktionsklass som lagras någonstans alltid till hands.

Delvis som svar på detta problem, jag har också en tom funktionsdataset (D:\s.gdb\_template) som jag kanaliserar all vår data som ett första stegsfilter innan jag alls gör något annat med dem. Bland ett vanligt koordinatsystem säkerställer detta också att precision och rumslig domän etc. är identiska.

Uppdatering: Se Andys svar om att använda python, bara två rader, för att kopiera det rumsliga referenssystemet Feature Dataset från en mallfunktionsklass. Detta fungerade för mig i ArcCatalog 10.3 när den interaktiva metoden för att definiera SR genom att välja en funktionsklass för att importera en inte fungerade.

Kommentarer

  • Skulle ’ t dessa små förändringar i det vackra utskriftsnamnet eller decimalpositionerna du nämner finns i .prj-filen som ’ exporteras med alternativet Spara som ? Om så varför visar olika PRJ-filer ingenting? Jag hade undrat om små skillnader i upplösningen x, y också skulle kunna orsaka konflikten.
  • Det kan vara .prj-filen som skapats med ” Spara som ” är inte exakt samma som internt. Jag använder en funktionsdataset ” filter ” för att säkerställa gemensam rumslig upplösning etc.
  • I ’ Lägg till ytterligare en aspekt till detta: Ibland genereras datamängder från andra källor som innehåller M- och Z-värden när de inte har M eller Z.Jag ’ har upptäckt att vissa ESRI-verktyg upptäcker det tomma Z-koordinatsystemet som inte matchar, trots att X / Y-koordinatsystemen faktiskt matchar exakt.

Svar

Detta är en förklaring snarare än ett svar.

Vi (Esri) gör ganska strikta tester av koordinatsystemets namn och värden. Testet ”är lika” returnerar inte ett fel när man jämför 500000,00 och 500000,000000, men kan misslyckas om en verkligen är 500000.0 och den andra 500000.00000005. Vi arbetar med att lägga till alias för namn så att ”är lika” kommer att passera mer.

Som mindless.panda och matt wilkie nämnde kan skillnaderna vara i de andra värdena i en rumslig referens. referens inkluderar koordinatsreferenssystemet och lagrings- / bearbetningsvärden. För lagring: xy, z och måttupplösning och omfattning. För bearbetning: xy, z och måttoleransvärden. Varje skillnad i dessa kan orsaka ett inte lika stort fel.

Kommentarer

  • ditt svar är mycket uppskattat. Jag skulle verkligen vilja se felhantering, särskilt vad som rapporteras till användaren, förbättras i ArcGIS. Mer informativa fel behövs, med möjlighet att få ännu mer detaljerad information om så önskas. Återigen, tack till ESRI för att du tog dig tid att svara.
  • Jag understryker förslaget att ge mer information om felen. de senaste två veckorna har jag fått samma fel (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. ) på grund av en rad problem. Detta är ett in rasande meddelande att få eftersom jag inte kan göra annat än att försöka köra vad jag gjorde en andra gång för att se om felet upprepas, eller ge upp och använda en annan metod (eller programvara, vilket i allt högre grad är fallet).

Svar

Här är vad jag gjorde för att lösa problemet (med arcpy i ArcGIS 10.0) –

Detta förutsätter följande:

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

Du kan ändra dina sökvägar och objektnamn i koden och klistra in den i pythonfönstret i ArcCatalog.

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

Efter funktionsdataset skapas kan du dra och släppa funktionsklasserna i.

Kommentarer

  • Tack! Detta fungerade för mig idag i en situation där det interaktiva verktyget för att definiera det nya funktionsdatakoordinatsystemet genom att välja en befintlig funktionsklass inte fungerade (v10.3).

Svar

Detta problem dödade mig! Efter att ha sparat en massa funktionsklasser från en CAD-fil försökte jag ett antal gånger att definiera deras koordinatsystem och sedan organisera dem i funktionsdatauppsättningar. Jag försökte både definiera alla nödvändiga f.klasser och f.datasets från den officiella WGS_1984_UTM_42N-projektionen från ESRI, samt att ställa in projiceringen för datasetet och sedan importera den projiceringen för f.klasserna med hjälp av verktyget Definiera projektion. Antingen skulle ingen f.klasser klistra in, eller så skulle 1 och de andra inte.

Mycket tack till @Matt Wilkie i det här inlägget , verktyget Feature Class till Feature Class verkar ha löst problemet. Det importerar f.klasserna framgångsrikt till önskad dataset, även om jag ännu inte har definierat koordinatsystemet för f.klassen i fråga.

Dessutom fann jag att Feature Class till Geodatabase (multipel) skript fungerar bra för att flytta f.klasser till en f.dataset i bulk, förutom att detta måste göras från Geodatabase till en annan ( inte till en f.dataset inom samma geodatabas). Det verkar bero på att manuset inte automatiskt byter namn på f.klasserna när de kopieras (eller be operatören om ett nytt namn, som i Feature Class till Feature Class). Som påpekats av andra (samma tråd länkad ovan) är emellertid felet generiskt 999999.

Svar

I hade detta problem när man helt enkelt ville flytta en funktionsklass till en funktionsdataset i en GeoDatabase. Jag skapade min Feature Dataset och såg till att den hade samma koordinatsystem. Om och om igen fick jag ”Det gick inte att klistra in xyz De rumsliga referenserna matchar inte” Det snabbaste arbetet jag hittade var att importera identisk rumslig referens i min nyskapade dataset från funktionsklassen jag ville importera till den. I det andra steget i guiden ”Skapa ny funktionsdataset”.

Jag vet inte varför de rumsliga referenserna skiljer sig.

Kommentarer

  • Hej @Alan! Tack för att du delar med dig av din upplevelse och välkommen till vår webbplats.
  • Hej Alan, guiden för att skapa nya funktioner / klass är inte ’ t drar alltid alla lagrings- / bearbetningsvärden när ” importkoordinatsystem ” används.Vi ’ arbetar med att fixa det. Jag tror det här är vad du ’ stöter på.
  • Jag ’ m ser detta problem – även om jag skapar funktionsdataset och använder importmekanismen och väljer funktionsklassen kan jag ändå ’ t dra / kopiera funktionsklassen till det nyskapade funktionsdataset utan nämnda fel.

Svar

Jag tror att ett av meddelandena till ESRI är att tillhandahålla mer specifik parameter skillnader felsökningsinformation när detta fel inträffar. Jag har också stött på det här felet även efter att jag noggrant har kontrollerat rumsliga referenssystem och projektioner, som jag tror att de flesta GIS-användare gör.

Jag har hittat proceduren för att använda ArcToolbox Copy Features för att avhjälpa felmeddelanden som uppstår när import- eller kopieringsmekanismerna används. Här är vi beroende av proceduren för kopieringsfunktioner i verktygslådan för att korrekt lösa referens- eller projektionsskillnader innan vi introducerar funktionsklassen i funktionsdataset.

Jag har till och med försökt skapa funktionsdataset med ett projektionssystem definierat vid tidpunkt för skapande av dataset och sedan projicera funktionsklasser i funktionsdataset med ArcToolbox-projiceringsverktyget med samma projektion och ändå fick det fel som beskrivs här när jag försöker importera eller kopiera funktionsklassen till datasetet.

Dessa koordinatsystemproblem maskeras när du använder data i ArcMap. Eftersom ArcMap utför on-the-fly-projektion kan flera funktionsklasser med olika projektioner läggas till på en ArcMap-karta utan att användaren blir medveten om det. ArcMap varnar för olika koordinatsreferenssystem.

Svar

Svar

Svar

Har du försökt ta upp det till ArcMap och ställ in lagren som din GCS_WGS_1984 och exportera sedan alla dina lager till en filgeodatabas?

Om du har ett eller flera lager som är i olika projicering kan du exportera dem men ändra dataramen till GCS_WGS_1984?

Jag är inte säker för det i ArcGIS 10. Jag har inte dem ännu men använder 9.3.1.

Kommentarer

  • Kan du snälla förtydliga punkterna 1 och 2? Dessa verkar inte vara korrekta.

Lämna ett svar

Din e-postadress kommer inte publiceras. Obligatoriska fält är märkta *