После использования 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.