[GRASS-user] raster history logs

[Nikos Alexandris]

On Sat, 2008-04-19 at 05:00 +0100, Glynn Clements wrote:
> 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).
> 
> 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.

Of course, a renaming of the source maps would cause confusions. Yet, it
is a starting point to remember where from did a "processed with
r.mapcalc" map came.

* 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?

* Or why not set a threshold like:

if the number of maps processed is greater than X then use the command
as is (see above) otherwise use all map names in the map's history log.


> For modules which perform a straightforward transformation of a single
> input map, it wouldn't be particularly hard to include the history of
> the original input map.

Would be nice to have.
> 
> There's still the issue that the history is limited to 50 lines, so
> complex sequences of commands will eventually result in the earlier
> history getting lost.