[GRASS5] saving metadata

GRASS GRASS developer
1

Currently several modules, such as s.surf.rst and r.mapcalc write to the
hist meta-data file. This is good.

Unfortunatly running r.mapcalc or another processing module overwrites
instead of appends to the hist file, destroying possibly important
meta-data (such as s.surf.rst parameters).

I understand that the hist file code may need a bit of work, and it is a
mine-field of relevance, which hist to keep in event of a map
merge, etc., but that might be better than just throwing all the old
data away?

In lieu of modifying the hist library functions to allow append, a hack
might be to read in the hist file to memory, append the new string and
write the whole thing back?

better ideas?

thanks,
Hamish

2

On Sat, May 31, 2003 at 09:09:16PM +1200, H Bowman wrote:

Currently several modules, such as s.surf.rst and r.mapcalc write to the
hist meta-data file. This is good.

Unfortunatly running r.mapcalc or another processing module overwrites
instead of appends to the hist file, destroying possibly important
meta-data (such as s.surf.rst parameters).

I understand that the hist file code may need a bit of work, and it is a
mine-field of relevance, which hist to keep in event of a map
merge, etc., but that might be better than just throwing all the old
data away?

In lieu of modifying the hist library functions to allow append, a hack
might be to read in the hist file to memory, append the new string and
write the whole thing back?

better ideas?

Good idea! There should be a function to append text to the GRASS history
file. This function should be able to break long lines etc.

If such a function were available in GIS lib, we could use
G_recreate_command() to store cmd line paramters in the
history file (desired for r.sunmask, r.texture, ...).
Once I tried to write such function, but it is not complete,
(strings seem to be too complicated for me) :slight_smile:

Markus

3

H Bowman wrote:

Currently several modules, such as s.surf.rst and r.mapcalc write to the
hist meta-data file. This is good.

Unfortunatly running r.mapcalc or another processing module overwrites
instead of appends to the hist file, destroying possibly important
meta-data (such as s.surf.rst parameters).

r.mapcalc doesn't overwrite anything. It creates a new map, and fills
in its history with the expression which is used to create it. Any
maps which were used as input remain unchanged (including their
history).

Or are you suggesting that r.mapcalc should include the histories of
all of the input maps in the new map's history?

There is one special case: if the RHS is a single map, possibly with
an offset or modifier, the history is copied.

Now that I think of it, this is incorrect; the history shouldn't be
preserved if there is any offset or modifier, as it may contain
comments which are rendered untrue by the offset or modifier. No data
is better than incorrect data.

The handling of the categories and colour table is correct; these
aren't copied if a modifier is used, but an offset is allowed.

I understand that the hist file code may need a bit of work, and it is a
mine-field of relevance, which hist to keep in event of a map
merge, etc., but that might be better than just throwing all the old
data away?

Nothing is being thrown away; it just isn't being propagated. But I'm
not sure that it should be; is the "history" meant to be a "comments"
section (which is how it is currently used) or an audit trail?

If it's the latter, the data could become quite large; particularly
when using r.mapcalc to create one map from several maps, each of
which were created with r.mapcalc from several maps, etc.

In lieu of modifying the hist library functions to allow append, a hack
might be to read in the hist file to memory, append the new string and
write the whole thing back?

What happens when the combined history exceeds MAXEDLINES? If every
program propagates its inputs' histories, it will happen eventually.

--
Glynn Clements <glynn.clements@virgin.net>