Ukuran file inflasi normal dengan gdalwarp?

19

Setelah menggunakan gdalwarpuntuk memproyeksikan dan menyelaraskan ke jaringan (melalui -tap) sejumlah raster saya perhatikan bahwa raster keluaran secara signifikan lebih besar daripada raster asli. Pencarian web yang cukup menyeluruh memunculkan masalah Trac ini :

Frank Warmerdam menjelaskan alasannya:

"Pada tinjauan yang cermat, perbedaan dalam file tersebut adalah karena gdal_translate menggunakan antarmuka TIFFWriteScanline () untuk menulis file output dari dalam GTiffDataset :: CreateCopy? (), Dan ini hanya menulis sebanyak 'strip' akhir dari File seperti yang diperlukan untuk menyelesaikan area gambar. Tapi gdalwarp melewati antarmuka blockio yang menulis strip akhir lengkap, bahkan bagian yang jatuh dari ujung file. "

Masalah Trac ini ~ 7 tahun, dan saya tahu beberapa perubahan pada utilitas GDAL, termasuk yang gdalwarptelah dibuat sejak itu. Saya ingin tahu apakah alasan di atas masih berlaku dan apakah inflasi ukuran file yang saya lihat "normal." Kata "normal" di sini mungkin diartikan tidak mengejutkan atau diharapkan tetapi, yang lebih penting: adakah yang bisa dilakukan untuk mengurangi efek yaitu mengurangi ukuran file raster output? Di bawah ini adalah tabel inflasi ukuran file yang saya alami.

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

File input TIFF dibuat dalam ArcGIS dan dengan demikian memiliki file Worldfiles, XML dan DBF eksternal tetapi ini tidak membuat perbedaan dalam ukuran file. Ini adalah contoh gdalwarppanggilan karena saya telah menggunakannya dalam semua kasus ini; eksekusi sebenarnya ditangani oleh 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

Saya mengerti bahwa dalam kasus yang jarang terjadi kompresi membuat file lebih besar, tetapi efeknya sama tanpa kompresi LZW. Rasio dalam tabel adalah dengan kompresi LZW.

Arthur
sumber

Jawaban:

30

Ini adalah masalah yang sudah diketahui dan berlangsung lama bahwa gdalwarp tidak menangani kompresi dengan baik . Solusinya adalah dengan gdalwarp tanpa kompresi lalu gdal_translate dengan kompresi.

Untuk menghindari dua proses yang panjang, gdalwarp ke VRT terlebih dahulu, ini sangat cepat, kemudian gdal_translate dengan opsi -co kompres = lzw.

yaitu

$ 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

Jika menggunakan GDAL 2x Anda dapat menggabungkan ini ke dalam satu operasi dengan menulis VRT /vsistdoutdan memipipkannya ke gdal_translatedan menentukan /vsistdinsebagai input. Sebagai contoh:

gdalwarp -q -t_srs EPSG:32611 -of vrt input_file.tif /vsistdout/ | gdal_translate -co compress=lzw  /vsistdin/ output_file.tif
pengguna2856
sumber
Terima kasih atas solusi Anda, yang saya berhasil gunakan untuk menghindari kesalahan integer overflow. Tetapi sementara itu memecahkan kesalahan, saya mendapatkan pola aneh di hillshade saya. Saya memposting pertanyaan terpisah di sini, alangkah baiknya jika Anda bisa melihatnya: gis.stackexchange.com/questions/292632/…
Tim Autin