[GRASS5] SEARCH_PATH

[Glynn Clements]

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
[rsv].proj.

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
G_open_cell_old() etc.

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

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