[gdal-dev] LZW Compression on geotiffs

[Even Rouault]

Le mercredi 01 octobre 2014 19:21:39, Stephen Roecker a écrit :
> I've also been toying with the compression settings lately and thought
> I would mention my experience. I'm not sure if this is known behavior,
> but when subsequently using the compressed rasters with 'gdaldem' I
> got some strange results when the raster was greater than 4GB (i.e.
> BIGTIFF). The resulting rasters were either corrupt, way way larger than
> they should have been, or I terminated before they completed due to
> the extreme length of time (> 2 hours) they took to process. When I
> used an uncompressed BIGTIFF raster with gdaldem, the results were as
> expected. This was all using gdal 11.0, and the following BIGTIFF
> compression settings, -co "TILED=YES" -co "BIGTIFF=YES" -co
> "COMPRESS=DEFLATE".

Stephen,

That it might be long or result in larger than expected file is not completely 
unsurprising. With formats like geotiff, the gdaldem utility fills the output 
raster line by line. So when creating a tiled compress geotiff, partial blocks 
may be read and written several times. Each time a compressed block is written 
and larger than its previous size it gets written at the end of the TIFF, and 
the previous space occupied is lost. That you get corruption is more 
surprising though.
But there was another code path in gdaldem, used for formats like PNG, that 
can also be used for GTiff. It is a bit slower when applied in the general 
case, but it is definitely needed in the use case you mentionned (tiled 
compressed geotiff). Fixed now by http://trac.osgeo.org/gdal/ticket/5678

In the meantime, outputing to uncompressed file and then gdal_translat'ing to 
compressed tiled file is the best option.

Even


> 
> Stephen
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com