여러 래스터 gdalwarp를 통해 그리드에 정렬하고 정렬 한 후 -tap출력 래스터가 원래 래스터보다 상당히 큰 것을 알았습니다. 상당히 철저한 웹 검색 으로이 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 압축입니다.