[GRASS-dev] modules have problems with @mapset

[Hamish]

Glynn Clements wrote:
> 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}.

Right.


> 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

It's a similar class of problem. Once we have a good solution for one
script we can apply the same method to the other.

> (I don't even know if there *is* a problem with v.db.addtable; I have
> yet to see any evidence that there is).

v.db.addtable:
....
    89      if [ $GIS_OPT_LAYER -eq 1 ] ; then
    90         g.message "Using vector map name as table name:
$MAP_NAME" 
    91         table="$MAP_NAME"
    92      else
    93         # two avoid tables with identical names on higher layers
    94         g.message "Using vector map name extended by layer
number as table name: ${MAP_NAME}_$GIS_OPT_LAYER" 
    95         table="${MAP_NAME}_$GIS_OPT_LAYER"
    96      fi
....

Thus $MAP_NAME should be unqualified and in the current mapset.


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

I was not aware that it was possible for the current mapset NOT to be
the first entry in the search path? If it is possible for that to
happen, is there a valid reason why that should be allowed?
The g.mapsets module insists on putting the current one first, I
suppose it is possible to hack the $MAPSET/SEARCH_PATH file manaually
to change the order, but I don't know why someone would want to.


> Whether the GUI should add that for "new" maps is debatable.

Well as long as we stick to the "only write to the current mapset"
rule^ it's redundant to qualify the name. And a lower signal to noise
ratio means typos are harder to spot.
(^ i.rectify)

> But modules and scripts should still handle that case. If they don't,
> it's a fault in the module rather than the GUI.

No arguement there.


Hamish



      ____________________________________________________________________________________
Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  http://tools.search.yahoo.com/newsearch/category.php?category=shopping