[GRASS-user] raster history logs

Glynn Clements glynn at gclements.plus.com
Sat Apr 19 23:10:41 EDT 2008


Nikos Alexandris wrote:

> > > Why isn't the raster history log (of any raster) similar with a vector's
> > > history log?
> > > 
> > > Whenever I create a subset of a map with r.mapcalc, its pre-r.mapcalc
> > > history is gone. Is it not a good idea to keep all actions logged?
> 
> Isn't there a possibility to keep single history lines instead of let
> them be replaced by simple r.mapcalc commands? (please read also below).

I have read below, and I'm not sure what you are asking for.

> > The problem is that a map created by r.mapcalc can based upon an
> > unlimited number of input maps. Also, actually identifying which maps
> > the output is based upon isn't straightforward. E.g. the defining
> > expression can use variables whose value depends upon some other map,
> > and identifying such dependencies could be quite complex.
> 
> Just some brainstorming:
> 
> * Is it a bad idea to save at least the command as given?
> 
> I mean a command like:
> 
> for i in `g.mlist rast par=SOMETHING`; do r.mapcalc X=SOMETHING
> 
> to be saved as is without actually "executing" the g.mlist command and
> see which maps have been really processed.

If you're asking for the "for i in ..." to be saved in the map's
history, that's impossible. A program only knows that it was executed
with specific arguments; it cannot determine what caused it to be
executed like that (e.g. what was entered into the shell).

> * And in case someone is entering manually all maps (without using
> wildcards): how many people will sit-down and create a complex r.mapcalc
> expression with more than 20 maps?

The issue isn't the number of input maps, but the correspondence
between input maps and output maps.

First, an r.mapcalc command can create any number of output maps. If
there are multiple input maps, not all of them may be used in the
construction of any given output map.

Second, an input map might not directly appear in the expression used
to generate the output map. Instead, it can be used to calculate an
expression which is stored in a variable, then the variable is used in
the expression which determines the output map.

E.g. in the expression:

	outmap1 = eval(v = inmap1 + inmap2)
	outmap2 = v * inmap3

The history for outmap2 will be "v * inmap3"; the information on how v
was constructed isn't available at the point that outmap2's history is
generated.

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


More information about the grass-user mailing list