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

[Eric G. Miller]

On Mon, Feb 18, 2002 at 05:30:33AM +0000, Glynn Clements wrote:
[snip]
> > 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?

> 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).

> 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.

> 3. I'm thinking in terms of a "map directory" being completely self
> contained, so it would basically correspond to a "document". Such
> directories could exist anywhere, in the same way that most
> applications can access data files in any directory, with the
> possibility of specifying a map using an absolute path.

This is where I'll have to diverge.  I strongly believe we'd get
better long term flexibility by moving to more of a geo-relational
database.  I am biased, since I'm somewhat more focused toward
data development and management, and I don't particularly like
loosely coupled systems (like the DBMI stuff), as it is too
fragile (not the code, the data).  I also don't care for spagetti vector
formats as they somewhat limit modelling capabilities and can be a real
pain for long term maintainence.

My pipe-dream is to have a fully integrated, topological geo-relational
database management system, with a nice set of query and analysis
functions.  Cartographic capabilities can be provided via a front
end.  But perhaps GRASS is not the right vehicle for this pipe-dream.

The idea of a "document" does play well with the relational concept of
a "view" (or actually, a set of views) and would be a natural way to
define a "map" comprised of several data sources.  Anyway...

> 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? 

[snip]
> 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.

-- 
Eric G. Miller <egm2 at jps.net>