Sau khi sử dụng gdalwarpđể chiếu và căn chỉnh theo lưới (thông qua -tap), một số trình quét tôi nhận thấy rằng các trình quét đầu ra lớn hơn đáng kể so với các trình quét gốc. Một tìm kiếm web khá kỹ lưỡng đã đưa ra vấn đề Trac này :
Frank Warmerdam giải thích lý do:
"Khi xem xét cẩn thận, sự khác biệt trong tệp được đề cập là do gdal_translate sử dụng giao diện TIFFWriteScanline () để ghi tệp đầu ra từ bên trong GTiffDataset :: CreateCopy? () Và điều này chỉ ghi nhiều nhất là 'dải' cuối cùng của tập tin như được yêu cầu để hoàn thành khu vực hình ảnh. Nhưng gdalwarp đi qua giao diện blockio ghi dải hoàn chỉnh cuối cùng, ngay cả phần rơi ra khỏi phần cuối của tập tin. "
Tuy nhiên, vấn đề Trac này đã được 7 năm tuổi và tôi biết một số thay đổi đối với các tiện ích GDAL, bao gồm cả gdalwarpđã được thực hiện kể từ đó. Tôi muốn biết nếu lý do trên vẫn còn và nếu lạm phát kích thước tệp tôi thấy là "bình thường". Từ "bình thường" ở đây có thể được hiểu là không gây ngạc nhiên hoặc mong đợi , nhưng quan trọng hơn: có bất cứ điều gì có thể được thực hiện để giảm thiểu các hiệu ứng tức là giảm kích thước tệp raster đầu ra không? Dưới đây là bảng lạm phát kích thước tệp tôi đang gặp phải.
Input File Size (bytes) Output File Size (bytes) Inflation
1437380431 1698334217 18%
1428001178 1698334433 19%
41683165 137036637 228%Các tệp TIFF đầu vào đã được tạo trong ArcGIS và do đó có các tệp Worldfiles, XML và DBF bên ngoài nhưng chúng không tạo ra sự khác biệt về kích thước tệp. Đây là một gdalwarpcuộc gọi mẫu vì tôi đã sử dụng nó trong tất cả các trường hợp này; thực thi thực tế đã được xử lý bởi 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.tifTôi hiểu rằng trong các trường hợp hiếm hoi, nén tạo ra một tệp lớn hơn, nhưng hiệu quả là như nhau mà không cần nén LZW. Các tỷ lệ trong bảng là với nén LZW.