ArcGIS non riesce a importare tutti i record dall'enorme file CSV nella tabella di geodatabase di file nonostante sia all'interno dei limiti delle dimensioni della tabella FGDB

11

Sto usando ArcGIS 10.0 su Windows 7 a 64 bit con 4 GB di RAM.

Ho alcune tabelle molto grandi in formato CSV da importare in ArcGIS, tutte hanno circa 30 campi, oltre 5 milioni di record per tabella (alcuni hanno il doppio o più) e dimensioni dei file fino a circa 5 GB. Sto cercando di importare ciascuno di essi in un geodatabase di file come tabelle separate in modo da poter infine collegarli a una classe di caratteristiche e analizzare i risultati nelle tabelle in base alla loro posizione.

Il problema è che ArcGIS sembra aver smesso di importare i record a un certo punto. Sto utilizzando lo strumento "Tabella in tabella" in Conversione> In geodatabase, ma lo strumento "Copia righe" presenta lo stesso problema. Anche se aggiungo semplicemente il file CSV direttamente ad ArcGIS senza provare prima a convertirlo in una tabella FGDB, il problema è lo stesso. Una delle mie tabelle ha circa 11 milioni di record e ArcGIS ne importa solo circa 10 milioni. ArcGIS non mi dice che si è verificato un errore, lo strumento termina come se niente fosse.

L'ho provato un paio di volte e il numero di record che lo compongono nella tabella FGDB è sempre lo stesso e non sembra essere un limite di dimensione del file di cui abbia mai sentito parlare (non un quadrato di 2 o 16). ArcGIS è stato in grado di importare un altro CSV con circa 6 milioni di record e tutti i record sono arrivati (anche se con i problemi che ho con la tabella più grande, anche quella più piccola è un po 'sospetta). Il sito Web di ESRI elenca i seguenti limiti di dimensione in un file geodatabase e sono tutt'altro che colpire nessuno di essi:

Dimensione del geodatabase del file: nessun limite

Dimensioni della tabella o della classe di funzionalità: 1 TB (impostazione predefinita), 4 GB o 256 TB con parola chiave

Numero di classi e tabelle di entità geografiche: 2.147.483.647

Numero di campi in una classe o tabella di entità geografiche: 65.534

Numero di righe in una classe o tabella di entità geografiche: 2.147.483.647

Lunghezza nome geodatabase: numero di caratteri consentiti dal sistema operativo in una cartella

Lunghezza nome classe classe o tabella: 160 caratteri

Lunghezza nome campo: 64 caratteri

Larghezza del campo di testo: 2.147.483.647

Tutto ciò che devo davvero fare a queste tabelle sono aggiungere un paio di campi, eliminare un paio di altri e generare valori per i nuovi campi (somme di alcuni dei campi esistenti). Sto usando ArcGIS per questo perché ho familiarità con il calcolatore di campo e so (o sapevo , fino ad ora) che poteva gestire tabelle costituite da milioni di record, mentre la maggior parte degli altri software desktop che ho a portata di mano (MS Access / Excel ) soffoca su così tanti dischi. Quindi sono aperto all'utilizzo di qualche altro software per manipolare la tabella originale e quindi esportare la tabella risultante (molto più piccola) in ArcGIS. In realtà, il fatto che io stia riscontrando questo problema e che ArcGIS non mi stia dando alcun errore o avvertimento che il problema si sta verificando mi fa venire voglia di gestire questi dati al di fuori di ArcGIS il più possibile.

— Dan C
fonte

2

Se "il numero di record che lo compongono nella tabella FGDB è sempre lo stesso", darei un'occhiata all'ultimo e al successivo record per vedere se potrebbero avere qualcosa in loro che sembra incoerente rispetto ai milioni importati con successo in precedenza.

— PolyGeo

1

Buona idea. Non riesco a vedere alcuna differenza tra l'ultimo record nella tabella FGDB troncata e il record successivo (dal CSV). Ho appena provato a rimuovere tutti i record importati con successo dal CSV di origine, quindi importare il resto in un'altra tabella FGDB e ha funzionato. Quindi non sembra essere un problema con nessun record. A peggiorare le cose, ho unito le due tabelle FGDB (tra le due ho tutti i record di origine), e ancora una volta ArcGIS finge che tutto sia andato bene, ma la tabella unita contiene solo 9,6 milioni dei 10,9 milioni di record dei due Tabelle FGDB.

— Dan C

Hai aperto un incidente di supporto con ESRI? Sembra a questo punto, hai scoperto quale potrebbe essere potenzialmente un problema piuttosto serio. Se non altro, il personale di supporto sarebbe interessato a conoscerlo semplicemente perché potrebbe già conoscere una soluzione o sarebbe disposto ad aiutare con i test.

— Ottieni Spatial

Concordo con Get Spatial, ma un ultimo test che potresti voler eseguire è la generazione di un file CSV con un campo in cui inserisci valori identici (forse "test"). Se la tua teoria è che 9,6 milioni è il massimo, questo limite verrebbe raggiunto ogni volta che vengono utilizzate 10 milioni di righe di "test", ma non quando lo sono 9,5 milioni di righe.

— PolyGeo

Ora ho provato con un CSV diverso, ma anche grande (oltre 10 milioni di record) e fallisce allo stesso modo, ma su una linea diversa (entrano circa 8,9 milioni di record). Quindi non sembra essere un numero specifico di record o una dimensione specifica della tabella. Proverò un test CSV con due campi e vedrò cosa succede. Chiamerò ESRI lunedì in entrambi i casi, tuttavia, questo processo fallito senza alcun messaggio di errore è inaccettabile e rende sospetti anche i record che lo rendono sospetto.

