modules have problems with @mapset

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

modules have problems with @mapset

Michael Barton
I just ran into a couple modules that choke on map@mapset:

v.rast.stats
v.db.addtable

Perhaps there are others. Can these be updated to accept the map@mapset form?

Michael

______________________________

Michael Barton, Professor

Professor of Anthropology
Director of Graduate Studies
School of Human Diversity & Social Change
Center for Social Dynamics & Complexity

Arizona State University

Tempe, AZ  85287-2402

USA


voice: 480-965-6262; fax: 480-965-7671

www: http://www.public.asu.edu/~cmbarton



_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: modules have problems with @mapset

Glynn Clements

Michael Barton wrote:

> I just ran into a couple modules that choke on map@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@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.

In both cases, the script modifies the database associated with the
map, so it might only work for maps in the current mapset. 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?).

Or are you asking about the particular case of referencing maps which
happen to be in the current mapset using a qualified name? g.findfile
should[1] handle the situation where file= is qualified and the mapset
matches the mapset= option.

[1] I don't know whether it does; if it doesn't that's a g.findfile
bug.

Also, AFAICT, the parser only understands "old" maps (must exist, can
be in any mapset, won't be modified) and "new" maps (must not exist
unless --o etc is used, must be in the current mapset, will be
created). It doesn't have any concept of maps which are modified
in-place; this is rare for raster maps (only r.null springs to mind),
but seems to be not uncommon for vector maps.

--
Glynn Clements <[hidden email]>
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: modules have problems with @mapset

Michael Barton
To make this work better with the GUI parser and not generate an  
error, the script should just strip off the @mapset portion of the name.

Michael
______________________________
Michael Barton, Professor
Professor of Anthropology
Director of Graduate Studies
School of Human Diversity & Social Change
Center for Social Dynamics & Complexity
Arizona State University
Tempe, AZ  85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

On Feb 12, 2008, at 1:25 PM, Glynn Clements wrote:

>
> Michael Barton wrote:
>
>> I just ran into a couple modules that choke on map@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@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.
>
> In both cases, the script modifies the database associated with the
> map, so it might only work for maps in the current mapset. 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?).
>
> Or are you asking about the particular case of referencing maps which
> happen to be in the current mapset using a qualified name? g.findfile
> should[1] handle the situation where file= is qualified and the mapset
> matches the mapset= option.
>
> [1] I don't know whether it does; if it doesn't that's a g.findfile
> bug.
>
> Also, AFAICT, the parser only understands "old" maps (must exist, can
> be in any mapset, won't be modified) and "new" maps (must not exist
> unless --o etc is used, must be in the current mapset, will be
> created). It doesn't have any concept of maps which are modified
> in-place; this is rare for raster maps (only r.null springs to mind),
> but seems to be not uncommon for vector maps.
>
> --
> Glynn Clements <[hidden email]>

_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: modules have problems with @mapset

Markus Neteler
In reply to this post by Glynn Clements
On Feb 12, 2008 9:25 PM, Glynn Clements <[hidden email]> wrote:

>
> Michael Barton wrote:
>
> > I just ran into a couple modules that choke on map@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@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
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: modules have problems with @mapset

Glynn Clements
In reply to this post by Michael Barton

Michael Barton wrote:

> To make this work better with the GUI parser and not generate an  
> error, the script should just strip off the @mapset portion of the name.

Please answer the following question:

> > Or are you asking about the particular case of referencing maps which
> > happen to be in the current mapset using a qualified name?

If g.findfile doesn't handle the combination of mapset= and a
qualified name *where the mapsets are the same*, that's a bug in
g.findfile which should be fixed.

OTOH, if it's complaining because you're trying to use a map which
isn't in the current mapset, the scripts should be generating an
error. The scripts absolutely should not simply ignore the mapset.

--
Glynn Clements <[hidden email]>
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: modules have problems with @mapset

Michael Barton


On Feb 13, 2008, at 12:08 PM, Glynn Clements wrote:

>
> Michael Barton wrote:
>
>> To make this work better with the GUI parser and not generate an
>> error, the script should just strip off the @mapset portion of the  
>> name.
>
> Please answer the following question:
>
>>> Or are you asking about the particular case of referencing maps  
>>> which
>>> happen to be in the current mapset using a qualified name?
>
> If g.findfile doesn't handle the combination of mapset= and a
> qualified name *where the mapsets are the same*, that's a bug in
> g.findfile which should be fixed.
>
> OTOH, if it's complaining because you're trying to use a map which
> isn't in the current mapset, the scripts should be generating an
> error. The scripts absolutely should not simply ignore the mapset.

