Just wanted to keep exact track of the processing leading to a new layer.
1 - would it be feasible to store the whole processing line with
parameters (i.e. r.something -a input=file_in output-file_out etc...)
as metadata in the output file of a module ?
2 - would it be interesting to make a scripts/ place inside a mapset
where scripts would get automatically saved with something like:
YYYYMMMDDHHHHH_MODULE_NAME.sh or the like?
Just wanted to keep exact track of the processing leading to a new layer.
1 - would it be feasible to store the whole processing line with
parameters (i.e. r.something -a input=file_in output-file_out etc...)
as metadata in the output file of a module ?
G_command_history() already does this, i.e. it appends the result of
G_recreate_command() to the history.
2 - would it be interesting to make a scripts/ place inside a mapset
where scripts would get automatically saved with something like:
YYYYMMMDDHHHHH_MODULE_NAME.sh or the like?
I'm not sure what you're suggesting here.
GRASS (the libraries and modules) only knows which commands are run;
it doesn't know *how* they are run, e.g. if they are part a script, if
they were typed into the shell, executed by the GUI, etc.
Just wanted to keep exact track of the processing leading to a new layer.
1 - would it be feasible to store the whole processing line with
parameters (i.e. r.something -a input=file_in output-file_out etc...)
as metadata in the output file of a module ?
G_command_history() already does this, i.e. it appends the result of
G_recreate_command() to the history.
G_recreate_command()
OK I'll look into it.
2 - would it be interesting to make a scripts/ place inside a mapset
where scripts would get automatically saved with something like:
YYYYMMMDDHHHHH_MODULE_NAME.sh or the like?
I'm not sure what you're suggesting here.
GRASS (the libraries and modules) only knows which commands are run;
it doesn't know *how* they are run, e.g. if they are part a script, if
they were typed into the shell, executed by the GUI, etc.
well, since G_recreate_command passed it into the metadata,
I guess already that is good.
I was thinking more of a kind of "command log", but with time-based
separation of commands used in txt files.
Whether they are stored inside a mapset would just be convenient.
well, since G_recreate_command passed it into the metadata,
I guess already that is good.
I was thinking more of a kind of "command log",
but with time-based
separation of commands used in txt files.
Whether they are stored inside a mapset would just be
convenient.
see also 'v.info -h <mapname>' for some developed <mapname> which is the result of a number of vector module processing steps.
and the raster-metadata rewrite task suggestion box on the grass wiki grass7 ideas page.