Jukka Rahkonen wrote:
Gdalwarp has now been running for 27 hours. Process is taking 70 megabytes of
memory and 5-15 percent of processor time. As a result I have now output tiff
file that is very, very slowly growing in size. Now, after 27-hour run the
filesize is 13 gigabytes. Judged by the filesize my new tiff file might be ready
after 4-5 more days.  However, I am not sure if this estimate is reliable. The
gdalwarp status indicator is still showing just zero for me:
Processing input file gdalwarptest.vrt.
0

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?

Jukka,

I hate to bring this up so late in the discussion, but have you tried
-wo SKIP_NOSOURCE=YES?  When mosaicing small images into large images it
prevents processing of chunks for which there is no source data.  Otherwise
the whole output image is generated for each input image.

There is an open ticket on this issue to apply this option by default.

BTW, in combination with SKIP_NOSOURCE it can be helpful to keep the -wm
option to a modest size to the tiles aren't too large.  A 200MB should be
sufficient - especially if the input and output image are tiled.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmer...@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent

_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Reply via email to