It's complaining that the map you are using isn't in the current  
mapset when it actually is in the mapset.

GRASS 6.3.svn (spearfish60_test):~ > v.rast.stats -e  
vector=sites@spatialtech2008 layer=1 raster=elevation.dem@PERMANENT  
colprefix=elev_ percentile=90
ERROR: sites@spatialtech2008_18153.0 is not in the current mapset
        (spatialtech2008)
ERROR: An error occurred while converting vector to raster
G__open(r): mapset (spatialtech2008) doesn't match xmapset  
(spatialtech2008_18153.0)
G__open(r): mapset (spatialtech2008) doesn't match xmapset  
(spatialtech2008_18153.0)
ERROR: sites@spatialtech2008_18153.0 is not in the current mapset
        (spatialtech2008)

But...

GRASS 6.3.svn (spearfish60_test):~ > v.rast.stats -e vector=sites  
layer=1 raster=elevation.dem@PERMANENT colprefix=elev_ percentile=90
Statistics calculated from raster map <elevation.dem@PERMANENT> and
uploaded to attribute table of vector map <sites>.
Done.
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: modules have problems with @mapset

Markus Neteler
On Feb 13, 2008 7:35 PM, Michael Barton <[hidden email]> wrote:

>
>
> On Feb 13, 2008, at 12:08 PM, Glynn Clements wrote:
>
> >
> > Michael Barton wrote:
> >
> >> To make this work better with the GUI parser and not generate an
> >> error, the script should just strip off the @mapset portion of the
> >> name.
> >
> > Please answer the following question:
> >
> >>> Or are you asking about the particular case of referencing maps
> >>> which
> >>> happen to be in the current mapset using a qualified name?
> >
> > If g.findfile doesn't handle the combination of mapset= and a
> > qualified name *where the mapsets are the same*, that's a bug in
> > g.findfile which should be fixed.
> >
> > OTOH, if it's complaining because you're trying to use a map which
> > isn't in the current mapset, the scripts should be generating an
> > error. The scripts absolutely should not simply ignore the mapset.
>
> It's complaining that the map you are using isn't in the current
> mapset when it actually is in the mapset.

I guess that you have a map with same name in a different path
and SEARCHPATH first defines that? What does
g.mapsets -p

say?

> GRASS 6.3.svn (spearfish60_test):~ > v.rast.stats -e
> vector=sites@spatialtech2008 layer=1 raster=elevation.dem@PERMANENT
> colprefix=elev_ percentile=90
> ERROR: sites@spatialtech2008_18153.0 is not in the current mapset
>         (spatialtech2008)
> ERROR: An error occurred while converting vector to raster
> G__open(r): mapset (spatialtech2008) doesn't match xmapset
> (spatialtech2008_18153.0)
> G__open(r): mapset (spatialtech2008) doesn't match xmapset
> (spatialtech2008_18153.0)
> ERROR: sites@spatialtech2008_18153.0 is not in the current mapset
>         (spatialtech2008)


Are you currently in "spatialtech2008" mapset? (just to be sure)
This "xmapset" thing is strange above.
Related: how old is your g.mapsets? I updated it on Feb 2:
http://trac.osgeo.org/grass/changeset/30030
http://trac.osgeo.org/grass/changeset/30031
http://trac.osgeo.org/grass/changeset/30032
to use longer buffers.

> But...
>
> GRASS 6.3.svn (spearfish60_test):~ > v.rast.stats -e vector=sites
> layer=1 raster=elevation.dem@PERMANENT colprefix=elev_ percentile=90
> Statistics calculated from raster map <elevation.dem@PERMANENT> and
> uploaded to attribute table of vector map <sites>.
> Done.

Maybe related to the previously too short buffers?

Markus
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: modules have problems with @mapset

Michael Barton

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

On Feb 13, 2008, at 2:52 PM, Markus Neteler wrote:

>> It's complaining that the map you are using isn't in the current
>> mapset when it actually is in the mapset.
>
> I guess that you have a map with same name in a different path

