を使用gdalwarpし-tapて多数のラスタを（グリッドを介して）グリッドに配置した後、出力ラスタが元のラスタよりも大幅に大きいことに気付きました。かなり徹底的なWeb検索により、このTracの問題が判明しました。
フランク・ウォーマーダムはその理由を説明しました：
「慎重に検討すると、問題のファイルの違いは、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で作成されたため、外部のワールドファイル、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圧縮の場合です。