[GRASS-user] r.mapcalc question

[Glynn Clements]

Christian Schwartze wrote:

> > I have a problem running a r.mapcalc procedure:
> >
> > given two maps
> > dir_x,
> > dir_y
> >
> > with 0,1,-1 entries
> >
> > I want to run:
> >
> > r.mapcalc "the_map=if(isnull(the_map),the_map[dir_x,dir_y],null())"
> >
> > in order to make a r.water.outlet on many many areas at the same time.
> >
> > The error I get is:
> > syntax error, unexpected NAME, expecting INTEGER or '-'
> >
> > why does dir_x/dir_y does not return an integer here? Using int(dir_x) 
> > also does not work.
> >
> > Until now I use a r.mapcalc command with many "if", checking the direction 
> > of every pixel every time. But this is quite slow.
> 
> dir_x and dir_y are maps, and as far as I know they can not use in map[x,y] 
> since it expects relative coordinates for the moving window...even though 
> your raster values are in [0,1,-1]

To elaborate: the parser only recognises integer literals for the
neighbourhood modifier.

Apart from that, allowing expressions would require knowing in advance
the range of the data, so that it knows how many rows need to be
cached.

> I've been searching for a while, but I cannot find any tool like grasss 
> r.mapcalc that is a bit more flexible, eg. that can handle recursive tasks.

For tasks such as this, the alternatives are either to use a
general-purpose language such as MatLab/Octave or Python+NumPy/SciPy
(which requires reading the entire map into memory), or write a GRASS
module in C/C++ (you could use the SWIG bindings to write a complete
module in Python, but it would be slow, and the bindings are rather
primitive at the moment).

The main problem with extending r.mapcalc is that it's a slippery
slope; the more features we add, the more features we'll be asked to
add and the harder it will be to add such features (as each new
feature has to consider interactions with all existing feature).

As it stands, r.mapcalc provides just enough "glue" (or possibly duct
tape) to connect other modules together. E.g. by allowing simple pre-
and post-processing of the data used or produced by other modules, it
saves us from needing to add many relatively simple special-purpose
modules as well as adding many features to many existing modules.

-- 
Glynn Clements <glynn at gclements.plus.com>