Инфляция размера файла нормальная с gdalwarp?

После использования gdalwarpдля проецирования и выравнивания по сетке (через -tap) нескольких растров я заметил, что выходные растры были значительно больше, чем исходные растры. Достаточно тщательный поиск в Интернете выявил эту проблему Trac :

Фрэнк Вармердам объяснил причину:

«При тщательном рассмотрении разница в рассматриваемом файле заключается в том, что gdal_translate использует интерфейс TIFFWriteScanline () для записи выходного файла из GTiffDataset :: CreateCopy? (), И при этом записывается только столько конечной« полосы » файл, необходимый для заполнения области изображения. Но gdalwarp проходит через интерфейс blockio, который записывает всю финальную полосу, даже часть, которая выпадает из конца файла. "

Однако этой проблеме Trac ~ 7 лет, и я знаю некоторые изменения в утилитах GDAL, в том числе gdalwarpвнесенные с тех пор. Я хотел бы знать, если приведенные выше рассуждения все еще верны, и если инфляция размера файла, которую я вижу, является "нормальной". Слово «нормальный» здесь может означать неудивительный или ожидаемый но, что более важно: есть ли что-нибудь, что можно сделать, чтобы смягчить эффекты, то есть уменьшить размер выходного растрового файла? Ниже приведена таблица инфляции размера файла, которую я испытываю.

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

Входные файлы TIFF были созданы в ArcGIS и, таким образом, имеют внешние файлы Worldfiles, XML и DBF, но они не составляют разницу в размере файла. Вот пример gdalwarpвызова, как я использовал его во всех этих случаях; фактическое выполнение было обработано 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

Я понимаю, что в редких случаях сжатие дает больший файл, но эффект тот же без сжатия LZW. Соотношения в таблице приведены для компрессии LZW.

Это хорошо известная и давняя проблема, что gdalwarp плохо справляется со сжатием . Решением является gdalwarp без сжатия, а затем gdal_translate со сжатием.

Чтобы избежать двух длительных процессов, сначала gdalwarp to VRT, это действительно быстро, а затем gdal_translate с опцией -co compress = lzw.

т.е.

$ 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

Если вы используете GDAL 2x, вы можете объединить это в одну операцию, записав VRT /vsistdoutи отправив его по трубопроводу gdal_translateи указав /vsistdinв качестве входа. Например:

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