No. This is the only map with this name.

>
> and SEARCHPATH first defines that? What does
> g.mapsets -p
>
>
> say?


spatialtech2008 PERMANENT


>
>
>> GRASS 6.3.svn (spearfish60_test):~ > v.rast.stats -e
>> vector=sites@spatialtech2008 layer=1 raster=elevation.dem@PERMANENT
>> colprefix=elev_ percentile=90
>> ERROR: sites@spatialtech2008_18153.0 is not in the current mapset
>>        (spatialtech2008)
>> ERROR: An error occurred while converting vector to raster
>> G__open(r): mapset (spatialtech2008) doesn't match xmapset
>> (spatialtech2008_18153.0)
>> G__open(r): mapset (spatialtech2008) doesn't match xmapset
>> (spatialtech2008_18153.0)
>> ERROR: sites@spatialtech2008_18153.0 is not in the current mapset
>>        (spatialtech2008)
>
>
> Are you currently in "spatialtech2008" mapset? (just to be sure)

yes

>
> This "xmapset" thing is strange above.
> Related: how old is your g.mapsets? I updated it on Feb 2:

Compiled from trunk 2 days ago

>
> http://trac.osgeo.org/grass/changeset/30030
> http://trac.osgeo.org/grass/changeset/30031
> http://trac.osgeo.org/grass/changeset/30032
> to use longer buffers.
>
>> But...
>>
>> GRASS 6.3.svn (spearfish60_test):~ > v.rast.stats -e vector=sites
>> layer=1 raster=elevation.dem@PERMANENT colprefix=elev_ percentile=90
>> Statistics calculated from raster map <elevation.dem@PERMANENT> and
>> uploaded to attribute table of vector map <sites>.
>> Done.
>
> Maybe related to the previously too short buffers?

I don't know.

Michael

>
>
> Markus

_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: modules have problems with @mapset

hamish-2
> >> It's complaining that the map you are using isn't in the current
> >> mapset when it actually is in the mapset.
...
> >> ERROR: sites@spatialtech2008_18153.0 is not in the current mapset
> >>        (spatialtech2008)


It is trying to append _{$TMP} after map@mapset instead of just 'map'.


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)
@@ -88,18 +88,20 @@
    g.message -e  "Vector map '$GIS_OPT_MAP' not found in current
mapset"
    exit 1
+else
+   MAP_NAME=`echo "$GIS_OPT_MAP" | cut -f1 -d'@'`
 fi


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


Hamish



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

_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: 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@spatialtech2008_18153.0 is not in the current mapset
> > >>        (spatialtech2008)
>
>
> It is trying to append _{$TMP} after map@mapset instead of just 'map'.
>
>
> 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)
> @@ -88,18 +88,20 @@
>     g.message -e  "Vector map '$GIS_OPT_MAP' not found in current
> mapset"
>     exit 1
> +else
> +   MAP_NAME=`echo "$GIS_OPT_MAP" | cut -f1 -d'@'`
>  fi

Completely bogus. Reverted.

This just papers over the symptoms without fixing anything.

If the name includes a mapset which isn't the current one, that's an
error. You don't just discard the mapset.

If you don't have a clue what's going on, don't just commit random
changes which make the problem appear to go away on your system.

--
Glynn Clements <[hidden email]>
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: modules have problems with @mapset

Glynn Clements
In reply to this post by hamish-2

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@spatialtech2008_18153.0 is not in the current mapset
> > >>        (spatialtech2008)
>
>
> It is trying to append _{$TMP} after map@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@glynn'
        mapset='glynn'
        fullname='newmap@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 <[hidden email]>
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: modules have problems with @mapset

hamish-2
In reply to this post by Glynn Clements
> Hamish wrote:
> > It is trying to append _{$TMP} after map@mapset instead of just
> > 'map'.
> >
> > 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)
> > @@ -88,18 +88,20 @@
> >     g.message -e  "Vector map '$GIS_OPT_MAP' not found in current
> > mapset"
> >     exit 1
> > +else
> > +   MAP_NAME=`echo "$GIS_OPT_MAP" | cut -f1 -d'@'`
> >  fi

Glynn:
> Completely bogus. Reverted.
>
> This just papers over the symptoms without fixing anything.
>
> If the name includes a mapset which isn't the current one, that's an
> error. You don't just discard the mapset.

