[GRASS-dev] modules have problems with @mapset

[Markus Neteler]

On Feb 12, 2008 9:25 PM, Glynn Clements <glynn at gclements.plus.com> wrote:
>
> Michael Barton wrote:
>
> > I just ran into a couple modules that choke on map at mapset:
> >
> > v.rast.stats
>
>         # does map exist in CURRENT mapset?
>         eval `g.findfile element=vector file="$VECTOR" mapset="$MAPSET"`
>         if [ ! "$file" ] ; then
>            g.message -e "Vector map <$VECTOR> not found"
>            exit 1
>         fi
>
>         ------------------------------------------------------------------------
>         r23567 | markus | 2007-04-25 23:08:51 +0100 (Wed, 25 Apr 2007) | 2 lines
>
>         test improved: does map exist in CURRENT mapset?
>
> > v.db.addtable
>
>         # does map exist in CURRENT mapset?
>         eval `g.findfile element=vector file=$GIS_OPT_MAP mapset=$MAPSET`
>         if [ ! "$file" ] ; then
>            g.message -e  "Vector map '$GIS_OPT_MAP' not found in current mapset"
>            exit 1
>         fi
>
>         ------------------------------------------------------------------------
>         r22855 | markus | 2007-03-07 13:01:31 +0000 (Wed, 07 Mar 2007) | 2 lines
>
>         check if map exists in current mapset
>
> > Perhaps there are others. Can these be updated to accept the
> > map at mapset form?
>
> One might assume that the author had some reason to require that the
> map was in the current mapset, given that they put CURRENT in block
> capitals.

AFAIK you can only update a vector map in the current mapset.
* v.rast.stats:  Calculates univariate statistics from a GRASS raster
map based on vector polygons and uploads statistics to new attribute
columns.

AFAIK you can only add a new table to a vector map in the current mapset.
* v.db.addtable:  Creates and adds a new attribute table to a given
layer of an existing vector map.


> In both cases, the script modifies the database associated with the
> map, so it might only work for maps in the current mapset.

...yes, I think so.

> Even if it
> happens to work for maps in other mapsets, it may be reasonable to
> explicitly prevent it (what if someone else is using the map?).

So far the policy was to only modify maps in the current mapset.
...

Markus