The GDAL default value for GDAL_CACHEMAX is 40 MB. I routinely set up
my gdal_translate scripts to run with a larger value for GDAL_CACHEMAX.
export GDAL_CACHEMAX_value=50
gdal_translate --config GDAL_CACHEMAX ${GDAL_CACHEMAX_value}
In my benchmark tests, I have observed that this small increase in
GDAL_CACHEMAX has dramatically reduced processing time by a factor of
more than 60, from 10473 to 166 seconds.
I do not see any information about a -wm option on these web pages
http://www.gdal.org/gdal_utilities.html
http://www.gdal.org/gdal_translate.html
I would appreciate information about the -wm option. What is the
default value? Are the units MB of memory?
Greg
On Sep 11, 2009, at 11:42 AM, William Kyngesburye wrote:
Hmm, yes that one works for me. I simplified my example for the
email, maybe there's a memory problem, or raster size problem?
I originally tried to resample a GRASS raster DEM directly. It's
really 1000m cell size, 12809x18192 float cells, and want to
resample to 21000m and 7000m. That wasn't working so I exported to
Geotiff (Int16 cells) with r.out.gdal. The exported image has the
nulls as -32768. That doesn't work either.
... ah! memory! I just tried with -wm 250 and I get the nulls. And
the nasty artifacts. I think I want the nulls filled now ;) I saw
a bug about this on the tracker but it was fixed. Maybe this is a
different problem?
On Sep 10, 2009, at 5:56 PM, Even Rouault wrote:
Selon William Kyngesburye <[email protected]>:
I don't manage to reproduce your issue neither with trunk nor with
1.6.2 with a
indem.tif generated by the following python script :
import gdal
import osr
ds = gdal.GetDriverByName('GTiff').Create('indem.tif', 500, 500, 1,
gdal.GDT_Int16)
ds.SetGeoTransform([500000, 10, 0, 45000000, 0, -10])
sr = osr.SpatialReference()
sr.ImportFromEPSG(32631)
ds.SetProjection(sr.ExportToWkt())
ds.GetRasterBand(1).Fill(-32768)
ds.GetRasterBand(1).SetNoDataValue(-32768)
ones = ''
for i in range(50*50):
ones = ones + '\001\000'
ds.GetRasterBand(1).WriteRaster(225,225,50,50, ones, 25, 25)
ds = None
and
gdalwarp -tr 100 100 -ot Int16 -r lanczos -dstnodata -32768
indem.tif outdem.tif
You need to specify -dstnodata -32768. The result I get is as
expected a square
of ones at the middle of nodata values at -32768 (except that due
to a strange
behaviour of lanczos you get some artifacts at the edge of the
square).
Maybe I'm missing something? I'm trying to resample a DEM, with
null/
nodata values in oceans, using gdalwarp. No matter what options
I've
used so far, all the resampled nodata areas get filled with 0.
GDAL 1.6.2
So far I've tried (src res 10, nodata -32768 defined in src):
gdalwarp -tr 100 100 -ot Int16 -r lanczos indem.tif outdem.tif
gdalwarp -tr 100 100 -ot Int16 -r lanczos -dstnodata -32768
indem.tif
outdem.tif
gdalwarp -tr 100 100 -ot Int16 -r lanczos -dstalpha indem.tif
outdem.tif
The last time I used gdalwarp, with nulls, was back at 1.5.x, and it
worked then, though I was projecting data (-t_srs), instead of only
resampling. (I'd have to dig up an old 1.5 to see if it still
works)
-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/
"I ache, therefore I am. Or in my case - I am, therefore I ache."
- Marvin
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/
"History is an illusion caused by the passage of time, and time is
an illusion caused by the passage of history."
- Hitchhiker's Guide to the Galaxy
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
