Converti enorme XYZ CSV in GeoTIFF


11

Ho un'enorme quantità di dati sotto forma di CSV contenente coordinate UTM come Xe Ye un valore di elevazione come Zinformazioni. Devo convertire questi dati in un DEM come GeoTIFF per ulteriori analisi. In questo caso, una quantità enorme significa 16 m. linee, con un punto X, Ye Zper linea. I punti sono equamente distribuiti, pertanto non è necessaria un'interpolazione; ogni punto deve solo essere convertito in una cella raster.

I dati originali sono arrivati ​​senza separatore, con larghezze di colonna fisse. Ho già capito come convertire la sintassi del file per utilizzare un separatore invece di larghezze fisse ed eliminare tutti i caratteri dello spazio, utilizzando l'editor di testo di flusso sed . Da qui in poi, normalmente il mio flusso di lavoro consisterebbe nell'importare i dati in ArcGIS creando una classe di funzionalità da X, Ye Zdati e come secondo passo, convertendo il file shapefile in un GeoTIFF, usando lo strumento Point to Raster . Tuttavia, il file che ho attualmente è troppo grande per questo processo.

Invece del flusso di lavoro sopra descritto, stavo cercando un'alternativa efficiente e ho scoperto GDAL. Tuttavia, in gdal_translate, il formato supportato più vicino che posso trovare nell'elenco dei tipi di file supportati, è la griglia ASCII ma nessuna XYZ separata da virgola. Un'altra difficoltà è che ho le coordinate UTM , mentre la maggior parte degli esempi sembra utilizzare coordinate in gradi decimali. Tuttavia, devo rimanere all'interno del sistema UTM (o almeno, il mio output GeoTIFF deve essere in un sistema di coordinate UTM).

Quindi sto cercando un modo per convertire il CSV XYZ in un GeoTIFF, usando GDAL , ma finora non sono riuscito a trovare esempi che affrontino questo esatto problema. Sarei molto felice per alcuni suggerimenti o anche esempi di codice.


Perché pensi che il metodo GDAL sarebbe più efficiente del metodo Esri?
artwork21

L'esempio esatto di usare un xyz-csv per un tiff è nel documentaion qui: gdal.org/gdal_grid.html
Matte

Qual è esattamente la domanda? In questo momento la risposta è "sì, puoi usare GDAL per convertire". :}
bugmenot123

La domanda è come applicare la conversione. Il commento di Matte sembra fornire la soluzione: ci proverò.
Arne,

Ok! Potete fornire un esempio minimo di dati? Vuoi una risposta in GDAL o altri strumenti gratuiti (es. GMT) andrebbero bene?
bugmenot123

Risposte:


16

Puoi farlo usando GDAL, supporta direttamente il formato XYZ . Non importa se le tue coordinate sono UTM, gdal_translate verrà emesso nello stesso sistema di coordinate.

Quindi convertire in GeoTIFF è semplice come:

gdal_translate test.xyz test.tif

Guarda il documento GeoTIFF per le opzioni di output (come la compressione) e il documento gdal_translate per ulteriori informazioni sull'utilizzo. In particolare, è necessario specificare quale sia il sistema di coordinate con il -a_srsparametro.

-a_srs srs_def:

Sostituisci la proiezione per il file di output. Srs_def può essere uno dei soliti moduli GDAL / OGR, WKT completo, PROJ.4, EPSG: n o un file contenente il WKT.

gdal_translate -a_srs EPSG:12345 test.xyz test.tif

Sono supportate larghezze di colonna separate da virgola / spazio, con e senza una riga di intestazione.

I separatori di colonne supportati sono spazio, virgola, punto e virgola e tabulazioni.

$ head -n 2 test_space.xyz 
x y z
146.360047076550984 -39.0631214488636616 0.627969205379486084

$ gdalinfo test_space.xyz
Driver: XYZ/ASCII Gridded XYZ
Files: test_space.xyz
Size is 84, 66
Coordinate System is `'
Origin = (146.359922066953317,-39.062997159090934)
Pixel Size = (0.000250019195332,-0.000248579545455)
Corner Coordinates:
Upper Left  ( 146.3599221, -39.0629972) 
Lower Left  ( 146.3599221, -39.0794034) 
Upper Right ( 146.3809237, -39.0629972) 
Lower Right ( 146.3809237, -39.0794034) 
Center      ( 146.3704229, -39.0712003) 
Band 1 Block=84x1 Type=Float32, ColorInterp=Undefined
  Min=0.336 Max=0.721 

$ head -n 2 test_commas.xyz 
x, y, z
146.360047076550984, -39.0631214488636616, 0.627969205379486084

$ gdalinfo test_commas.xyz
Driver: XYZ/ASCII Gridded XYZ
etc...

$ head -n 2 test_formatted.xyz
x                       y                       z
146.3600471            -39.06312145             0.627969205

$ gdalinfo test_formatted.xyz
Driver: XYZ/ASCII Gridded XYZ
etc...

Gli unici gotcha di cui sono a conoscenza sono:

  1. L'apertura di un set di dati di grandi dimensioni può essere lenta poiché il driver deve eseguire la scansione dell'intero file per determinare la dimensione del set di dati e la risoluzione spaziale; e
  2. Il file deve essere ordinato correttamente (da Y, quindi X).

    Le celle con le stesse coordinate Y devono essere posizionate su linee consecutive. Per uno stesso valore di coordinata Y, le linee nel set di dati devono essere organizzate aumentando i valori X. Il valore della coordinata Y può tuttavia aumentare o diminuire.

    $ head -n 5 test.csv
    x,y,z
    146.3707979,-39.07778764,0.491866767
    146.3787985,-39.07157315,0.614820838
    146.3637974,-39.07132457,0.555555582
    146.3630473,-39.07579901,0.481217861
    
    $ gdalinfo test.csv
    ERROR 1: Ungridded dataset: At line 3, too many stepY values
    gdalinfo failed - unable to open 'test.csv'.
    
    $ tail -n +2 test.csv| sort -n -t ',' -k2 -k1 > test_sorted.xyz
    
    $ head -n 5 test_sorted.xyz 
    146.3600471,-39.07927912,0.606096148
    146.3602971,-39.07927912,0.603663027
    146.3605471,-39.07927912,0.603663027
    146.3607971,-39.07927912,0.589507282
    146.3610472,-39.07927912,0.581049323
    
    $ gdalinfo test_sorted.xyz
    Driver: XYZ/ASCII Gridded XYZ
    etc...

2
Consiglio vivamente di assegnare un CRS all'output per chiarire quali sono le coordinate:-a_srs EPSG:12345
bugmenot123

1
Buon punto @bugmenot
user2856

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.