Hi,
for a few modules I would like to add the feature that
the invoking command lines is stored into the raster file history.
It will be trivial, but I don't get the command line into
a string.
Thanks!
Markus
On Wed, Apr 03, 2002 at 06:29:37PM +0200, Markus Neteler wrote:
for a few modules I would like to add the feature that
the invoking command lines is stored into the raster file history.It will be trivial, but I don't get the command line into
a string.
Maybe it is just me, but I don't understand the question.
--
Professional Service for Free Software (intevation.net)
The FreeGIS Project (freegis.org)
Association for a Free Informational Infrastructure (ffii.org)
FSF Europe (fsfeurope.org)
On Thu, 4 Apr 2002, Bernhard Reiter wrote:
On Wed, Apr 03, 2002 at 06:29:37PM +0200, Markus Neteler wrote:
> for a few modules I would like to add the feature that
> the invoking command lines is stored into the raster file history.
>
> It will be trivial, but I don't get the command line into
> a string.Maybe it is just me, but I don't understand the question.
I think Markus has something here, but I agree it could be clearer. Is
what you were thinking of a kind of audit trail, so that one could trace
which commands had led to a given map object being in its current state in
the location? Something like appending the verbatim command line (plus the
working directory address etc.) to a file somewhere. To do that, one could
either use a daemon mechanism to harvest change data during a session, or
insert an extra function in gisinit.c or similar to grab the command line
for command line programs, or line some other way of inserting such a
function after arguments have been set interactively (more
cumbersome). I think it becomes top-heavy when the output inherits
histories from multiple parents.
Roger
--
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Breiviksveien 40, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 93 93
e-mail: Roger.Bivand@nhh.no
and: Department of Geography and Regional Development, University of
Gdansk, al. Mar. J. Pilsudskiego 46, PL-81 378 Gdynia, Poland.
On Thu, Apr 04, 2002 at 12:32:19PM +0200, Bernhard Reiter wrote:
On Wed, Apr 03, 2002 at 06:29:37PM +0200, Markus Neteler wrote:
> for a few modules I would like to add the feature that
> the invoking command lines is stored into the raster file history.
>
> It will be trivial, but I don't get the command line into
> a string.Maybe it is just me, but I don't understand the question.
Ok, sorry for boing unclear. A new try:
I want to store the command line, which was used to start a
module, into the history section of data.
Example: I run
r.proj dgm1km loc=europa map=europa
When I now run
r.info dgm1km
the string "r.proj dgm1km loc=europa map=europa" should appear in
the history. This is implemented in r.slope.aspect and s.surf.rst,
but more complicated there. For my module (not r.proj) the command line
string is sufficient to later remember the parameters which I used to
generate that particular map.
It must be something with argv or so.
Thanks,
Markus
Markus,
I think what you are talking about is writing to the History structure
of the raster. Only a few programs implement this. Most other programs
simply pick up the history from a previous raster.
As a code example you could look at i.rectify (exec.c). Here the History
structure is initialized and command parameters (and other useful info)
is written out.
What we need to do is identify the programs that would be most useful to
have the history written.
Hope this helps.
Markus Neteler wrote:
On Thu, Apr 04, 2002 at 12:32:19PM +0200, Bernhard Reiter wrote:
> On Wed, Apr 03, 2002 at 06:29:37PM +0200, Markus Neteler wrote:
> > for a few modules I would like to add the feature that
> > the invoking command lines is stored into the raster file history.
> >
> > It will be trivial, but I don't get the command line into
> > a string.
>
> Maybe it is just me, but I don't understand the question.Ok, sorry for boing unclear. A new try:
I want to store the command line, which was used to start a
module, into the history section of data.Example: I run
r.proj dgm1km loc=europa map=europa
When I now runr.info dgm1km
the string "r.proj dgm1km loc=europa map=europa" should appear in
the history. This is implemented in r.slope.aspect and s.surf.rst,
but more complicated there. For my module (not r.proj) the command line
string is sufficient to later remember the parameters which I used to
generate that particular map.It must be something with argv or so.
Thanks,
Markus
_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5
--
Bob Covill
Tekmap Consulting
P.O. Box 2016 Fall River, N.S.
B2T 1K6
Canada
E-Mail: bcovill@tekmap.ns.ca
Phone: 902-860-1496
Fax: 902-860-1498
Hi,
Markus Neteler wrote:
Ok, sorry for boing unclear. A new try:
I want to store the command line, which was used to start a
module, into the history section of data.Example: I run
r.proj dgm1km loc=europa map=europa
When I now runr.info dgm1km
the string "r.proj dgm1km loc=europa map=europa" should appear in
the history. This is implemented in r.slope.aspect and s.surf.rst,
but more complicated there. For my module (not r.proj) the command line
string is sufficient to later remember the parameters which I used to
generate that particular map.It must be something with argv or so.
what about G_recreate_command()? IMHO this gives a complete command
line, even if the command was invoked interactively.
I think that a own library for accessing and creating metadata (history
data) would be very useful. Somehow the metadata capabilites should be
unified for all modules (raster, vector, sites).
HTH,
Andreas
--
Andreas Lange, 65187 Wiesbaden, Germany, Tel. +49 611 807850
url: http://mitglied.lycos.de/AndreasLange
mail: Andreas.Lange_at_Rhein-Main.de - A.C.Lange_at_GMX.net
On Thu, Apr 04, 2002 at 02:10:48PM +0200, Markus Neteler wrote:
On Thu, Apr 04, 2002 at 12:32:19PM +0200, Bernhard Reiter wrote:
> On Wed, Apr 03, 2002 at 06:29:37PM +0200, Markus Neteler wrote:
> > for a few modules I would like to add the feature that
> > the invoking command lines is stored into the raster file history.
> >
> > It will be trivial, but I don't get the command line into
> > a string.
>
> Maybe it is just me, but I don't understand the question.Ok, sorry for boing unclear. A new try:
I want to store the command line, which was used to start a
module, into the history section of data.Example: I run
r.proj dgm1km loc=europa map=europa
When I now runr.info dgm1km
the string "r.proj dgm1km loc=europa map=europa" should appear in
the history. This is implemented in r.slope.aspect and s.surf.rst,
but more complicated there. For my module (not r.proj) the command line
string is sufficient to later remember the parameters which I used to
generate that particular map.It must be something with argv or so.
The developer's guide says programs need not be concerned about the
history file. Also, says the history mechanism is in need of an
overhaul. On quick inspection of the struct, all I can say is there'd
be no easy way to just append a line to an existing history. You'd
have to go through each line looking for an opening. Also, it's
possible a command would be longer than RECORD_LEN, so would need to
be split across lines.
--
Eric G. Miller <egm2@jps.net>
On Thu, Apr 04, 2002 at 07:27:13AM -0800, Eric G. Miller wrote:
On Thu, Apr 04, 2002 at 02:10:48PM +0200, Markus Neteler wrote:
> On Thu, Apr 04, 2002 at 12:32:19PM +0200, Bernhard Reiter wrote:
> > On Wed, Apr 03, 2002 at 06:29:37PM +0200, Markus Neteler wrote:
> > > for a few modules I would like to add the feature that
> > > the invoking command lines is stored into the raster file history.
> > >
> > > It will be trivial, but I don't get the command line into
> > > a string.
> >
> > Maybe it is just me, but I don't understand the question.
>
> Ok, sorry for boing unclear. A new try:
>
> I want to store the command line, which was used to start a
> module, into the history section of data.
>
> Example: I run
>
> r.proj dgm1km loc=europa map=europa
> When I now run
>
> r.info dgm1km
>
> the string "r.proj dgm1km loc=europa map=europa" should appear in
> the history. This is implemented in r.slope.aspect and s.surf.rst,
> but more complicated there. For my module (not r.proj) the command line
> string is sufficient to later remember the parameters which I used to
> generate that particular map.
>
> It must be something with argv or so.The developer's guide says programs need not be concerned about the
history file. Also, says the history mechanism is in need of an
overhaul. On quick inspection of the struct, all I can say is there'd
be no easy way to just append a line to an existing history. You'd
have to go through each line looking for an opening. Also, it's
possible a command would be longer than RECORD_LEN, so would need to
be split across lines.
... all this code I have already written. I only don't know how to
catch the command line. It must be possible as the parser does the
same (catching the command line).
I know that the history mechanism is poor, but for some reason I
have to store the CMD line along with the data.
Thanks,
Markus
On Thu, Apr 04, 2002 at 05:54:39PM +0200, Markus Neteler wrote:
> > the string "r.proj dgm1km loc=europa map=europa" should appear in
> > the history. This is implemented in r.slope.aspect and s.surf.rst,
> > but more complicated there. For my module (not r.proj) the command line
> > string is sufficient to later remember the parameters which I used to
> > generate that particular map.
> >
> > It must be something with argv or so.
You should be able to use the infos in argv and arc
to reconstruct parts of the command line.
You do not get the information about redirected file pointers,
because this is done by the shell.
e.g. cat - <parafile
argv[0] should have the programm executed.
argv will contain the arguments.
http://www.cs.cf.ac.uk/Dave/C/section2_22_4.html#SECTION00224000000000000000
... all this code I have already written. I only don't know how to
catch the command line. It must be possible as the parser does the
same (catching the command line).
--
Professional Service for Free Software (intevation.net)
The FreeGIS Project (freegis.org)
Association for a Free Informational Infrastructure (ffii.org)
FSF Europe (fsfeurope.org)
On Thu, Apr 04, 2002 at 03:49:08PM +0200, Andreas Lange wrote:
Hi,
Markus Neteler wrote:
> Ok, sorry for boing unclear. A new try:
>
> I want to store the command line, which was used to start a
> module, into the history section of data.
>
> Example: I run
>
> r.proj dgm1km loc=europa map=europa
> When I now run
>
> r.info dgm1km
>
> the string "r.proj dgm1km loc=europa map=europa" should appear in
> the history. This is implemented in r.slope.aspect and s.surf.rst,
> but more complicated there. For my module (not r.proj) the command line
> string is sufficient to later remember the parameters which I used to
> generate that particular map.
>
> It must be something with argv or so.what about G_recreate_command()? IMHO this gives a complete command
line, even if the command was invoked interactively.
yes - this will be the command I was looking for. Thanks for the pointer.
I think that a own library for accessing and creating metadata (history
data) would be very useful. Somehow the metadata capabilites should be
unified for all modules (raster, vector, sites).
Oh yes - that's really needed! On FreeGIS mailing list is currently some
discussion about that, see
http://intevation.de/pipermail/freegis-list/
However, even a simple solution might be better than what's currently
implemented. At least the data import modules should take more care about
that (eventually optionally ask the user about data source, year etc).
Markus
In the US many government agencies must include a standard and very detailed
metadata file with the data that they distribute. It would be extremely useful
if this file was imported
along with the data and either stored in the description part of history file
(r.info might need modification then)
or as a separate file, along with history file. As far as I know there is free
code supporting
the management of this file, in case that something more than just copying the
file to the GRASS
database would be considered.
Frank do you use or consider this file in GDAL?
Helena
Markus Neteler wrote:
On Thu, Apr 04, 2002 at 03:49:08PM +0200, Andreas Lange wrote:
> Hi,
>
> Markus Neteler wrote:
> > Ok, sorry for boing unclear. A new try:
> >
> > I want to store the command line, which was used to start a
> > module, into the history section of data.
> >
> > Example: I run
> >
> > r.proj dgm1km loc=europa map=europa
> > When I now run
> >
> > r.info dgm1km
> >
> > the string "r.proj dgm1km loc=europa map=europa" should appear in
> > the history. This is implemented in r.slope.aspect and s.surf.rst,
> > but more complicated there. For my module (not r.proj) the command line
> > string is sufficient to later remember the parameters which I used to
> > generate that particular map.
> >
> > It must be something with argv or so.
>
> what about G_recreate_command()? IMHO this gives a complete command
> line, even if the command was invoked interactively.yes - this will be the command I was looking for. Thanks for the pointer.
> I think that a own library for accessing and creating metadata (history
> data) would be very useful. Somehow the metadata capabilites should be
> unified for all modules (raster, vector, sites).Oh yes - that's really needed! On FreeGIS mailing list is currently some
discussion about that, see
http://intevation.de/pipermail/freegis-list/However, even a simple solution might be better than what's currently
implemented. At least the data import modules should take more care about
that (eventually optionally ask the user about data source, year etc).Markus
_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5
Just a followup:
Did anyone ever try
src/scripts/contrib/metadata
r.meta
v.meta
?
Markus
On Thu, Apr 04, 2002 at 01:52:57PM -0500, Helena Mitasova wrote:
In the US many government agencies must include a standard and very detailed
metadata file with the data that they distribute. It would be extremely useful
if this file was imported
along with the data and either stored in the description part of history file
(r.info might need modification then)
or as a separate file, along with history file. As far as I know there is free
code supporting
the management of this file, in case that something more than just copying the
file to the GRASS
database would be considered.Frank do you use or consider this file in GDAL?
Helena
Markus Neteler wrote:
> On Thu, Apr 04, 2002 at 03:49:08PM +0200, Andreas Lange wrote:
> > Hi,
> >
> > Markus Neteler wrote:
> > > Ok, sorry for boing unclear. A new try:
> > >
> > > I want to store the command line, which was used to start a
> > > module, into the history section of data.
> > >
> > > Example: I run
> > >
> > > r.proj dgm1km loc=europa map=europa
> > > When I now run
> > >
> > > r.info dgm1km
> > >
> > > the string "r.proj dgm1km loc=europa map=europa" should appear in
> > > the history. This is implemented in r.slope.aspect and s.surf.rst,
> > > but more complicated there. For my module (not r.proj) the command line
> > > string is sufficient to later remember the parameters which I used to
> > > generate that particular map.
> > >
> > > It must be something with argv or so.
> >
> > what about G_recreate_command()? IMHO this gives a complete command
> > line, even if the command was invoked interactively.
>
> yes - this will be the command I was looking for. Thanks for the pointer.
>
> > I think that a own library for accessing and creating metadata (history
> > data) would be very useful. Somehow the metadata capabilites should be
> > unified for all modules (raster, vector, sites).
>
> Oh yes - that's really needed! On FreeGIS mailing list is currently some
> discussion about that, see
> http://intevation.de/pipermail/freegis-list/
>
> However, even a simple solution might be better than what's currently
> implemented. At least the data import modules should take more care about
> that (eventually optionally ask the user about data source, year etc).
>
> Markus
> _______________________________________________
> grass5 mailing list
> grass5@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass5_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5
Helena Mitasova wrote:
In the US many government agencies must include a standard and very detailed
metadata file with the data that they distribute. It would be extremely useful
if this file was imported
along with the data and either stored in the description part of history file
(r.info might need modification then)
or as a separate file, along with history file. As far as I know there is free
code supporting
the management of this file, in case that something more than just copying the
file to the GRASS
database would be considered.Frank do you use or consider this file in GDAL?
Helena,
I have a mechanism in GDAL for transporting "metadata", but it isn't
specifically targetted to FDGC or any other standard format. It is mostly
used for adhoc name/value pairs of extra information about a dataset.
Note that even this limited form of metadata is not currently imported by
r.in.gdal. If GRASS had a standard location and API for accessing generic
metadata documents I would be interested in populating it from GDAL metadata
where available.
Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent
On Thu, Apr 04, 2002 at 01:52:57PM -0500, Helena Mitasova wrote:
In the US many government agencies must include a standard and very detailed
metadata file with the data that they distribute. It would be extremely useful
if this file was imported
along with the data and either stored in the description part of history file
(r.info might need modification then)
or as a separate file, along with history file. As far as I know there is free
code supporting
the management of this file, in case that something more than just copying the
file to the GRASS
database would be considered.
USGS has a free set of FGDC metadata tools. Most of the validation and
output tools are command line, but there's an editor either using Tk or
Athena widgets.
GRASS could help by generating some required "fields", but the majority
of it is really the user's responsibility to maintain.
There is some broken handling for doing FGDC metadata in GRASS, but I
think it'd be more appropriate just to generate a stub of those things
GRASS can fill in, and leave it to the user to figure out the rest.
What Markus has been talking about, would maybe be appropriate for the
Processing Steps section, but would still probably be too obtuse without
explication by the metadata author.
A generic log history is maybe more appropriate?
--
Eric G. Miller <egm2@jps.net>
"Eric G. Miller" wrote:
On Thu, Apr 04, 2002 at 01:52:57PM -0500, Helena Mitasova wrote:
> In the US many government agencies must include a standard and very detailed
> metadata file with the data that they distribute. It would be extremely useful
> if this file was imported
> along with the data and either stored in the description part of history file
> (r.info might need modification then)
> or as a separate file, along with history file. As far as I know there is free
> code supporting
> the management of this file, in case that something more than just copying the
> file to the GRASS
> database would be considered.USGS has a free set of FGDC metadata tools. Most of the validation and
output tools are command line, but there's an editor either using Tk or
Athena widgets.GRASS could help by generating some required "fields", but the majority
of it is really the user's responsibility to maintain.There is some broken handling for doing FGDC metadata in GRASS, but I
think it'd be more appropriate just to generate a stub of those things
GRASS can fill in, and leave it to the user to figure out the rest.What Markus has been talking about, would maybe be appropriate for the
Processing Steps section, but would still probably be too obtuse without
explication by the metadata author.A generic log history is maybe more appropriate?
A think that what Markus had in mind is more related to generic log history.
I was talking about something different and relatively simple - all I had in mind
refered to import of files and simply copying the metadata text file (if there is
any)
to an appropriate place in the GRASS data base, e.g. "attaching" it to
history file as a description section or keeping it separate under cell_misc (for
rasters).
Then there could be a command r.meta which will just read the file smilarly as
r.info. There is
nothing else that one would need to do with it, unless we would want to make it
sophisticated and copy it to each file which is derived from the imported file -
but that could lead to many complicated situations.
Helena
--
Eric G. Miller <egm2@jps.net>
_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5