Une inflation de taille de fichier normale avec gdalwarp?

Après avoir utilisé gdalwarppour projeter et aligner sur la grille (via -tap) un certain nombre de rasters, j'ai remarqué que les rasters en sortie étaient beaucoup plus volumineux que les rasters d'origine. Une recherche Web assez approfondie a révélé ce problème Trac :

Frank Warmerdam a expliqué la raison:

"Après un examen attentif, la différence dans le fichier en question est que gdal_translate utilise l'interface TIFFWriteScanline () pour écrire le fichier de sortie à partir de GTiffDataset :: CreateCopy? (), Et cela n'écrit que la plus grande partie de la" bande "finale de la comme requis pour compléter la zone d'image. Mais gdalwarp passe par l'interface blockio qui écrit la bande finale complète, même la partie qui tombe à la fin du fichier. "

Ce problème Trac date de ~ 7 ans, cependant, et je sais que des modifications gdalwarpont été apportées aux utilitaires GDAL, notamment depuis. Je voudrais savoir si le raisonnement ci-dessus est toujours valable et si l'inflation de taille de fichier que je vois est "normale". Le mot «normal» ici peut être interprété comme signifiant non surprenant ou attendu mais, plus important encore: peut-on faire quelque chose pour atténuer les effets, c'est-à-dire réduire la taille du fichier raster en sortie? Voici un tableau de l'inflation de la taille du fichier que je connais.

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

Les fichiers TIFF d'entrée ont été créés dans ArcGIS et ont donc des fichiers Worldfiles, XML et DBF externes, mais ceux-ci ne font pas la différence de taille de fichier. Voici un exemple d' gdalwarpappel tel que je l'ai utilisé dans tous ces cas; l'exécution réelle a été gérée par 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

Je comprends que dans de rares cas, la compression crée un fichier plus volumineux, mais l'effet est le même sans la compression LZW. Les ratios dans le tableau correspondent à la compression LZW.

C'est un problème bien connu et de longue date que gdalwarp ne gère pas bien la compression . La solution est de gdalwarp sans compression puis gdal_translate avec compression.

Pour éviter deux processus longs, gdalwarp en VRT d'abord, c'est vraiment rapide, puis gdal_translate avec l'option -co compress = lzw.

c'est à 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

Si vous utilisez GDAL 2x, vous pouvez combiner cela en une seule opération en écrivant le VRT /vsistdoutet en le canalisant gdal_translateet en spécifiant /vsistdincomme entrée. Par exemple:

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