glynn.clements at virgin.net
Fri Nov 14 14:50:08 EST 2003
Thierry Laronde wrote:
> Well, you can put additionnal mapsets, via g.mapsets, but you can also
> create under your location (directory) symbolic links pointing to, for
> example, a nfs mounted tree, and add this symbolic link name to the file
> SEARCH_PATH (or via g.mapsets) meaning that one is not restricted to her
> own LOCATION or to the inside of the GRASS database.
> Yes, as Glynn says this _can_ be messy if people do this without knowing
> exactly what they do, but this is a mean, not more dirty than others if
> used with reflexion, to indeed "escape" GRASS database in order to
> access "remote" data.
> One can also use it (but I would not emphasize the possibility in the
> user's manual, but only in the admin's one) to see some MAPSETS of
> other LOCATIONS (for example to display a vector/raster overlay).
We probably shouldn't mention this anywhere. Maps in a different
location will typically have a completely different projection; the
only legitimate way to access maps from another location is via
OTOH, it seems reasonable to access non-geographic data (e.g. colour
tables, category labels, icons) from another location.
Ideally, I would like to remove all knownledge of the database
structure from the individual modules, concentrating it within libgis.
Modules wouldn't need to call G_find_file(), or even know what a
mapset was; they would just pass the map name directly to
That way, if someone comes up with a better idea for how to organise
the database, we only need to change libgis, not ~400 individual
Glynn Clements <glynn.clements at virgin.net>
More information about the grass-dev