[GRASSLIST:3161] Re: [GRASS5] Re: Grass GUI

[Glynn Clements]

Eric G. Miller wrote:

> > > Such a layout would be similar to an Arc/Info workspace, 'cept we
> > > don't have an "info" directory.  I still prefer the idea that
> > > all the data sets in a LOCATION are in the same coordinate
> > > system.
> > 
> > I agree, in the sense that it should be possible to check if one map
> > is in the same "location" as another (or as the "current" location)
> > without having to compare all of the various parameters (ellipse,
> > datum, projection, zone etc).
> > 
> > However, that doesn't necessarily mean that a location has to be
> > implemented as a common parent directory.
> 
> Not using a common parent directory would require some other
> reliable place to store what defines a "location" and where
> it's constituents live.  A way to do this would be to have
> a per-user (and possibly as well system-wide) ~/.grass
> directory.  Somewhere in there would be a "database" of
> locations w/ aliases, each location containing defining
> parameters and members (with their actual location and
> an alias).  Perhaps you have some other idea how to do this?

No, that's basically what I was thinking of, at least for per-user
locations.

System-wide locations are more complex. The main issue is whether
anyone can create a location, or if it is a "privileged" operation. Or
whether you have some kind of structure, so each user owns part of the
location name space.

> > 1. I'd like to do away with the $GISDBASE concept altogether. It
> > doesn't sit at all well with typical access control mechanisms. Of
> > course, a more general mechanism wouldn't prohibit collecting all of
> > the data under a common "root" directory, if that was desired.
> 
> Well a GISDBASE is nothing more than a directory containing locations,
> which are directories containing mapsets, one of which must be
> PERMANENT/.  Only the "location" concept really has a functional
> benefit (at least to my mind).

Sure. Although even that needn't be as significant as it currently is
(in the sense that each location is almost a completely separate
database, with only the *.proj commands linking them). I've been
thinking about what would be involved in allowing maps to be read from
arbitrary locations, effectively performing a *.proj operation
transparently.

> > 2. I don't really see any advantage to imposing the
> > vector/raster/sites level.
> 
> Only one I can think of, can use same names for objects representing
> the same thing, but in different format.

Right. I can see some advantage there, although I'm not sure whether
it's sufficient to warrant imposing that structure on the user.

The main advantage which I see in self-contained map directories is
that the user then has complete freedom as to how they organise them
within the filesystem.

> > There would also need to be some $PATH-like mechanism, so that the
> > user isn't forced to use absolute paths. Basically, something which
> > enables the use of the current layout, but without *requiring* any
> > particular layout.
> 
> Aliases? 

Well, that's a fairly broad term. You can simulate the "map at mapset"
scheme with shell variables, i.e. "$mapset/map" (although it may well
be preferable to build in something which uses the existing syntax). 
OTOH, a "path" system effectively "merges" multiple name spaces. This
would also allow the user to implement the vector/raster/sites thing
if it wasn't built in.

> > I suspect that you can get a lot more radical than that without having
> > to change too much code (i.e. you might need to change libgis, but not
> > the applications).
> > 
> > AFAICT, the only thing that would be hard (and probably undesirable)
> > to change is the requirement that the components (cellhd, cell, colr
> > etc) are separate files. Code which contains assumptions about
> > relative locations (other than libgis itself) should probably be fixed
> > anyway (with new functions added to libgis if necessary).
> 
> Well, you'd have to implement some real trickery into the file lookup
> code to not break alot of modules.  This idea of mapset components
> being directories is written write into the programming manual, and
> there's even discussion about defining new components.

AFAICT, most of that *should* be encapsulated within G__file_name(). 
Obviously there will be the odd valid exception, but a typical
read/process/write program shouldn't need to know anything about the
internal data organisation.

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