1
文件大小膨胀是否与gdalwarp正常？
在使用gdalwarp（通过-tap）投影并对齐到栅格后，我注意到输出栅格比原始栅格大得多。相当彻底的网络搜索发现了Trac问题： 弗兰克·沃默丹（Frank Warmerdam）解释了原因： “经过仔细检查，所讨论文件的不同之处在于，gdal_translate使用TIFFWriteScanline（）接口从GTiffDataset :: CreateCopy？（）内部写入输出文件，而这仅写入了最后一个'strip'完整的图像区域所需的文件。但是gdalwarp会通过blockio接口，该接口会写入完整的最终条带，甚至是掉落到文件末尾的部分。” 但是，此Trac问题gdalwarp已有7年之久了，我知道GDAL实用程序已经进行了一些更改。我想知道上述推理是否仍然成立，我看到的文件大小膨胀是否“正常”。此处的“正常”一词可能表示意料之中或意料之中，但更重要的是：是否可以采取任何措施来减轻这种影响，即减小输出栅格文件的大小？下表是我遇到的文件大小膨胀的表。 Input File Size (bytes) Output File Size (bytes) Inflation 1437380431 1698334217 18% 1428001178 1698334433 19% 41683165 137036637 228% 输入的TIFF文件是在ArcGIS中创建的，因此具有外部Worldfile，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压缩率。