[GRASS-dev] modules have problems with @mapset

[Glynn Clements]

Hamish wrote:

> > >> It's complaining that the map you are using isn't in the current
> > >> mapset when it actually is in the mapset.
> ...
> > >> ERROR: sites at spatialtech2008_18153.0 is not in the current mapset
> > >>        (spatialtech2008)
> 
> 
> It is trying to append _{$TMP} after map at mapset instead of just 'map'.

That's a bug in v.rast.stats.

I note that g.findfile doesn't include the unqualified name in its
output, e.g.:

	name='newmap at glynn'
	mapset='glynn'
	fullname='newmap at glynn'
	file='/opt/grass-data/global/glynn/vector/newmap'

There should probably be a (e.g.) basename= line in its output.

In its absence, v.rast.stats will need to manually obtain the
unqualified before appending _${TMPNAME}.

> Try this:
>   http://trac.osgeo.org/grass/changeset/30118
> (really please try that, I haven't tested it)
> 
> 
> +++ /grass/trunk/scripts/v.db.addtable/v.db.addtable (revision 30118)

Michael was reporting a problem with v.rast.stats, which is completely
unrelated to any problem which may or may not exist with v.db.addtable
(I don't even know if there *is* a problem with v.db.addtable; I have
yet to see any evidence that there is).

> As for i.smap, the imagery library + modules are known to be very bad
> at dealing with @mapset, my suggestion for users of imagery modules is
> to not use @mapset at all. (yes I know the GUI insists on adding that,
> sorry..)

The GUI *should* insist on adding that, at least for input maps.

Yet again: an unqualified input map name does *not* refer to a map in
the current mapset. It refers to the first map with that name in the
search path. They aren't the same thing.

Whether the GUI should add that for "new" maps is debatable. But
modules and scripts should still handle that case. If they don't, it's
a fault in the module rather than the GUI.

-- 
Glynn Clements <glynn at gclements.plus.com>