Rozmiar pliku inflacji normalny z gdalwarp?

19

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.tif

Rozumiem, że w rzadkich przypadkach kompresja tworzy większy plik, ale efekt jest taki sam bez kompresji LZW. Proporcje w tabeli dotyczą kompresji LZW.

Artur
źródło

Odpowiedzi:

30

Jest to znany i długotrwały problem, że gdalwarp nie radzi sobie dobrze z kompresją . Rozwiązaniem jest gdalwarp bez kompresji, a następnie gdal_translate z kompresją.

Aby uniknąć dwóch długich procesów, najpierw gdalwarp do VRT, jest naprawdę szybki, a następnie gdal_translate z opcją -co compress = lzw.

to znaczy

$ gdalwarp -tap -tr 30 30 -t_srs "etc..." -of vrt input_file.tif output_file.vrt
$ gdal_translate -co compress=LZW output_file.vrt output_file.tif

Jeśli używasz GDAL 2x , możesz połączyć to w jedną operację, pisząc VRT /vsistdouti przesyłając go do niego gdal_translatei określając /vsistdinjako dane wejściowe. Na przykład:

gdalwarp -q -t_srs EPSG:32611 -of vrt input_file.tif /vsistdout/ | gdal_translate -co compress=lzw  /vsistdin/ output_file.tif
użytkownik2856
źródło
Dziękujemy za rozwiązanie, którego z powodzeniem wykorzystałem, aby uniknąć błędu przepełnienia liczby całkowitej. Ale gdy rozwiązuje błąd, na moim cieniu mam dziwny wzór. Zadałem
Tim Autin