[gdal-dev] bigtiff support maybe not working

Margherita Di Leo diregola at gmail.com
Mon Jul 16 09:01:53 PDT 2012

Hi Even,

> BigTIFF support likely works as expected. In that instance, the error
> comes from
> the huge value used for the -wm option of gdalwarp. Try to keep it below
> 2000.
> If I remember well, there must be a sanity check in the warping algorithm
> to
> prevent allocation of buffers above 2 GB, to avoid errors in 32bit
> environmenet.
> And in 64bit builds, there's little gain to expect from such huge values
> anyway.
> The GDAL_CACHEMAX value is also probably much bigger than really needed.
> In any
> case, you must make sure that the available RAM is at least the sum of the
> 2
> values, otherwise you'll get into disk swapping, which will anihilate the
> benefit of those optimizations.
> If you are playing with cache values, you must make sure to read and
> understand
> http://trac.osgeo.org/gdal/wiki/UserDocs/GdalWarp#WillincreasingRAMincreasethespeedofgdalwarp
> . To sum it up : "bigger is not necessarily better"
> But you could likely benefit from adding -co TILED=YES to produce a tiled
> GeoTIFF.
> And specifying -co BIGTIFF=YES is rarely needed. Recent GDAL builds will
> figure
> automatically if BigTIFF is necessary for uncompressed files. If you ask
> for
> compressed GeoTIFF, the heuristics might fail and the explicit BIGTIFF=YES
> option might be necessary.

thank you for valuable hints,
now I'm trying with:

CACHE="--config GDAL_CACHEMAX 8000 -wm 2000"
gdalwarp $CACHE -srcnodata -9999 -dstnodata -9999 -r bilinear -tr $RES $RES
$LIST mosaik_$RES.tif -co TILED=YES

It is taking long, of course, but somehow it is working and I don't get
error, so I have good expectations.. I'll keep you posted about the results


Dr. Margherita Di Leo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20120716/6913b153/attachment.html>

More information about the gdal-dev mailing list