หลังจากใช้gdalwarp
ในการฉายภาพและจัดเรียงตามตาราง (ผ่าน-tap
) จำนวนของ rasters ฉันสังเกตเห็นว่า rasters ที่ส่งออกมีขนาดใหญ่กว่า rasters ดั้งเดิมอย่างมีนัยสำคัญ การค้นหาเว็บอย่างละเอียดพอสมควรทำให้เกิดปัญหา Trac นี้ :
Frank Warmerdam อธิบายเหตุผล:
"ในการตรวจสอบอย่างละเอียดความแตกต่างในไฟล์ที่เป็นปัญหาคือเพราะ 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