[GRASS5] maps with identical name in different mapsets

[Markus Neteler]

On Wed, Mar 13, 2002 at 11:33:17AM +0000, Glynn Clements wrote:
> 
> Markus Neteler wrote:
> 
> > > > Maybe I am missing something, but we cannot be sure which map
> > > > is picked up when a map name exists several times (at least it
> > > > is not obvious to the user).
> > > 
> > > Well, it should also be explained right at the very beginning of any
> > > user guide or tutorial. And if a user can't grasp this concept, I'm
> > > not sure that they are going be able to grasp the other concepts
> > > involved.
> > 
> > Mhhh. Ok - an example.
> > 
> > We have these mapsets activated with g.mapsets:
> > 
> > neteler PERMANENT dtm belluno
> > 
> > There may be a file 'dtm10' both in 'dtm' and 'belluno'. The user
> > may have already forgotten that it exists twice. When using d.rast,
> > is the mapset search path searched 1. own, 2. PERMANENT, 3. alphabetically?
> > If yes, will the user remember that the map exists twice (I am sure that
> > he/she won't remember). 
> 
> > Addition: In our project location here we have around 5000 maps
> > in 76 mapsets, 8 people are adding maps daily. Like that I would have to
> > always run g.list to verify that I pick the right map, perhaps a
> > colleage had added a map with same name yesterday in a mapset which is
> > in my current mapset search path ....
> > 
> > So this problem exists mostly for work-groups.
> > 
> > Hope I could illustrate the problem a bit better now.
> 
> Basically, you get what you ask for. If you have 76 mapsets in your
> search path, and GRASS were to implement "collision avoidance", I
> would expect that commands would frequently fail because the name you
> chose existed elsewhere.

Even that does not work (at least for r.proj). If I have a map
'dtm10' in a mapset which is in search path, r.proj happily generates
'dtm10' in the current mapset without notifying that dtm10 already
exists in another mapset (while g.copy complains and stops).

At least we should have identical behaviour for all modules.

> This is a minor nuisance if you're running
> commands interactively, and potentially a major nuisance for scripts.
> 
> Personally, I would just leave the search path at the default, and use
> "map" for my own maps (and those in PERMANENT) and "map at mapset" for
> everything else.

Maybe yes, but then I have to know where all the maps live. That
means heavy usage of g.list and grep. So probably I stick with
having selected mapsets in my search path.

The current behaviour of GRASS is rather nice, I only wonder about
different behaviour as pointed out for g.copy and r.proj.

> The existing behaviour seems fine to me; if I run "r.mapcalc foo=...",
> it will create a map called "foo" in the current mapset. Any
> unqualified references to "foo" will then refer to the map which I've
> just created. I don't need to worry about whether someone else already
> has a map called "foo". And even if they have, I can access it with
> "foo at mapset".
> 
> -- 
> Glynn Clements <glynn.clements at virgin.net>

Markus