Dimensione del file inflazione normale con gdalwarp?

Dopo aver utilizzato gdalwarpper proiettare e allineare alla griglia (via -tap) un numero di raster ho notato che i raster di output erano significativamente più grandi dei raster originali. Una ricerca web abbastanza approfondita ha rivelato questo problema di Trac :

Frank Warmerdam ha spiegato il motivo:

"Su un'attenta revisione, la differenza nel file in questione è perché gdal_translate utilizza l'interfaccia TIFFWriteScanline () per scrivere il file di output all'interno di GTiffDataset :: CreateCopy? (), E questo scrive solo la maggior parte della 'striscia' finale del come richiesto per completare l'area dell'immagine. Ma gdalwarp passa attraverso l'interfaccia blockio che scrive l'intera striscia finale, anche la porzione che cade dalla fine del file. "

Questo problema di Trac ha ~ 7 anni, tuttavia, e so che alcune modifiche alle utility GDAL, tra cui gdalwarpsono state apportate da allora. Mi piacerebbe sapere se il ragionamento sopra è ancora valido e se l'inflazione della dimensione del file che vedo è "normale". La parola "normale" qui potrebbe essere intesa come non sorprendente o prevedibile , ma, cosa più importante, c'è qualcosa che può essere fatto per mitigare gli effetti, cioè ridurre le dimensioni del file raster di output? Di seguito è riportata una tabella dell'inflazione delle dimensioni del file che sto riscontrando.

Input File Size (bytes)     Output File Size (bytes)    Inflation
1437380431                  1698334217                   18%
1428001178                  1698334433                   19%
  41683165                   137036637                  228%

I file TIFF di input sono stati creati in ArcGIS e quindi hanno file Worldfile, XML e DBF esterni ma questi non fanno la differenza nella dimensione del file. Ecco una gdalwarpchiamata di esempio come l'ho usata in tutti questi casi; l'esecuzione effettiva è stata gestita da un Python subprocess( subprocess.Popen):

$ gdalwarp -tap -tr 30 30 -t_srs "+proj=aea +lat_1=20 +lat_2=60 +lat_0=40 +lon_0=-96 +x_0=0 +y_0=0 +ellps=GRS80 +datum=NAD83 +units=m +no_defs" -co "COMPRESS=LZW" input_file.tif output_file.tif

Capisco che in rari casi la compressione rende un file più grande, ma l'effetto è lo stesso senza la compressione LZW. I rapporti nella tabella sono con compressione LZW.

È un problema ben noto e di vecchia data che gdalwarp non gestisce bene la compressione . La soluzione è gdalwarp senza compressione, quindi gdal_translate con compressione.

Per evitare due lunghi processi, gdalwarp in VRT prima, è davvero veloce, quindi gdal_translate con l'opzione -co compress = lzw.

vale a dire

$ gdalwarp -tap -tr 30 30 -t_srs "etc..." -of vrt input_file.tif output_file.vrt
$ gdal_translate -co compress=LZW output_file.vrt output_file.tif

Se si utilizza GDAL 2x è possibile combinare questo in un'unica operazione scrivendo il VRT /vsistdoute collegandolo a gdal_translatee specificando /vsistdincome input. Per esempio:

gdalwarp -q -t_srs EPSG:32611 -of vrt input_file.tif /vsistdout/ | gdal_translate -co compress=lzw  /vsistdin/ output_file.tif