On Aug 22, 2009, at 4:51 AM, Hermann Peifer wrote:
Just to repeat my earlier observations: over the last days, I tried
with all kinds of -wm and GDAL_CACHEMAX settings, and also added
the options TILED=YES and SKIP_NOSOURCE=YES. I haven't documented
the performance changes systematically, b
Selon Mateusz Loskot :
Actually, it would rather belong to
http://trac.osgeo.org/gdal/wiki/UserDocs/GdalWarp
> Adam Nowacki wrote:
> > Some rather counterintuitive gdalwarp behavior: the bigger
> > dfWarpMemoryLimit (-wm setting) the more cpu time will be wasted on
> > warping not existing pixels
Adam Nowacki wrote:
> Some rather counterintuitive gdalwarp behavior: the bigger
> dfWarpMemoryLimit (-wm setting) the more cpu time will be wasted on
> warping not existing pixels. Why? Warping begins with the destination
> window size of entire output image size. If this size is larger than
> dfW
Adam Nowacki wrote:
Some rather counterintuitive gdalwarp behavior: the bigger
dfWarpMemoryLimit (-wm setting) the more cpu time will be wasted on
warping not existing pixels. Why? Warping begins with the destination
window size of entire output image size. If this size is larger than
dfWarpMe
Some rather counterintuitive gdalwarp behavior: the bigger
dfWarpMemoryLimit (-wm setting) the more cpu time will be wasted on
warping not existing pixels. Why? Warping begins with the destination
window size of entire output image size. If this size is larger than
dfWarpMemoryLimit it is split
Frank Warmerdam wrote
Jukka Rahkonen wrote:
Conclusion: Too slow to be useful with my settings.
Question 1: Should it work this way?
Question 2: If yes, is it worth trying to find the limits when it goes
too slow
and perhaps file a ticket?
I hate to bring this up so late in the discussion,
