文件大小膨胀是否与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压缩率。