[GRASS5] maps with identical name in different mapsets

[Glynn Clements]

Markus Neteler wrote:

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

AFAIK, everything except g.copy works the same way as r.proj. g.copy
explicitly checks whether a map with that name exists in any mapset;
G_open_cell_new() doesn't do this, so programs won't get this
behaviour automatically.

This is probably as it should be; if everything behaved like g.copy,
it could cause real problems (particularly with programs which have
fixed output names; e.g. the CELL driver uses "D_cell", rgb.hsv.sh
uses "H", "S" and "V" etc).

Also, g.copy's check only prevents you from using a name which exists
in the *current* mapset path. If you subsequently add mapsets to the
path with g.mapsets, you may then have duplicates.

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