[GRASS-dev] i.rectify still chokes on @mapset

GRASS GRASS developer
1

One of my students is testing the GRASSRC4 windows release. Apparently, i.rectify still raises and error if the maps in the group file have the mapset specification (map@mapset). I thought this was fixed. We can try to strip the mapset specifier out in the GUI, but I thought that all modules were supposed to respect it.

Michael

C. Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

Phone: 480-965-6262
Fax: 480-965-7671
www: <www.public.asu.edu/~cmbarton>

2

On Tue, Apr 14, 2009 at 6:39 PM, Michael Barton <michael.barton@asu.edu> wrote:

One of my students is testing the GRASSRC4 windows release. Apparently,
i.rectify still raises and error if the maps in the group file have the
mapset specification (map@mapset). I thought this was fixed. We can try to
strip the mapset specifier out in the GUI, but I thought that all modules
were supposed to respect it.
Michael

The related discussion is in this ticket:
http://trac.osgeo.org/grass/ticket/70

Markus

3

On Tue, Apr 14, 2009 at 8:56 PM, Markus Neteler <neteler@osgeo.org> wrote:

On Tue, Apr 14, 2009 at 6:39 PM, Michael Barton <michael.barton@asu.edu> wrote:

One of my students is testing the GRASSRC4 windows release. Apparently,
i.rectify still raises and error if the maps in the group file have the
mapset specification (map@mapset). I thought this was fixed. We can try to
strip the mapset specifier out in the GUI, but I thought that all modules
were supposed to respect it.
Michael

The related discussion is in this ticket:
http://trac.osgeo.org/grass/ticket/70

I have downloaded the "imagery" package for Spearfish,
- run i.target to point the "demo" group to the "spearfish60"
  location,
- run i.points to set 4 GCPs
- run i.rectify:

GRASS 6.5.svn (imagery60):~ > i.rectify demo in=nhap.1 ext=rect order=1
Region N=4928327.747796 S=4922940.933568 E=602038.752218 W=588501.065840
Resolution EW=6.474264 NS=6.293007
Rectified input raster map <nhap.1> will be saved as <nhap.1rect>
100%
Rectify <nhap.1@PERMANENT> (location <imagery60>)
into <nhap.1rect@neteler> (location <spearfish60>) ... complete
-----------------------------------------------
i.rectify complete.

and it works... (result is ok in the target UTM location).

