[GRASS5] Raster files suggestion: new directory layout

[Paul Kelly]

Hello Hamish

Hamish wrote:
> 
> > > > > - user can easily copy a map into another machine
> > > > >   (say, for backup reasons or whatever)
> > > >
> > > > For a quick way of copying maps now try: r.out.mat, copy the map file
> > > > to a new machine, then use r.in.mat. I guess you could do GeoTIFF or
> > > > something else as well, but this is quick and easy. Things like the
> > > > cats/, colr/, and hist/ files don't get included (yet).
> > >
> > > This is exactly missing. When I have to backup or to copy the map
> > > to a friend's computer, I need the full copy. Currently the only
> > > way is to use 'find' or manual file selection.
> >
> > Well writing an import/export module that included all the components of
> > the raster would be a lot less trouble than changing the file structure
> > IMHO... (and easier to explain to less experienced users how to use it).
> 
> This probably needs a bit more debugging, but....
> 

This is just like what I had in mind also.

A suggestion:
Perhaps pipe tar output/input to/from gzip to allow for non-GNU tars:

tar cf - * | gzip -fc > "$OLD_DIR"/"$GIS_OPT_input".pack
etc. ...

Two locations may have the same projection but totally different
PROJ_INFOs (e.g. UTm can be described by proj=utm, zone=xx etc. or
proj=tmerc, k_0=0.9996 and other parameters etc. and I feel it is not
really feasible to compare two projections. G_compare_projections() in
src/libes/gis/make_loc.c makes a stab at it though (but I don't like
what it does ;) )

Maybe the suffix for the pack file should have 3 letters to look
conventional? gpk for GRASS pack or something?

Also I have often wondered do we really need to say
exec $GISBASE/etc/bin/cmd/g.parser
and not just
exec g.parser
?

Paul