ArcCatalog siger, at rumlige referencer ikke matcher ' mellem funktionsdatasæt og funktionsklasse med samme koordinatsystem?

Det samme koordinatsystem er ikke altid et identisk koordinatsystem. Jeg er stødt på situationer, hvor nogle operationer og geoprocesseringsværktøjer vil tro, at funktionsklasser ikke deler et fælles koordinatsystem, fordi projektions beskrivende navn adskiller sig (“Yukon Albers” vs “Albers – brugerdefineret”), selvom parametrene er identiske eller på grund af forskellige decimalpositioner (falsk nord 500.000,00 vs 500000.0000).

Hvad jeg normalt gør er sikre, at koordinatsystemer til funktionssæt (og F.class) oprettes med vores standard .prj-fil placeret øverst i C:\path\to\ArcGIS\Desktop10.0\Coordinate Systems (gør CS tilgængelig med færre klik) og / eller kopiering af CS fra en masterfunktionsklasseskabelon, der altid er gemt et sted.

Delvist som svar på dette problem, jeg har også et tomt datasæt (D:\s.gdb\_template), som jeg trækker alle vores data igennem som et første trin filter, før jeg overhovedet gør noget andet med dem. Blandt et fælles koordinatsystem sikrer dette også, at præcisionen og det geografiske domæne osv. Er identiske.

Opdatering: Se Andys svar om brug af python, kun 2 linjer, til at kopiere det geografiske referencesystem til Feature Dataset fra en skabelonfunktionsklasse. Dette fungerede for mig i ArcCatalog 10.3 når den interaktive metode til at definere SR ved at vælge en funktionsklasse til at importere en ikke fungerede.

Kommentarer

• Ville ikke ‘ t disse små ændringer i det smukke udskriftsnavn eller decimalpositioner, du nævner, er til stede i .prj-filen, som ‘ eksporteres med indstillingen Gem som ? Hvis ja, hvorfor viser forskellige PRJ-filer intet? Jeg havde spekuleret på, om små forskelle i x, y-opløsning også kunne forårsage konflikten.
• Det kan være .prj-filen oprettet med ” Gem som ” er ikke nøjagtigt den samme som internt. Jeg bruger et funktionsdatasæt ” filter ” for at sikre fælles rumlig opløsning osv.
• I ‘ tilføjer en yderligere facet til dette: Nogle gange genereres datasæt fra andre kilder, der indeholder M- og Z-værdier, når de ikke har M eller Z.Jeg ‘ har fundet ud af, at nogle ESRI-værktøjer registrerer det tomme Z-koordinatsystem som ikke matchende, på trods af at X / Y-koordinatsystemerne faktisk matcher nøjagtigt.

Dette er en forklaring snarere end et svar.

Vi (Esri) udfører ret strenge test af koordinatsystemers navne og værdier. Testen “er lige” returnerer ikke en fejl, når man sammenligner 500000,00 og 500000,000000, men kan mislykkes, hvis den ene virkelig er 500000.0 og den anden 500000.00000005. Vi arbejder på at tilføje aliasser for navne, så “er lige”, vil passere mere.

Som mindless.panda og matt wilkie nævnte, kan forskellene være i de andre værdier i en rumlig reference. reference inkluderer koordinatsystemet og værdier for lagring / behandling. Til lagring: xy, z og måleopløsning og omfang. Til behandling: xy, z og målingstoleranceværdier. Enhver forskel i disse kan forårsage en ikke lige fejl.

Kommentarer

