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 :-) Regards, -- Dr. Margherita Di Leo
_______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