— Dan C

9

Ho chiamato il supporto ESRI a riguardo e la loro risposta non è stata incoraggiante, ma ha spiegato il problema. Parafrasando ESRI: il problema è che ArcGIS Desktop, essendo un software a 32 bit, è limitato all'utilizzo massimo di 4 GB di RAM. Il file di testo deve essere elaborato nella RAM prima di essere archiviato come una tabella, quindi ad un certo punto durante l'elaborazione ArcGIS stava colpendo il limite della RAM e si fermava lì. Il file che stavo importando aveva una dimensione di circa 6 GB. Apparentemente il fatto che sia fallito senza dare un messaggio di errore è unico per me, ho provato a farlo fare da altre persone nel mio ufficio e l'importazione è ancora fallita, ma ha dato un messaggio di errore (inutile, ma almeno qualcosa che ha permesso al l'utente sa che qualcosa è andato storto) e il rappresentante ESRI ha affermato che dovrebbe dare un errore.

La mia soluzione era quella di dividere il file in due CSV più piccoli usando un editor di testo (ho usato EditPad Pro), importare ciascuno di essi in un FGDB come tabella separata, quindi unire le due tabelle FGDB. Per qualche ragione questo non è riuscito la prima volta che l'ho provato, ma ha funzionato in seguito. Potrei provare a testarlo un po 'più a fondo, mi occuperò di file di queste dimensioni su base continuativa.

Sto usando ArcGIS 10.0, ma ArcGIS 10.1 Service Pack 1 è stato appena rilasciato e aggiunge la possibilità di utilizzare un geoprocessore in background a 64 bit, che consentirà al geoprocessore di utilizzare più di 4 GB di RAM, che potrebbe risolvere questo problema ma non posso prova quello.

AGGIORNAMENTO: ora sto usando ArcGIS 10.1 SP1 (con il componente aggiuntivo di geoprocessing in background a 64 bit) e importa con successo questi giganteschi CSV, almeno quelli con cui ho affrontato finora. Su una macchina con 14 GB di RAM (sì, 14), un CSV da 6 GB con circa 10,5 milioni di righe viene importato correttamente in una tabella FGDB.

— Dan C
fonte

1

Sarei curioso di provare a eseguirlo in una build a 64 bit di GDAL. Scommetto che funzionerebbe benissimo.

— Ragi Yaser Burhum,

7

Ai fini del caricamento dei dati, leggere un enorme file CSV in memoria è piuttosto sciocco. Ha davvero solo bisogno di leggere 1 riga alla volta.

Suggerirei di scrivere uno script Python e utilizzare il csvmodulo per leggerlo riga per riga e inserire le righe nella tabella usando un InsertCursor(o preferibilmente un arcpy.da.InsertCursorin quanto è più veloce, ma disponibile solo a 10.1).

Modifica: basta leggere il tuo ultimo paragrafo. Sembra che tu possa effettivamente farlo in Python abbastanza facilmente, anche esportando i risultati in CSV o in qualche altro formato.

Se potessi descrivere esattamente cosa devi fare con ogni riga e colonna sarebbe utile.

— blah238
fonte

4

Hai provato a dividere i file csv da 5 GB in piccoli.

c'è uno strumento per dividere il CSV in base alle righe o al conteggio dei file.

Dividi i file e poi prova a importare .. Ma c'è un limite in questo strumento, penso che funzionerà solo per la tabella in un file (penso di sì). pls. prova.

http://www.shivaranjan.com/2008/11/06/how-to-split-csv-file-into-multiple-parts-easily-and-quickly/

— vadivelan
fonte

Ho intenzione di provare che se devo, non ci sono molti CSV da affrontare, quindi probabilmente li dividerò manualmente con il mio editor di testo. Vorrei ancora scoprire se qualcun altro ha avuto questo problema, tuttavia, se ArcGIS avrà l'abitudine di fraintendere tavoli di grandi dimensioni e nemmeno di avere la cortesia comune di lanciare un messaggio di errore inutile, sarà un problema.

— Dan C

OK, l'ho appena provato e funziona parzialmente. Dopo aver diviso il CSV in due più piccoli (manualmente, con un editor di testo), sono stati importati correttamente in due tabelle FGDB separate e tutti i record sono lì. Ma quando provo a unire quelle due tabelle FGDB in una, ArcGIS esegue ancora una volta il processo come se nulla fosse sbagliato, e quindi nella tabella unita mancano 1,3 milioni di record.

— Dan C

2

Stavo riscontrando questo errore (001156) sulla stessa riga di un file di testo delimitato da pipe di grandi dimensioni (2.712.391) righe a circa un quarto del percorso.
Quindi ho pensato che ci fosse qualcosa di sbagliato in quella linea, ma era identico al resto delle file.
Ho finito per eliminare le righe dall'importazione parziale e quindi caricare i dati (Carica> Carica dati ...) e sono stato in grado di ottenere tutte le linee 2M +.

Anch'io sto usando il geoprocessing in background 10.1 SP1 con 64 bit su 16 GB di RAM ed è un processo che utilizzerà la RAM (non tutti i processi sono ancora abilitati in 64 bit).
Soluzione alternativa lenta, ma funzionante.
Potrebbe essere necessario impostare prima la tabella vuota se non si riesce con alcun grado di importazione.

— opaco
fonte