Dateigrößeninflation normal mit gdalwarp?

Nachdem ich eine Reihe von Rastern mit gdalwarpprojiziert und am Raster (über -tap) ausgerichtet hatte, stellte ich fest, dass die Ausgabe-Raster erheblich größer waren als die ursprünglichen Raster. Eine ziemlich gründliche Websuche ergab dieses Trac-Problem :

Frank Warmerdam erklärte den Grund:

"Bei sorgfältiger Prüfung besteht der Unterschied in der fraglichen Datei darin, dass gdal_translate die TIFFWriteScanline () - Schnittstelle verwendet, um die Ausgabedatei aus GTiffDataset :: CreateCopy? () Heraus zu schreiben, und dies schreibt nur so viel wie der letzte" Streifen "der file as wird benötigt, um den Bildbereich zu vervollständigen. Aber gdalwarp durchläuft die Blockio-Schnittstelle, die den gesamten letzten Streifen schreibt, sogar den Teil, der vom Ende der Datei abfällt. "

Dieses Trac-Problem ist jedoch ~ 7 Jahre alt, und ich kenne einige Änderungen an den GDAL-Dienstprogrammen, einschließlich der gdalwarpseither vorgenommenen. Ich würde gerne wissen, ob die obigen Überlegungen immer noch zutreffen und ob die Dateigrößeninflation, die ich sehe, "normal" ist. Das Wort "normal" kann hier als " nicht überraschend" oder " erwartet" verstanden werden. Aber was noch wichtiger ist: Gibt es etwas, das getan werden kann, um die Auswirkungen abzuschwächen, dh die Größe der Ausgabe-Raster-Datei zu verringern? Unten ist eine Tabelle der Dateigrößeninflation, die ich erlebe.

Input File Size (bytes)     Output File Size (bytes)    Inflation
1437380431                  1698334217                   18%
1428001178                  1698334433                   19%
  41683165                   137036637                  228%

Die TIFF-Eingabedateien wurden in ArcGIS erstellt und weisen daher externe Worldfiles, XML- und DBF-Dateien auf, die jedoch den Unterschied in der Dateigröße nicht ausmachen. Hier ist ein Beispielaufruf gdalwarp, wie ich ihn in all diesen Fällen verwendet habe. Die eigentliche Ausführung übernahm ein 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

Ich verstehe, dass die Komprimierung in seltenen Fällen eine größere Datei ergibt, der Effekt jedoch ohne die LZW-Komprimierung derselbe ist. Die Verhältnisse in der Tabelle beziehen sich auf die LZW-Komprimierung.

Es ist ein bekanntes und langjähriges Problem, dass GDALWARP nicht gut mit Komprimierung umgehen kann . Die Lösung ist, gdalwarp ohne Komprimierung und dann gdal_translate mit Komprimierung auszuführen.

Um zwei langwierige Prozesse zu vermeiden, müssen Sie zuerst von GDALWARP zu VRT wechseln. Dann können Sie GDAL_translate mit der Option -co compress = lzw ausführen.

dh

$ 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

Wenn Sie GDAL 2x verwenden , können Sie dies zu einer einzigen Operation kombinieren, indem Sie den VRT schreiben /vsistdoutund diesen weiterleiten gdal_translateund /vsistdinals Eingang festlegen. Beispielsweise:

gdalwarp -q -t_srs EPSG:32611 -of vrt input_file.tif /vsistdout/ | gdal_translate -co compress=lzw  /vsistdin/ output_file.tif