ArcCatalog dice che i riferimenti spaziali non ' corrispondono tra il set di dati delle caratteristiche e la classe delle caratteristiche con lo stesso sistema di coordinate?

Lo stesso sistema di coordinate non è sempre un identico sistema di coordinate. Ho riscontrato situazioni in cui alcune operazioni e strumenti di geoprocessing penseranno che le feature class non condividano un sistema di coordinate comune perché il nome descrittivo della proiezione è diverso (“Yukon Albers” vs “Albers – custom”) sebbene i parametri siano identici, oa causa delle diverse posizioni decimali (falso nord 500000.00 vs 500000.0000).

Cosa faccio di solito è garantire che i sistemi di coordinate del Feature Dataset (e F.class) siano creati con il nostro file .prj standard posizionato allinizio di C:\path\to\ArcGIS\Desktop10.0\Coordinate Systems (rende disponibile il CS con meno clic) e / o copia il CS da un modello di feature class principale memorizzato da qualche parte sempre a portata di mano.

In parte in risposta a questo problema, ho anche un set di dati di funzionalità vuoto (D:\s.gdb\_template) in cui incanalo tutti i nostri dati come filtro di primo passaggio prima di fare qualsiasi altra cosa con loro. In un sistema di coordinate comune, ciò garantisce anche che la precisione e il dominio spaziale ecc. Siano identici.

Aggiornamento: Vedere la risposta di Andy sulluso di python, solo 2 righe, per copiare il sistema di riferimento spaziale Feature Dataset da una classe di caratteristiche del modello. Questo ha funzionato per me in ArcCatalog 10.3 quando il metodo interattivo per definire la SR selezionando una feature class per importarne una non ha funzionato.

Commenti

• Non ‘ t questi piccoli cambiamenti nel bel nome in stampatello o nelle posizioni decimali menzionate siano presenti nel file .prj che ‘ viene esportato con lopzione Salva con nome ? In tal caso, perché i file prj diversi non mostrano nulla? Mi ero chiesto se anche lievi differenze nella risoluzione x, y potessero causare il conflitto.
• Potrebbe essere il file .prj creato con ” Salva con nome ” non è esattamente uguale a quello memorizzato internamente. Utilizzo un set di dati della funzione ” filtro ” per garantire una risoluzione spaziale comune e così via
• I ‘ aggiungerò un ulteriore aspetto a questo: a volte i set di dati da altre fonti verranno generati come contenenti valori M e Z quando in realtà non hanno M o Z.’ ho scoperto che alcuni strumenti ESRI rilevano che il sistema di coordinate Z vuoto non corrisponde, nonostante il fatto che i sistemi di coordinate X / Y effettivamente corrispondano esattamente.

Questa è una spiegazione piuttosto che una risposta.

Noi (Esri) eseguiamo test piuttosto rigorosi dei nomi e dei valori del sistema di riferimento delle coordinate. Il test “è uguale” non restituirà un errore quando si confrontano 500000.00 e 500000.000000, ma potrebbe non riuscire se uno è realmente 500000.0 e laltro 500000.00000005. Stiamo lavorando per aggiungere alias per i nomi in modo che “è uguale” ne passi di più.

Come hanno menzionato mindless.panda e matt wilkie, le differenze potrebbero essere negli altri valori di un riferimento spaziale. riferimento include il sistema di riferimento delle coordinate e i valori di memorizzazione / elaborazione. Per la memorizzazione: xy, ze la risoluzione e le estensioni della misura. Per lelaborazione: xy, ze i valori di tolleranza della misura. Qualsiasi differenza tra questi può causare un errore diverso.

Commenti

• la tua risposta è molto apprezzata. Mi piacerebbe davvero vedere la gestione degli errori, in particolare in ciò che viene segnalato allutente, migliorare in ArcGIS. sono necessari errori informativi, con la possibilità di ottenere informazioni ancora più dettagliate se lo si desidera. Ancora una volta, grazie a ESRI per aver dedicato del tempo a rispondere.
• Appoggio la proposta per fornire maggiori informazioni sugli errori. nelle ultime due settimane ho ricevuto lo stesso errore (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. ) a causa di una serie di problemi. Questo è un messaggio furioso da ricevere poiché non posso fare nulla se non provare a eseguire quello che ho fatto una seconda volta per vedere se lerrore si ripete, o rinunciare e utilizzare un altro metodo (o software, che è sempre più il caso).

Ecco cosa ho fatto per risolvere il problema (utilizzando arcpy in ArcGIS 10.0) –

Ciò presuppone quanto segue:

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

È possibile modificare i percorsi e i nomi degli oggetti nel codice e incollarli nella finestra python in ArcCatalog.

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

Dopo il set di dati della caratteristica è stato creato in cui puoi trascinare e rilasciare le classi di entità geografiche.

Commenti

• Grazie! Questo ha funzionato per me oggi in una situazione in cui lutilizzo dello strumento interattivo per definire il nuovo sistema di coordinate del set di dati dellentità geografica selezionando una classe di entità geografiche esistente non funzionava (v10.3).

Questo problema mi stava uccidendo! Dopo aver salvato un gruppo di classi di entità geografiche da un file CAD, ho provato diverse volte a definire i loro sistemi di coordinate, quindi a organizzarle in set di dati delle caratteristiche. Ho provato sia a definire tutte le f.class e f.dataset necessarie dalla proiezione ufficiale WGS_1984_UTM_42N di ESRI, sia a impostare la proiezione per il set di dati, quindi a importare quella proiezione per le f.classes utilizzando lo strumento Define Projection. O nessuna f.class si incollava, oppure una sì e le altre no.

Mille grazie a @Matt Wilkie in questo post , lo strumento da classe di feature a feature class sembra aver risolto il problema. Importa correttamente le f.classes nel set di dati desiderato, anche se non ho ancora definito il sistema di coordinate per la f.class in questione.

Inoltre, ho scoperto che Feature Class to Geodatabase (multiple) script funziona alla grande per spostare f.class in un f.dataset in blocco, tranne per il fatto che questo deve essere fatto da Geodatabase a un altro ( non in un f.dataset allinterno dello stesso geodatabase). Ciò sembra essere dovuto al fatto che lo script non rinomina automaticamente le f.class quando vengono copiate (o chiede alloperatore un nuovo nome, come da Feature Class a Feature Class). Tuttavia, come sottolineato da altri (stesso thread collegato sopra), lerrore fornito è un generico 999999.

I ha avuto questo problema quando si desiderava semplicemente spostare una feature class in un feature dataset in un GeoDatabase. Ho creato il mio Feature Dataset e mi sono assicurato che avesse lo stesso sistema di coordinate. Ho ricevuto ripetutamente “Impossibile incollare xyz I riferimenti spaziali non corrispondono” Il lavoro più veloce che ho trovato è stato importare lo stesso riferimento spaziale nel mio set di dati appena creato dalla feature class che volevo importare in esso. Nel secondo passaggio della procedura guidata “Crea nuovo set di dati di funzionalità”.

Non so perché i riferimenti spaziali differiscono.

Commenti

• Ciao, @Alan! Grazie per aver condiviso la tua esperienza e benvenuto nel nostro sito.
• Ciao Alan, la procedura guidata per la creazione di un nuovo set di dati di funzionalità / classe non è ‘ t estrae sempre tutti i valori di archiviazione / elaborazione quando viene utilizzato ” sistema di coordinate di importazione “.’ stiamo lavorando per risolverlo. Penso questo è ciò in cui ‘ ti imbatti.
• I ‘ m vedendo questo problema – anche se creo il Feature Dataset e utilizzo il meccanismo di importazione e ho selezionato la feature class, posso ancora ‘ t trascinare / copiare la feature class nel Feature Dataset appena creato senza lerrore di cui sopra.

Penso che uno dei messaggi a ESRI sia fornire un parametro più specifico differenze di informazioni di debug quando si verifica questo errore. Anchio ho riscontrato questo errore anche dopo aver controllato attentamente i sistemi di riferimento spaziale e le proiezioni, come penso faccia la maggior parte degli utenti GIS.

Ho trovato la procedura per utilizzare le funzionalità di copia di ArcToolbox per rimediare ai messaggi di errore che si verificano quando vengono utilizzati i meccanismi di importazione o copia. Qui dipendiamo dalla procedura della casella degli strumenti Copia feature per risolvere correttamente le differenze di riferimento o di proiezione prima di introdurre la feature class nel dataset dellentità.

Ho anche provato a creare il dataset dellentità con un sistema di proiezione definito nel data di creazione del set di dati, quindi proiettare le classi di entità geografiche nel set di dati delle caratteristiche utilizzando lo strumento di proiezione ArcToolbox con la stessa proiezione e ho comunque ricevuto lerrore descritto qui quando provo a importare o copiare la classe di entità geografiche nel set di dati.

Questi problemi del sistema di coordinate vengono mascherati quando si utilizzano i dati in ArcMap. Poiché ArcMap esegue la proiezione al volo, è possibile aggiungere più classi di entità geografiche ciascuna con proiezioni diverse a una mappa ArcMap senza che lutente se ne accorga. ArcMap avviserà dei diversi sistemi di riferimento delle coordinate.