head -20 grassdata/imagery60/user1/group/demo/*
==> grassdata/imagery60/user1/group/demo/POINTS <==
# image target status
# east north east north (1=ok)
#
      2042.513344 -712.821839 600117.032967 4925562.236842 1
      1097.131868 -765.296935 594306.527473 4925394.868421 1
       650.701727 -499.641762 591547.582418 4927194.078947 1
       448.056089 -557.957883 590370.589286 4926762.321514 1
       599.690518 -1082.381863 591988.872607 4923848.733105 1

==> grassdata/imagery60/user1/group/demo/REF <==
nhap.1 PERMANENT b
nhap.2 PERMANENT g
nhap.3 PERMANENT r

==> grassdata/imagery60/user1/group/demo/TARGET <==
spearfish60
neteler

looks all good to me.

And then, just to be sure, created a new group:
GRASS 6.5.svn (imagery60):~ > i.group group=mydemo input=nhap.1,nhap.2,nhap.3
Adding raster map <nhap.1@PERMANENT> to group
Adding raster map <nhap.2@PERMANENT> to group
Adding raster map <nhap.3@PERMANENT> to group
i.group complete.
GRASS 6.5.svn (imagery60):~ > cat grassdata/imagery60/user1/group/mydemo/REF
nhap.1 PERMANENT
nhap.2 PERMANENT
nhap.3 PERMANENT

also ok.

So might it be a Windows specific issue?

Markus

4

On Apr 14, 2009, at 2:46 PM, Markus Neteler wrote:

On Tue, Apr 14, 2009 at 8:56 PM, Markus Neteler <neteler@osgeo.org> wrote:

On Tue, Apr 14, 2009 at 6:39 PM, Michael Barton <michael.barton@asu.edu> wrote:

One of my students is testing the GRASSRC4 windows release. Apparently,
i.rectify still raises and error if the maps in the group file have the
mapset specification (map@mapset). I thought this was fixed. We can try to
strip the mapset specifier out in the GUI, but I thought that all modules
were supposed to respect it.
Michael

The related discussion is in this ticket:
#70 (imagery modules: strip @mapset part) – GRASS GIS

I have downloaded the "imagery" package for Spearfish,
- run i.target to point the "demo" group to the "spearfish60"
location,
- run i.points to set 4 GCPs
- run i.rectify:

GRASS 6.5.svn (imagery60):~ > i.rectify demo in=nhap.1 ext=rect order=1
Region N=4928327.747796 S=4922940.933568 E=602038.752218 W=588501.065840
Resolution EW=6.474264 NS=6.293007
Rectified input raster map <nhap.1> will be saved as <nhap.1rect>
100%
Rectify <nhap.1@PERMANENT> (location <imagery60>)
into <nhap.1rect@neteler> (location <spearfish60>) ... complete
-----------------------------------------------
i.rectify complete.

and it works... (result is ok in the target UTM location).

head -20 grassdata/imagery60/user1/group/demo/*
==> grassdata/imagery60/user1/group/demo/POINTS <==
# image target status
# east north east north (1=ok)
#
     2042.513344 -712.821839 600117.032967 4925562.236842 1
     1097.131868 -765.296935 594306.527473 4925394.868421 1
      650.701727 -499.641762 591547.582418 4927194.078947 1
      448.056089 -557.957883 590370.589286 4926762.321514 1
      599.690518 -1082.381863 591988.872607 4923848.733105 1

==> grassdata/imagery60/user1/group/demo/REF <==
nhap.1 PERMANENT b
nhap.2 PERMANENT g
nhap.3 PERMANENT r

==> grassdata/imagery60/user1/group/demo/TARGET <==
spearfish60
neteler

looks all good to me.

And then, just to be sure, created a new group:
GRASS 6.5.svn (imagery60):~ > i.group group=mydemo input=nhap.1,nhap.2,nhap.3
Adding raster map <nhap.1@PERMANENT> to group
Adding raster map <nhap.2@PERMANENT> to group
Adding raster map <nhap.3@PERMANENT> to group
i.group complete.
GRASS 6.5.svn (imagery60):~ > cat grassdata/imagery60/user1/group/mydemo/REF
nhap.1 PERMANENT
nhap.2 PERMANENT
nhap.3 PERMANENT

also ok.

So might it be a Windows specific issue?

Markus

Maybe. I'm copying Isaac who reported this.

Michael

5

On Wed, Apr 15, 2009 at 1:17 AM, Isaac Ullah <iullah@asu.edu> wrote:

The error I get is like this: "map@mapset" is not found in group "map_group"
try using maps "map@mapset"
where my group is "map_group", which contains only one map "map@mapset".

I have now also tried 6.4.0svn on cmd line, no problem.

But:

This error comes after using both the tcltk and the wx georectifier when
trying to do final georectififactaion after points are made, and is even
replicated when i.rectify using from the original xy location after a
correct points file is made. I am able to circumvent this error by
specifying a map name in i.rectify, but stripping the "@mapset". If I don't
strip the "@mapset", then same error occurs.

I feel that the GUIs introduce the problem since it works on command
line.

For example:

grep mapset gui/tcltk/gis.m/georect.tcl | grep -v '#'
            set cmd "i.target group=$GRMap::xygroup location=$currloc
mapset=$currmset"
            -title [G_msg "Select mapset of raster to georectify"] \
    Button $row.a -text [G_msg "1. Select mapset"] \

Why
$GRMap::xygroup
?

suggestion: remove ::xygroup in both lines 292 and 294 in file
etc/gm/georect.tcl
from the i.target command and try again.

I currently don't have the time to try the GUI based georectifier
tools... perhaps taking off the mapset from the input helps?

Markus

6

On Apr 15, 2009, at 12:10 AM, Markus Neteler wrote:

grep mapset gui/tcltk/gis.m/georect.tcl | grep -v '#'
           set cmd "i.target group=$GRMap::xygroup location=$currloc
mapset=$currmset"
           -title [G_msg "Select mapset of raster to georectify"] \
   Button $row.a -text [G_msg "1. Select mapset"] \

Why
$GRMap::xygroup
?

This calls a variable (xygroup) that identifies the group file.

I think I see what the problem is, and I still don't think it is the GUI, especially be cause it causes a problem in both TclTk and wxPython.

Sometime (recently??), i.rectify has been changed so that it now accepts map names as input; it used to only accept a group as input. The TclTk and wxPython GUI's only send a group to i.rectify, not a map or list of maps.

Isaac, take a look at the relevant group file and see if it has the mapsets appended to the map names AND see if it has incorrect information like mapsets appended twice. Then run i.rectfy with group input, not map input. Also, try i.rectify with a map input that does use @mapset. I'm betting that it chokes on the first at least and either i.group is making the group wrong or i.rectify has trouble with groups in which the @mapset is part of the group name.

A more general question Markus (or others) is which direction is i.rectify going now: inputting groups or just inputting maps? There has been off and on discussion about groups that I've only partly followed. I seem to remember that subgroups are now gone. It would simplify the GUI work some if we could skip the group creation and just rectify a map or list of maps. The group is there to rectify a batch of multiband imagery files. Is this still the way to go? Maybe we could just leave the more sophisticated way of running i.rectify (e.g., on groups) to the module itself and not worry about implementing groups in the GUI.

Michael

7

On 15/04/09 17:04, Michael Barton wrote:

Sometime (recently??), i.rectify has been changed so that it now accepts map names as input; it used to only accept a group as input. The TclTk and wxPython GUI's only send a group to i.rectify, not a map or list of maps.

Where do you see this ? If you mean the input= option, then this has been there ever since 6.0, and it is not required, whereas group= is.

Moritz

8

On Wed, Apr 15, 2009 at 5:04 PM, Michael Barton <michael.barton@asu.edu> wrote:

On Apr 15, 2009, at 12:10 AM, Markus Neteler wrote:

grep mapset gui/tcltk/gis.m/georect.tcl | grep -v '#'
set cmd "i.target group=$GRMap::xygroup location=$currloc
mapset=$currmset"
-title [G_msg "Select mapset of raster to georectify"] \
Button $row.a -text [G_msg "1. Select mapset"] \

Why
$GRMap::xygroup
?

This calls a variable (xygroup) that identifies the group file.

I think I see what the problem is, and I still don't think it is the GUI,
especially be cause it causes a problem in both TclTk and wxPython.

Sometime (recently??), i.rectify has been changed so that it now accepts map
names as input; it used to only accept a group as input. The TclTk and
wxPython GUI's only send a group to i.rectify, not a map or list of maps.

i.rectify was changed to use G_parser() in June 2008. I didn't check
in detail but the interface is as before.

Isaac, take a look at the relevant group file and see if it has the mapsets
appended to the map names AND see if it has incorrect information like
mapsets appended twice. Then run i.rectfy with group input, not map input.
Also, try i.rectify with a map input that does use @mapset. I'm betting that
it chokes on the first at least and either i.group is making the group wrong
or i.rectify has trouble with groups in which the @mapset is part of the
group name.

A more general question Markus (or others) is which direction is i.rectify
going now: inputting groups or just inputting maps? There has been off and
on discussion about groups that I've only partly followed.

Mhh, personally I don't recall any discussion.
Why changes? we cannot, at least in the GRASS 6 version.

I seem to remember that subgroups are now gone.

They are pretty alive :slight_smile:

It would simplify the GUI work some if
we could skip the group creation and just rectify a map or list of maps. The
group is there to rectify a batch of multiband imagery files. Is this still
the way to go? Maybe we could just leave the more sophisticated way of
running i.rectify (e.g., on groups) to the module itself and not worry about
implementing groups in the GUI.

I am not sure but there should be no interface differences between 6.0 and 6.4.

Markus

9

On Wed, Apr 15, 2009 at 7:12 PM, Isaac Ullah <iullah@asu.edu> wrote:

To clarify, the error is exactly this:

i.rectify group=central_hasa_square_60_69@PERMANENT
input=central_hasa_square_60_69.1@PERMANENT extension=rectify_test order=1
Input raster map <central_hasa_square_60_69.1@PERMANENT> does not exist in
group <central_hasa_square_60_69@PERMANENT>.
Try:
central_hasa_square_60_69.1
central_hasa_square_60_69.alpha
Exit!

three questions:

- in which mapset are you currently? (g.gisenv)
- does the group really exist? (g.list group)
- please post the content of the group file

Markus

10

On 15/04/09 19:14, Markus Neteler wrote:

On Wed, Apr 15, 2009 at 7:12 PM, Isaac Ullah <iullah@asu.edu> wrote:

To clarify, the error is exactly this:

i.rectify group=central_hasa_square_60_69@PERMANENT
input=central_hasa_square_60_69.1@PERMANENT extension=rectify_test order=1
Input raster map <central_hasa_square_60_69.1@PERMANENT> does not exist in
group <central_hasa_square_60_69@PERMANENT>.
Try:
central_hasa_square_60_69.1
central_hasa_square_60_69.alpha
Exit!

three questions:

- in which mapset are you currently? (g.gisenv)
- does the group really exist? (g.list group)
- please post the content of the group file

As the message says, the group file contains central_hasa_square_60_69.1, but not central_hasa_square_60_69.1@PERMANENT. I would guess that the problem is in line 166 of imagery/i.rectify/main.c (ref to trunk) where you have

if (strcmp(ifile->answers[m], ref.file[n].name) == 0) {

without stripping the @mapset from the file name and so the comparison with the files in the group fails.

Don't know how this is handled elsewhere, but should be fairly trivial to correct, I would guess.

Moritz

11

On Wed, Apr 15, 2009 at 7:44 PM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:

On 15/04/09 19:14, Markus Neteler wrote:

On Wed, Apr 15, 2009 at 7:12 PM, Isaac Ullah <iullah@asu.edu> wrote:

To clarify, the error is exactly this:

i.rectify group=central_hasa_square_60_69@PERMANENT
input=central_hasa_square_60_69.1@PERMANENT extension=rectify_test
order=1
Input raster map <central_hasa_square_60_69.1@PERMANENT> does not exist
in
group <central_hasa_square_60_69@PERMANENT>.
Try:
central_hasa_square_60_69.1
central_hasa_square_60_69.alpha
Exit!

three questions:

- in which mapset are you currently? (g.gisenv)
- does the group really exist? (g.list group)
- please post the content of the group file

As the message says, the group file contains central_hasa_square_60_69.1,
but not central_hasa_square_60_69.1@PERMANENT. I would guess that the
problem is in line 166 of imagery/i.rectify/main.c (ref to trunk) where you
have

if (strcmp(ifile->answers[m], ref.file[n].name) == 0) {

without stripping the @mapset from the file name and so the comparison with
the files in the group fails.

Don't know how this is handled elsewhere, but should be fairly trivial to
correct, I would guess.

Same in v.lidar.growing (maybe others).

Do we need a new function to strip off the @mapset from a file name?
Cannot find it...

Markus

12

Hi,

2009/4/25 Markus Neteler <neteler@osgeo.org>:

[...]

Do we need a new function to strip off the @mapset from a file name?
Cannot find it...

G__name_in_mapset()

?

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa

13

On Sat, Apr 25, 2009 at 10:12 AM, Martin Landa <landa.martin@gmail.com> wrote:

2009/4/25 Markus Neteler <neteler@osgeo.org>:

[...]

Do we need a new function to strip off the @mapset from a file name?
Cannot find it...

G__name_in_mapset()

?

I always that that G__ functions are for internal use. But maybe we
could wrap it?

Markus

14

Markus Neteler wrote:

Do we need a new function to strip off the @mapset from a file name?
Cannot find it...

G__name_is_fully_qualified() will split a qualified name into map and
mapset parts.

G__unqualified_name() does likewise, but also checks whether the
@mapset part matches a specific mapset.

In either case, you need to check the return value to determine
whether the output buffers were filled in.

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