ArcCatalog sier at romlige referanser ikke samsvarer ' t mellom funksjonsdatasett og funksjonsklasse med samme koordinatsystem?

Det samme koordinatsystemet er ikke alltid et identisk koordinatsystem. Jeg har opplevd situasjoner der noen operasjoner og geoprosesseringsverktøy vil tro at funksjonsklasser ikke deler et felles koordinatsystem fordi det beskrivende navnet på projeksjonen er forskjellig («Yukon Albers» vs «Albers – custom») selv om parameterne er identiske, eller på grunn av forskjellige desimalposisjoner (falsk nording 500000,00 vs 500000,0000).

Hva jeg vanligvis gjør sørger for at koordinatsystemer for funksjonsdatasett (og F.class) opprettes med vår standard .prj-fil plassert øverst i C:\path\to\ArcGIS\Desktop10.0\Coordinate Systems (gjør CS tilgjengelig med færre klikk) og / eller kopiering av CS fra en mal for hovedfunksjonsklassen som er lagret et sted som alltid er tilgjengelig.

Delvis som svar på dette problemet har jeg også et tomt funksjonsdatasett (D:\s.gdb\_template) som jeg trakterer alle dataene våre som et første trinns filter før jeg gjør noe annet i det hele tatt med dem. Blant et vanlig koordinatsystem sikrer dette også at presisjonen og det romlige domenet osv. Er identiske.

Oppdatering: Se Andys svar om å bruke python, bare to linjer, for å kopiere det romlige referansesystemet Feature Dataset fra en malfunksjonsklasse. Dette fungerte for meg i ArcCatalog 10.3 da den interaktive metoden for å definere SR ved å velge en funksjonsklasse for å importere en ikke fungerte.

Kommentarer

• Ville ikke ‘ t disse små endringene i det vakre utskriftsnavnet eller desimalposisjonene du nevner, finnes i .prj-filen som ‘ eksporteres med alternativet Lagre som ? I så fall hvorfor viser diffing PRJ-filer ingenting? Jeg hadde lurt på om små forskjeller i x, y-oppløsningen også kunne forårsake konflikten.
• Det kan være .prj-filen opprettet med » Lagre som » er ikke akkurat den samme som den som er lagret internt. Jeg bruker et funksjonsdatasett » filter » for å sikre felles romlig oppløsning osv.
• I ‘ Legg til en ekstra fasett til dette: Noen ganger vil datasett fra andre kilder bli generert som inneholder M- og Z-verdier når de faktisk ikke har M eller Z.Jeg ‘ har funnet ut at noen ESRI-verktøy oppdager det tomme Z-koordinatsystemet som ikke samsvarer, til tross for at X / Y-koordinatsystemene faktisk stemmer overens.

Dette er en forklaring snarere enn et svar.

Vi (Esri) gjør ganske strenge tester av navn og verdier for koordinatsystemer. Testen «er lik» gir ikke feil når man sammenligner 500000,00 og 500000,000000, men kan mislykkes hvis den ene er 500000.0 og den andre 500000.00000005. Vi jobber med å legge til aliaser for navn slik at «er lik» vil passere mer.

Som mindless.panda og matt wilkie nevnte, kan forskjellene være i de andre verdiene til en romlig referanse. referanse inkluderer koordinats referansesystem og lagrings- / prosesseringsverdier. For lagring: xy, z, og måleoppløsning og omfang. For behandling: xy, z og toleranseverdier. Enhver forskjell i disse kan forårsake en ikke like feil.

Kommentarer

