Після використання 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.