[GRASS-dev] More efficient to use r.mapcalc or r.patch in a l oop for creating mosaics?

[Patton, Eric]

Cedric,

Thanks for the reply. What if the maps aren't fed to r.patch in order of
rows/columns, but in some random order with respect to the entire region
(like alphabetical order, for instance). Here's a snippet from my script,
for example:


declare -a PATCHLIST

i=0
for MAP in `g.mlist type=rast pattern=$INPUT` ; do

	PATCHLIST[${i}]=${MAP}
	i=$((${i} + 1))
done

where the $INPUT is some wildcard search pattern such as "Map44?6_*". So the
extents of the maps as read from the array will likely be somewhat
haphazard. Should I try some way of ordering the maps first, say from west
to east, north-south, and save that ordered set in a new array for optimal
input to r.patch?

~ Eric.
 

-----Original Message-----
From: Cedric Shock
To: grass-dev at grass.itc.it
Cc: Patton, Eric; 'grassuser at grass.itc.it'
Sent: 5/11/2006 2:23 PM
Subject: Re: [GRASS-dev] More efficient to use r.mapcalc or r.patch in a
loop for creating mosaics?



r.patch is more specialized and easier to use. It includes only one
speed 
optimization (besides being written for the job): it stops patching a
row 
once the whole row has been filled. This only really helps if your tiles

exactly cover the current region and are in row-major order, and even
then it 
only cuts the running time in half. The running time of r.patch goes
like 
columns (of current region) * rows * number of patches. I think one
could get 
r.mapcalc or r.patch to run in columns * rows * log (patches) with some 
clever manipulation of the region and how the patching is done. It
should 
really run like columns * rows * (average patch pixels per pixel).

Speaking of regions, both r.patch and r.mapcalc will generate an output
map 
that covers the current region at the current resolution, so both the
bounds 
of the region and the resolution must be correct before running these 
programs.

--Cedric