I'm unable to find where I have read that one desired feature would be
in the future to be able to access files spread all around, possibly
read only, and to not have the obligation to recopy the data in the
current MAPSET.
Isn't SEARCH_PATH exactly already defined for that? Since, from progman
(4.1) files are searched using the path specified here, but new files
are only written in the current MAPSET all the features are already here
Users need only to set some symbolic links (on OSes supporting this) in
the location pointing to other repositories and list them in
SEARCH_PATH.
Just for the record.
--
Thierry Laronde (Alceste) <tlaronde@polynum.org>
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
I'm unable to find where I have read that one desired feature would be
in the future to be able to access files spread all around, possibly
read only, and to not have the obligation to recopy the data in the
current MAPSET.
Isn't SEARCH_PATH exactly already defined for that? Since, from progman
(4.1) files are searched using the path specified here, but new files
are only written in the current MAPSET all the features are already here
Users need only to set some symbolic links (on OSes supporting this) in
the location pointing to other repositories and list them in
SEARCH_PATH.
Well, ideally the user shouldn't have to be fiddling around with the
internals of the database directory or making symlinks.
I'm unable to find where I have read that one desired feature would be
in the future to be able to access files spread all around, possibly
read only, and to not have the obligation to recopy the data in the
current MAPSET.
Do you mean:
d.rast rastmap@othermapset
or
d.sites sitefile@PERMANENT
?
see also:
g.mapsets --help
g.mapsets -p
g.mapsets addmapset= ....
addmapset Name(s) of existing mapset(s) to add to search list
On Fri, Nov 14, 2003 at 01:49:55AM +0000, Glynn Clements wrote:
>
> Users need only to set some symbolic links (on OSes supporting this) in
> the location pointing to other repositories and list them in
> SEARCH_PATH.
Well, ideally the user shouldn't have to be fiddling around with the
internals of the database directory or making symlinks.
Hamish wrote:
Do you mean:
d.rast rastmap@othermapset
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).
--
Thierry Laronde (Alceste) <tlaronde@polynum.org>
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
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.
On Fri, Nov 14, 2003 at 07:50:08PM +0000, Glynn Clements wrote:
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.
Short answer: yes.
Long answer: what I'm doing at the moment is clearing...GRASS 4.1.5
and looking closely to see all the hooks and all the half-ways,
weaknesses to get this overview that I'm after.
And FWIW, I will publish statistics about the cleaning I have made
(first pass already done resulting in 459 files/directories removed
in a regular basis i.e. via a Makefile piloting common deletions
and reading one file for "custom" cleaning with explanations)