• svaret ditt er mye verdsatt. Jeg vil virkelig se feilhåndtering, spesielt i det som rapporteres til brukeren, forbedres i ArcGIS. Mer informative feil er nødvendig, med muligheten til å få enda mer detaljert informasjon om ønskelig. Igjen, takk til ESRI for at du tok deg tid til å svare.
• Jeg utstikker forslaget om å gi mer informasjon om feilene. de siste to ukene har jeg fått den samme feilen (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å grunn av en rekke problemer. Dette er en furiating melding å motta som jeg ikke kan gjøre noe annet enn å prøve å kjøre det jeg gjorde en gang til for å se om feilen blir gjentatt, eller gi opp og bruke en annen metode (eller programvare, noe som i økende grad er tilfelle).

Her er hva jeg gjorde for å løse problemet (ved hjelp av arcpy i ArcGIS 10.0) –

Dette forutsetter følgende:

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

Du kan endre banene og objektenavnene dine i koden og lime den inn i pythonvinduet i ArcCatalog.

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

Etter funksjonsdatasettet er opprettet kan du dra og slippe funksjonsklassene i.

Kommentarer

• Takk! Dette fungerte for meg i dag i en situasjon der bruk av det interaktive verktøyet til å definere det nye funksjonsdatakoordinatsystemet ved å velge en eksisterende funksjonsklasse ikke fungerte (v10.3).

Dette problemet drepte meg! Etter å ha lagret en rekke funksjonsklasser fra en CAD-fil, prøvde jeg flere ganger å definere koordinatsystemene deres og deretter organisere dem i funksjonsdatasett. Jeg prøvde både å definere alle nødvendige f.klasser og f.datasett fra den offisielle WGS_1984_UTM_42N projeksjonen fra ESRI, samt å sette projeksjonen for datasettet og deretter importere projeksjonen for f.klassene ved hjelp av Define Projection-verktøyet. Enten ville ingen f.klasser lime inn, eller 1, og de andre ikke.

Mye takk til @Matt Wilkie i dette innlegget , Feature Class to Feature Class verktøyet ser ut til å ha løst problemet. Det importerte f.klassene med hell i ønsket datasett, selv om jeg ennå ikke har definert koordinatsystemet for den aktuelle f.klassen.

I tillegg fant jeg at Feature Class til Geodatabase (multiple) script fungerer utmerket for å flytte f.klasser til en f.datasett i bulk, bortsett fra at dette må gjøres fra Geodatabase til en annen ( ikke inn i et f.datasett innenfor samme geodatabase). Dette ser ut til å være fordi skriptet ikke automatisk omdøper f.klassene når de kopieres (eller spør operatøren om et nytt navn, som i Feature Class til Feature Class). Som påpekt av andre (samme tråd lenket ovenfor), er feilen gitt en generisk 999999.

I hadde dette problemet når du bare ønsket å flytte en funksjonsklasse til et funksjonsdatasett i en GeoDatabase. Jeg laget mitt Feature-datasett og sørget for at det hadde samme koordinatsystem. Om og om igjen fikk jeg «Kunne ikke lime xyz De romlige referansene stemmer ikke overens». Det raskeste arbeidet jeg fant var å importere den identiske romlige referansen i det nyopprettede datasettet mitt fra funksjonsklassen jeg ønsket å importere til den. På det andre trinnet i veiviseren «Create New Feature Dataset».

Jeg vet ikke hvorfor de romlige referansene er forskjellige.

Kommentarer

• Hei, @Alan! Takk for at du delte opplevelsen din og velkommen til nettstedet vårt.
• Hei Alan, den nye funksjonen datasett / klasse veiviseren er ikke ‘ t trekker alltid alle lagrings / prosesseringsverdiene når » importkoordinatsystem » brukes.Vi ‘ jobber med å fikse det. Jeg tror dette er det du ‘ kjører på.
• Jeg ‘ m ser dette problemet – selv om jeg oppretter funksjonsdatasettet og bruker importmekanismen og valgte funksjonsklassen, kan jeg fortsatt ‘ t dra / kopiere funksjonsklassen til det nyopprettede funksjonsdatasettet uten den ovennevnte feilen.

Jeg tror en av meldingene til ESRI er å gi mer spesifikk parameter forskjeller feilsøkingsinformasjon når denne feilen oppstår. Jeg har også opplevd denne feilen selv etter nøye kontroll av romlige referansesystemer og projeksjoner, slik jeg tror de fleste GIS-brukere gjør.

Jeg har funnet fremgangsmåten for å bruke ArcToolbox Copy Features for å avhjelpe feilmeldinger som oppstår når import- eller kopimekanismene brukes. Her er vi avhengig av fremgangsmåten for kopifunksjoner for å løse referanse- eller projeksjonsforskjellene riktig før vi introduserer funksjonsklassen i funksjonsdatasettet.

Jeg har til og med prøvd å lage funksjonsdatasettet med et projeksjonssystem definert på tid for opprettelse av datasett, og deretter projisere funksjonsklasser inn i funksjonsdatasettet ved hjelp av ArcToolbox-projeksjonsverktøyet med samme projeksjon, og fremdeles mottok feilen som er beskrevet her når jeg prøver å importere eller kopiere funksjonsklassen til datasettet. > Disse koordinatsystemproblemene blir maskert når du bruker data i ArcMap. Siden ArcMap utfører on-the-fly projeksjon, kan flere funksjonsklasser hver med forskjellige anslag legges til et ArcMap-kart uten at brukeren blir klar over det. ArcMap vil advare om forskjellige koordinatreferansesystemer.