[gdal-dev] Compression not applying when updating/exiting GeoTiff file in GDAL?

[taylorday.assimila at gmail.com]

Hi all,

 

I posted this question on GIS SE (link
<https://gis.stackexchange.com/questions/317009/compression-not-applying-whe
n-updating-exiting-geotiff-file-in-gdal?noredirect=1#comment515654_317009> )
but have not had any luck, so was wondering if anyone here could help. 

 

I have a `GeoTiff` file with dimensions 300 x 300 and 8760 bands (hourly for
one full year). I am testing some code that opens the file, updates ONE band
and exits - but I am finding that the file size almost doubles when I exit
the file, despite the new band being the same data type etc. Code is as
follows:

 

I am creating the `GeoTiff` file using the following creation options using
many singular `GeoTiff` files:

 

    gdal_merge.py -separate -co BIGTIFF=YES -co COMPRESS=DEFLATE -co
PREDICTOR=1 -co TILED=YES -co BLOCKXSIZE=64 -co BLOCKYSIZE=64 -o block64.tif
*.tif

    

The file size is 947MB.

 

I am then updating the file using the following code:

 

    ds = gdal.Open("block64.tif", gdal.GA_Update) 

 

    # Some simple operation to change band values

    arr = ds.GetRasterBand(11).ReadAsArray() / 2

    ds.GetRasterBand(11).WriteArray(arr)

    ds.FlushCache()

    ds = None

 

The file size is now 1.9GB.

 

My preliminary conclusion is that the compression/creation options are not
being applied once I've updated and exited the file. Is there any way to
re-compress/reapply the options once I close the file? 

 

Current options: 

 

1.	read file, make changes, save to a new file - this is not ideal as
saving the file each time I want to make an update is slow and this
operation is happening server-side and needs to be as quick as possible.
2.	Use VRTs - This is a good option, but I'd like all bands in one
GeoTiff to make I/O as quick as possible when extracting time series data,
so a VRT wrapper does not help with updating the base file. 

 

Any help would be greatly appreciated. 

 

Many thanks, 

 

Taylor 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20190329/c1d6d0b0/attachment.html>