¿El tamaño del archivo es normal con gdalwarp?

14

Después de usar gdalwarp para proyectar y alinear a la cuadrícula (a través de -tap ), varios rásteres notaron que los rásteres de salida eran significativamente más grandes que los rásteres originales. Una búsqueda en la Web bastante completa mostró este problema de Trac :

  

Frank Warmerdam explicó la razón:

     

"En una revisión cuidadosa, la diferencia en el archivo en cuestión se debe a que gdal_translate utiliza la interfaz TIFFWriteScanline () para escribir el archivo de salida desde GTiffDataset :: CreateCopy? (), y esto solo escribe la mayor parte de la tira final 'del archivo como se requiere para completar el área de la imagen. Pero gdalwarp atraviesa la interfaz de blockio que escribe la tira final completa, incluso la parte que cae del 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, incluido gdalwarp . Me gustaría saber si el razonamiento anterior sigue siendo válido y si la inflación del tamaño del archivo que veo es "normal". La palabra "normal" aquí puede entenderse como no sorprende o esperado pero, lo que es más importante, ¿se puede hacer algo para mitigar los efectos, es decir, reducir el ¿Tamaño de archivo ráster de salida? A continuación se muestra una tabla de la inflación de 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 no representan la diferencia en el tamaño del archivo. Aquí hay una muestra de gdalwarp call 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 relaciones en la tabla son con compresión LZW.

    
pregunta Arthur 12.03.2014 - 14:09

1 respuesta

23

Es un problema bien conocido y de larga data que gdalwarp no maneja bien la compresión . La solución es gdalwarp sin compresión, luego gdal_translate con compresión.

Para evitar dos procesos largos, gdalwarp a VRT primero, es muy 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 usa GDAL 2x , puede combinar esto en una sola operación escribiendo el VRT en /vsistdout y canalizando eso a gdal_translate y especificando /vsistdin como entrada. Por ejemplo:

gdalwarp -q -t_srs EPSG:32611 -of vrt input_file.tif /vsistdout/ | gdal_translate -co compress=lzw  /vsistdin/ output_file.tif
    
respondido por el Luke 13.03.2014 - 03:26

Lea otras preguntas en las etiquetas