• dit svar er meget værdsat. Jeg vil virkelig gerne se, at fejlhåndtering, især i det, der rapporteres til brugeren, forbedres i ArcGIS. Mere der er behov for informative fejl med mulighed for at få endnu mere detaljerede oplysninger, hvis det ønskes. Igen tak til ESRI for at tage sig tid til at svare.
• Jeg udstikker forslaget om at give mere information om fejlene. Over de sidste to uger har jeg fået den samme fejl (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 af en række problemer. Dette er et rasende besked for at modtage, da jeg ikke kan gøre andet end at prøve at køre, hvad jeg gjorde en anden gang for at se, om fejlen gentages, eller give op og bruge en anden metode (eller software, hvilket i stigende grad er tilfældet).

Her er hvad jeg gjorde for at løse problemet (ved hjælp af arcpy i ArcGIS 10.0) –

Dette forudsætter følgende:

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

Du kan ændre dine stier og objektnavne i koden og indsætte den i pythonvinduet i ArcCatalog.

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

Efter funktionsdatasættet er oprettet, kan du trække og slippe funktionsklasser i.

Kommentarer

• Tak! Dette fungerede for mig i dag i en situation, hvor brug af det interaktive værktøj til at definere det nye datasættets koordinatsystem ved at vælge en eksisterende funktionsklasse ikke fungerede (v10.3).

Dette problem dræbte mig! Efter at have gemt en masse funktionsklasser fra en CAD-fil forsøgte jeg et antal gange at definere deres koordinatsystemer og derefter organisere dem i funktionsdatasæt. Jeg forsøgte både at definere alle de nødvendige f.klasser og f.datasæt fra den officielle WGS_1984_UTM_42N-projektion fra ESRI, samt at indstille projiceringen for datasættet og derefter importere denne projektion til f.klasserne ved hjælp af Define Projection-værktøjet. Enten indsættes ingen f.klasser, eller 1, og de andre ikke.

Meget tak til @Matt Wilkie i dette indlæg , Feature Class til Feature Class værktøjet ser ud til at have løst problemet. Det importerer f.klasser med succes i det ønskede datasæt, selvom jeg endnu ikke har defineret koordinatsystemet for den pågældende f.klasse.

Derudover fandt jeg, at Feature Class til Geodatabase (multiple) script fungerer godt til at flytte f.klasser til en f.dataset i bulk, bortset fra at dette skal gøres fra Geodatabase til en anden ( ikke ind i et f.datasæt inden for den samme geodatabase). Dette ser ud til at være fordi scriptet ikke automatisk omdøber f.klasserne, når de kopieres (eller bede operatøren om et nyt navn, som i Feature Class til Feature Class). Som påpeget af andre (samme tråd linket ovenfor) er den givne fejl imidlertid en generisk 999999.

I havde dette problem, når de blot ville flytte en funktionsklasse til et funktionsdatasæt i en GeoDatabase. Jeg lavede mit Feature-datasæt og sørgede for, at det havde det samme koordinatsystem. Jeg modtog igen og igen “Kunne ikke indsætte xyz De geografiske referencer stemmer ikke overens”. Det hurtigste arbejde, jeg fandt ud af, var at importere den samme geografiske reference i mit nyoprettede datasæt fra den funktionsklasse, jeg ønskede at importere til det. På det andet trin i guiden “Opret nyt funktionssæt”.

Jeg ved ikke, hvorfor de geografiske referencer er forskellige.

Kommentarer

• Hej @Alan! Tak for din deling af din oplevelse og velkommen til vores site.
• Hej Alan, guiden Opret nyt funktionssæt / klasse er ikke ‘ t trækker altid alle lager- / behandlingsværdier, når ” importkoordinatsystem ” bruges.Vi ‘ arbejder på at rette det. Jeg synes det er det, du ‘ løber ind i.
• Jeg ‘ m ser dette problem – selvom jeg opretter funktionsdatasættet og bruger importmekanismen og valgte funktionsklassen, kan jeg stadig ‘ ikke trække / kopiere funktionsklassen til det nyoprettede funktionsdatasæt uden den førnævnte fejl.

Jeg tror, at en af meddelelserne til ESRI er at give en mere specifik parameter forskelle fejlretningsoplysninger, når denne fejl opstår. Jeg har også stødt på denne fejl, selv efter omhyggelig kontrol af rumlige referencesystemer og fremskrivninger, som jeg tror, de fleste GIS-brugere gør.

Jeg har fundet proceduren til at bruge ArcToolbox Copy Features til at afhjælpe fejlmeddelelser, der opstår, når import- eller kopimekanismerne bruges. Her er vi afhængige af fremgangsmåden til kopifunktioner i værktøjskassen for at løse reference- eller projektionsforskelle korrekt, før vi introducerer funktionsklassen i funktionsdatasættet.

Jeg har endda forsøgt at oprette funktionsdatasættet med et projektionssystem defineret på tid til oprettelse af datasæt og derefter projicering af funktionsklasser ind i funktionsdatasættet ved hjælp af ArcToolbox-projektionsværktøjet med den samme projektion og stadig modtaget den fejl, der er beskrevet her, når jeg prøver at importere eller kopiere funktionsklassen til datasættet.

Disse koordinatsystemproblemer bliver maskerede, når du bruger data i ArcMap. Da ArcMap udfører on-the-fly projektion, kan flere funktionsklasser hver med forskellige fremskrivninger føjes til et ArcMap-kort uden at brugeren bliver opmærksom. ArcMap vil advare om forskellige koordinatreferencesystemer.