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

GRASS GIS GRASS GIS developer
1

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@grass.itc.it
Cc: Patton, Eric; 'grassuser@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

2

Eric,

There's no point in trying to sort the inputs to r.patch. It'll only increase
the speed by a small amount (it'll take more than half as much as the maximum
time at best). It's pretty much guaranteed that the row skipping optimization
will never apply on mosaic problems anyway because almost every row will have
one null in it either from the input data, from slight gaps between input
patches, or the most common: gaps between the input patches and the edge of
the region.

I'd guess that r.patch is faster than mapcalc due to specialization. It could
easily be much faster to export the maps and use gdalwarp to compile them
together (assuming gdalwarp iterates over each input map seperately) and
re-import the result as Maciek suggested.

--Cedric

3

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).

If maps overlap at all, r.patch will use the values from the first map
listed as the value. So order matters.

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

why not just:

MAPS=`g.mlist pat="map_*" sep=,`
r.patch in=$MAPS out=patched_maps

or together

r.patch in="`g.mlist pat="map_*" sep=,`" out=patched_maps

note r.out.mpeg has wildcard code built-in for input maps.
Probably best not to go around adding this module by module.
Into G_parser() [multiple="YES"], if at all.

Hamish