note that was placed after a test to see if the map existed in the
current mapset. I now am reminded of the case where the user wants to
use somemap@othermapset when there is already a map of the same name in
the current.

Hopefully what is there now works to everyone's statisfaction.


Hamish



      ____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 


_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: modules have problems with @mapset

hamish-2
In reply to this post by Glynn Clements
Glynn Clements wrote:

> I note that g.findfile doesn't include the unqualified name in its
> output, e.g.:
>
> name='newmap@glynn'
> mapset='glynn'
> fullname='newmap@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

_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: modules have problems with @mapset

Glynn Clements
In reply to this post by hamish-2

Hamish wrote:

> > > It is trying to append _{$TMP} after map@mapset instead of just
> > > 'map'.
> > >
> > > 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)
> > > @@ -88,18 +88,20 @@
> > >     g.message -e  "Vector map '$GIS_OPT_MAP' not found in current
> > > mapset"
> > >     exit 1
> > > +else
> > > +   MAP_NAME=`echo "$GIS_OPT_MAP" | cut -f1 -d'@'`
> > >  fi
>
> Glynn:
> > Completely bogus. Reverted.
> >
> > This just papers over the symptoms without fixing anything.
> >
> > If the name includes a mapset which isn't the current one, that's an
> > error. You don't just discard the mapset.
>
> note that was placed after a test to see if the map existed in the
> current mapset. I now am reminded of the case where the user wants to
> use somemap@othermapset when there is already a map of the same name in
> the current.

Sorry. I completely mis-read what that line was doing. It's removing
the mapset when the check *succeeds*.

--
Glynn Clements <[hidden email]>
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: modules have problems with @mapset

Glynn Clements
In reply to this post by hamish-2

Hamish wrote:

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

>From a library perspective, the search path can be set to anything;
the current mapset doesn't even need to be in the path.

> If it is possible for that to
> happen, is there a valid reason why that should be allowed?

Suppose that you're generating a set of output maps from a set of
input maps, the two sets share a common naming policy, and the
operations aren't simple 1:1 operations (generating a single output
from a single input with the same name). It would be quite easy to
inadvertantly use a map from the output mapset instead of the input
mapset.

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

AFAICT, g.mapsets adds the current mapset to the head of the search
path if it isn't already in the path, but won't move it if it's
elsewhere in the path.

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

The main problem there is that the parser interface doesn't have any
notion of "update in place", which is the situation for both
v.db.addtable and v.rast.stats.

The maps to be updated can't be declared as "new", because they have
to already exist. So, they're declared as "old", which means that the
GUI thinks that they can be in any mapset, and uses qualified names.

--
Glynn Clements <[hidden email]>
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: modules have problems with @mapset

hamish-2
Hamish:
> > 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.
Glynn:
> AFAICT, g.mapsets adds the current mapset to the head of the search
> path if it isn't already in the path, but won't move it if it's
> elsewhere in the path.

I notice now that from the command line g.mapsets does give you more
control WRT mapset order than the GUI checkbox interface does.


[...]
> The main problem there is that the parser interface doesn't have any
> notion of "update in place", which is the situation for both
> v.db.addtable and v.rast.stats.
>
> The maps to be updated can't be declared as "new", because they have
> to already exist. So, they're declared as "old", which means that the
> GUI thinks that they can be in any mapset, and uses qualified names.

One thing to consider is that these modules are not modifying the
vector maps per se (vertices and topology), they are modifying the
associated database tables. And DBs historically are designed to be
modified in place.

AFAIK the primary* modules which modify maps in place are d.rast.edit
and v.edit. Hmmm, actually that's wrong- d.rast.edit takes input= and
output=, so maybe it is just v.edit.

* I hesitate to say "only" due to the sheer number of oddball modules.


Back on the @mapset thing, I just found a bug in i.target when called
from the GUI.
Step 1: create a group with i.group.
Step 2: start the i.target tcltk module GUI. Select your group from
        the GUI folder picker. It shows up as group@currentmapset.
Step 3: choose your target location  & mapset, hit run.
Step 4: 'g.list groups'.

You will notice two groups, your original group and one called
"group@currentmapset" containing the new TARGET file.

As mentioned earlier re. i.smap:
  imagery modules + @mapset = needs lots of cleanup work.


Hamish



      ____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 


_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev