Velocità di vari formati di dati raster

Ho problemi a localizzare qualsiasi discussione o benchmark comparativo di diversi formati di file raster (ad esempio, per l'uso nell'analisi dei dati in R). Qualcuno ha qualche idea sul perché determinati formati possono essere più veloci o più lenti? O le differenze dovrebbero essere minime?

In particolare, sono interessato se la conversione di un raster (ad esempio un file GEOTIFF) in un formato diverso (ad esempio un netCDF) sia mai utile ai fini della velocità di lettura / scrittura e altre operazioni.

Ecco un mio vecchio articolo sul blog che esamina le dimensioni del file e il tempo di accesso dei formati. Non ho studiato la velocità di scrittura, solo il tempo di accesso. Direi che probabilmente sarebbero direttamente collegati, ma non sarebbero in grado di garantirlo.

Riepilogo dell'articolo: Sembra che Packbits offra i migliori tempi di accesso (a scapito dello spazio su disco), mentre Deflate offre tempi di accesso intermedi / lenti per file intermedi / piccoli. Inoltre, puoi testare i tempi di accesso in modo più empirico creando miniature di varie dimensioni e tempistiche di quanto tempo impiega. Esempio di comando:time gdal_translate -outsize <thumbnail dimensions> -of GTiff <compressed image file> <thumbnail file>

Supponendo che l'unica cosa rilevante per R in questo caso sia la velocità con cui può leggere i dati dal file, proprio come farebbe qualsiasi altro processo, questo dovrebbe darti una buona indicazione.

Per le operazioni di lettura / scrittura , è possibile verificare la velocità di tali operazioni utilizzando system.time (). Ecco alcuni risultati del caricamento di un file DEM in R (pacchetto Raster) tradotto in quattro formati (ASCII, IMG e TIF senza compressione e Deflate). Ad esempio, su un raster di ~ 26 MB:

> system.time(dem <- raster("~/workspace/TEMP/kideporegion.img"))
 user  system elapsed 
 0.154   0.002   0.157 

'Elapsed' indica il tempo totale (secondi) impiegato per l'operazione. Eseguendo le operazioni 10 volte ciascuna e osservando il tempo medio trascorso:

              mean   diff
ASC         0.2237 0.3317
IMG         0.1544 0.0318
tif-Deflate 0.1510 0.0099
tif-none    0.1495 0.0000
tif-pack    0.1513 0.0118

TIFF senza compressione è il più veloce ... seguito da vicino da Deflate (0,1% più lento) e TIFF-Packbits (1,8% più lento), quindi IMG (3,2% più lento) e ASC (33% più lento). (Questo è su un Macbook Pro 2.4 GHz con un SSD, quindi operazioni su disco veloci)

Questo è semplicemente per caricare i file, non manipolarli.

Forse non si tratta davvero di quale formato di immagine raster abbia parametri di apertura migliori - piuttosto quali formati di immagine raster sono i formati di sorgente raster più efficienti per l'apertura e la lettura come input in un array numerico R. E successivamente, qual è il formato di output più efficiente da R, supponendo che tu stia restituendo i risultati al raster.

In entrambi i casi, se hai intenzione di lavorare con raster in R, probabilmente utilizzerai i pacchetti rgdal e R ncdf per integrare ciò che è contenuto nel pacchetto R raster . Con il principale affidamento sul comando gdalwarp . Devi fare delle dipendenze di formato lì per fare la tua scelta raster. Troverai un bel po 'di copertura su SO e vari forum / blog / wiki di OSGEO e R.

Ma poiché si tratta di un forum GIS in cui l'utilizzo di Python è in ascesa relativa, noterò che ci sono vantaggi nel lavorare con i dati raster in un array numpy Python, con una dipendenza simile dalle librerie gdal per il caricamento, la conversione e l'esportazione raster. Alcuni ritengono che la gestione della memoria e la struttura del codice in Python siano preferibili rispetto alla R nativa, forse date un'occhiata a RPy2 o PypeR poiché entrambi potrebbero essere appropriati per il vostro uso dell'analisi.

Una grande domanda è se leggerai l'intero raster dal file in memoria prima di elaborarlo, o se il file è così grande da poterlo elaborare in modo incrementale o elaborare un sottoinsieme del file complessivo.

Se caricherai tutto in memoria, eseguirai principalmente l'accesso sequenziale e il formato più veloce sarà un raggruppamento tra memoria semplice e compressa (a seconda di cose come la velocità della tua CPU rispetto al disco). Qualsiasi formato di file binario sarà probabilmente abbastanza vicino (ASCII sarà più lento).

Se è necessario elaborare un sottoinsieme di un file molto grande, un formato che raggruppa il sottoinsieme che si desidera più vicini potrebbe essere più veloce, ad esempio: riquadri o un formato in grado di calcolare gli offset. A volte qui si ottengono approcci non compressi perché può essere banale calcolare dove una determinata parte dell'immagine risiede all'interno del file, soprattutto se è necessaria solo una parte di una riga molto grande, ma la compressione può essere eseguita in modo granulare che funziona bene per alcuni schemi di accesso.

Siamo spiacenti, ma probabilmente dovrai fare un benchmark in base al tuo modello di accesso, piuttosto che ottenere una taglia unica. Naturalmente può dipendere non solo dal formato del file e dai fattori di cui sopra, ma dai driver per quel formato e dal tuo software.

Il modo in cui pensi a questo tipo di problemi è in termini di come l'applicazione accede al tuo file, rispetto a come i dati sono disposti nel tuo file. L'idea è che se puoi accedere ai tuoi dati in modo sequenziale, sarà molto più efficiente che se accedessi in modo casuale.

GeoTIFF è una raccolta di "immagini" 2D o array. NetCDF è un archivio generico per array multidimensionali. Ma se si memorizzano gli array nello stesso modo in netCDF come in GeoTIFF, si otterranno le stesse prestazioni, più o meno.

Si può anche riorganizzare i dati in netCDF, quindi in linea di principio si potrebbe ottimizzare per i vostri schemi di lettura. La mia ipotesi è che la maggior parte delle applicazioni GIS siano ottimizzate per il layout 2D GeoTIFF, quindi non c'è molto da guadagnare riorganizzando.

Infine, Id dice che conta davvero solo quando hai file molto grandi, almeno decine di megabyte.

Ho letto un paio di pagine su questo diversi anni fa e da allora ho usato tiff con compressione packbits, piastrellato con un'intestazione geotiff e sono stato felice.

articolo del team arcpad

wiki

Ma dopo aver letto quanto segue, riconsidererò e forse userò la varietà di sgonfiaggio.

Sito Arcpad

Così tanti pacchetti usano GDAL sotto il cofano, ad esempio rgdal, QGIS, GRASS, ecc. Se stessi usando uno di quei pacchetti, allora penserei di convertire le mie immagini in vrt. Ho visto spesso raccomandare che quando è necessario utilizzare due comandi GDAL, il file intermedio dovrebbe essere un file vrt perché l'overhead di lettura è minimo (ad esempio, http://www.perrygeo.com/lazy-raster-processing -with-gdal-vrts.html ). Sembra che il tuo flusso di lavoro sia: converti una volta e leggi molte volte. Forse vrt sarebbe appropriato.

[Modifica: collegamento corretto]