[GRASS-user] r.patch for stitching rasters?

[Hamish]

Boris:
> I am using r.patch to merge 200 1 degree, 3 seconds resolution srtm's
> (1-2 Mb each). After 24 hours of real time and 20 hours of Xeon
> processor time I have 39% completed! My guess that this task shouldn't
> take so long. Is r.patch a wrong tool to do this thing? Or is it a
> bug? I am using grass-6.3.cvs.

Dylan:
> g.region -p ?

Boris:
> rows:       13200
> cols:       24000
> cells:      316800000

Dylan:
> That is pretty big, but not impossibly big. Have you considered
> something like gdal_merge.py for merging the files outside of GRASS ?

splitting that into four or eight smaller tiles would make it more manageable,
but as Dylan says that isn't impossibly big, perhaps even on the high side
of common. For really huge regions (> 50000^2) you might start thinking about
using 64bit processors and if GRASS and the OS were compiled with large file
support.

Given the number of maps and size of the region, I'm not surprised it
could take x*y*maps times longer than normal.

Boris:
> since I was trying to preserve resolution of original srtms.

hint 1: use g.region with multiple maps to set the region to the outer
bounds of all maps. For you with so many maps that could take a while,
so probably maps at the four corners would be enough.
  g.region rast=map1,map2,map3,map4

hint 2: a low number of columns can be more important to speed than low
number of rows when doing things like displaying maps.


suggestion: wait 48 hours for it to finish then see if it is too big
to work with before deciding to split it up into smaller tiles.
Also it could be a lot faster to make 4 or 8 smaller tiles then r.patch
those together in a second pass. (ie reduce the module's search time
through known empty space)


Hamish



      ____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs