[GRASS5] raster file history question

[Helena Mitasova]

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 at grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass5