¿Inflación del tamaño del archivo normal con gdalwarp?

Después de usar gdalwarppara proyectar y alinear a la cuadrícula (a través de -tap) una serie de rásteres, noté que los rásteres de salida eran significativamente más grandes que los rásteres originales. Una búsqueda en la web bastante exhaustiva reveló este problema de Trac :

Frank Warmerdam explicó la razón:

"En una revisión cuidadosa, la diferencia en el archivo en cuestión es porque gdal_translate usa la interfaz TIFFWriteScanline () para escribir el archivo de salida desde GTiffDataset :: CreateCopy? (), Y esto solo escribe la mayor parte de la 'tira' final de la "como se requiere para completar el área de la imagen. Pero gdalwarp pasa a través de la interfaz blockio que escribe la tira final completa, incluso la parte que se cae al final del archivo".

Sin embargo, este problema de Trac tiene ~ 7 años y sé que se han realizado algunos cambios en las utilidades de GDAL, incluso gdalwarpdesde entonces. Me gustaría saber si el razonamiento anterior aún se mantiene y si la inflación del tamaño de archivo que estoy viendo es "normal". La palabra "normal" aquí podría tomarse en el sentido de sorprendente o esperada , pero, lo que es más importante: ¿hay algo que se pueda hacer para mitigar los efectos, es decir, reducir el tamaño del archivo ráster de salida? A continuación se muestra una tabla de la inflación del tamaño de archivo que estoy experimentando.

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

Los archivos TIFF de entrada se crearon en ArcGIS y, por lo tanto, tienen archivos Worldfiles, XML y DBF externos, pero estos no compensan la diferencia en el tamaño del archivo. Aquí hay una gdalwarpllamada de muestra como la he usado en todos estos casos; la ejecución real fue manejada por 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

Entiendo que en casos raros la compresión crea un archivo más grande, pero el efecto es el mismo sin la compresión LZW. Las proporciones en la tabla son con compresión LZW.

Es un problema bien conocido y antiguo que gdalwarp no trata bien con la compresión . La solución es gdalwarp sin compresión y luego gdal_translate con compresión.

Para evitar dos procesos largos, primero gdalwarp a VRT, es realmente rápido, luego gdal_translate con la opción -co compress = lzw.

es decir

$ 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

Si utiliza GDAL 2x , puede combinar esto en una sola operación escribiendo el VRT /vsistdouty canalizándolo gdal_translatey especificando /vsistdincomo entrada. Por ejemplo:

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