Po użyciu gdalwarpdo wyświetlania i wyrównywania do rastra (przez -tap) pewnej liczby rastrów zauważyłem, że wyjściowe rastry były znacznie większe niż oryginalne rastry. Dość dokładne wyszukiwanie w sieci ujawniło ten problem z Trac :
Frank Warmerdam wyjaśnił przyczynę:
„Po dokładnym sprawdzeniu różnica w tym pliku jest taka, że gdal_translate używa interfejsu TIFFWriteScanline () do zapisywania pliku wyjściowego z GTiffDataset :: CreateCopy? (), A to zapisuje tylko tyle ostatniego„ paska ” plik jest wymagany do uzupełnienia obszaru obrazu. Ale gdalwarp przechodzi przez interfejs blockio, który zapisuje pełny pasek końcowy, nawet część wypadającą z końca pliku. "
Ten problem z Tracem ma jednak ~ 7 lat i wiem, że niektóre zmiany w narzędziach GDAL, w tym gdalwarprównież zostały wprowadzone. Chciałbym wiedzieć, czy powyższe rozumowanie nadal obowiązuje i czy inflacja wielkości pliku, którą widzę, jest „normalna”. Słowo „normalny” może być tutaj rozumiane jako nie zaskakujące lub oczekiwane, ale, co ważniejsze: czy można coś zrobić, aby złagodzić skutki, tj. Zmniejszyć rozmiar wyjściowego pliku rastrowego? Poniżej znajduje się tabela inflacji wielkości pliku, której doświadczam.
Input File Size (bytes) Output File Size (bytes) Inflation
1437380431 1698334217 18%
1428001178 1698334433 19%
41683165 137036637 228%
Wejściowe pliki TIFF zostały utworzone w ArcGIS, a zatem mają zewnętrzne pliki Worldfiles, XML i DBF, ale nie stanowią one różnicy w rozmiarze pliku. Oto przykładowe gdalwarpwywołanie, ponieważ użyłem go we wszystkich tych przypadkach; faktyczne wykonanie było obsługiwane przez 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.tifRozumiem, że w rzadkich przypadkach kompresja tworzy większy plik, ale efekt jest taki sam bez kompresji LZW. Proporcje w tabeli dotyczą kompresji LZW.