[GRASS-dev] GRASS-dev] 6.4.1 blocker bugs?

On Jan 30, 2011, at 5:26 AM, <grass-dev-request@lists.osgeo.org> <grass-dev-request@lists.osgeo.org> wrote:

Date: Sun, 30 Jan 2011 00:38:21 -0500
From: Helena Mitasova <hmitaso@unity.ncsu.edu>
Subject: Re: [GRASS-dev] GRASS-dev] 6.4.1 blocker bugs?
To: Martin Landa <landa.martin@gmail.com>
Cc: "grass-dev@lists.osgeo.org list" <grass-dev@lists.osgeo.org>
Message-ID: <C3860209-4A71-4649-B9F7-0189606BF0F7@unity.ncsu.edu>
Content-Type: text/plain; charset=us-ascii

Martin,

thanks a lot for all the fixes - I got the release branch compiled and tested and I can confirm that
everything mentioned below and the histogram now work.

Only import still gives me trouble and this may be on Mac an Windows only (Michael, William does this work for you?
almost all my students had trouble with this)
For import with Common import formats (both raster and vector)
I tried different options and all file names are always greyed out and cannot be selected on Mac.
Import works when Directory is selected, because then I select directory and the shape files within it are loaded.
Import of files through the Command dialog works.
Maybe I am not understanding the File option in the Pannel "Import Raster Data" correctly?

I agree with Helena here. Thanks for all the recent fixes. However, the common import dialog/wrapper for r.in.gdal and v.in.ogr still has a number of problems.

Perhaps we could just stick with the original module dialogs for 6.4 so that there is time to get this custom import dialog working well. I can see how it could simplify the sometimes puzzling syntax of v.in.ogr but I'm not sure that it is any easier to navidate than r.in.gdal even if working right.

And one more issues as I keep trying new things -
d.rast.num - does nothing for me even if I zoom to just few grid cells (when doing this I discovered the option to display the
computational region boundary in the map display - very nice and useful feature).
d.rast.arrow - just colors the raster green - I don't see any arrows

I can test again, but this works for me on the Mac. The key, as you surmise, Helena, is to have the resolution of the display match the computation region resolution so that when you zoom in, only a few cells are displayed. It took a bit of playing with this, but I got it to work recently.

Cheers
Michael

Hi,

2011/2/1 Michael Barton <Michael.Barton@asu.edu>:

I agree with Helena here. Thanks for all the recent fixes. However, the common import dialog/wrapper for r.in.gdal and v.in.ogr still has a number of problems.

Perhaps we could just stick with the original module dialogs for 6.4 so that there is time to get this custom import dialog working well. I can see how it could simplify the sometimes puzzling syntax of v.in.ogr but I'm not sure that it is any easier to navidate than r.in.gdal even if working right.

no, better fix the bugs and go ahead...

Martin

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

OK. You still have the list that I sent awhile back? I haven't gone back through that, but there were issues about recognizing files (Helena's note too), the fact that the dialog is modal, the lack of support for location creation, and a couple other items that I don't remember right now.

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

voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

On Feb 1, 2011, at 8:14 AM, Martin Landa wrote:

Hi,

2011/2/1 Michael Barton <Michael.Barton@asu.edu>:

I agree with Helena here. Thanks for all the recent fixes. However, the common import dialog/wrapper for r.in.gdal and v.in.ogr still has a number of problems.

Perhaps we could just stick with the original module dialogs for 6.4 so that there is time to get this custom import dialog working well. I can see how it could simplify the sometimes puzzling syntax of v.in.ogr but I'm not sure that it is any easier to navidate than r.in.gdal even if working right.

no, better fix the bugs and go ahead...

Martin

--
Martin Landa <landa.martin gmail.com> * Studijní program Geodézie a kartografie – GeoWikiCZ

2011/2/1 Michael Barton <Michael.Barton@asu.edu>:

but there were issues about recognizing files (Helena's note too)

[...]

hopefully fixed in r45274.

Martin

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

Great. Thanks. I'll test as soon as I can.

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

voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

On Feb 1, 2011, at 9:01 AM, Martin Landa wrote:

2011/2/1 Michael Barton <Michael.Barton@asu.edu>:

but there were issues about recognizing files (Helena's note too)

[...]

hopefully fixed in r45274.

Martin

--
Martin Landa <landa.martin gmail.com> * Studijní program Geodézie a kartografie – GeoWikiCZ

Hi,

2011/2/1 Michael Barton <Michael.Barton@asu.edu>:

the lack of support for location creation

[...]

check out r45277.

Martin

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

2011/2/1 Michael Barton <Michael.Barton@asu.edu>:

the fact that the dialog is modal

done in r45278.

Martin

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

Thanks much!

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

voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

On Feb 1, 2011, at 9:37 AM, Martin Landa wrote:

2011/2/1 Michael Barton <Michael.Barton@asu.edu>:

the fact that the dialog is modal

done in r45278.

Martin

--
Martin Landa <landa.martin gmail.com> * Studijní program Geodézie a kartografie – GeoWikiCZ

Martin,

Thanks for the quick work. I'm at home now and am able to test this. I updated to GRASS 6.4 release branch r45278 and compiled. No errors.

I've just tested the raster common import dialog.

The dialog is no longer modal and now it recognizes different file types (at least *.tif and *.png). A big improvement.

There are several things left to do on this.

1) I still cannot find where I can have it create a new location for a file I'm importing in a different projection from the one I'm in.
2) There is no way to specify a new name in GRASS for the imported file; it will only use the existing file name.
3) The load settings combo box does not work.
4) Clicking the "import" button closes the dialog, regardless of what happens. If there is an error or you want to load more than one file, you must reopen the dialog and browse to the file again.

I think that all of these affect the vector version too. So if it is a common wxDialog instance, then fixing it for raster should fix it for vector too I hope.

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

voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

On Feb 1, 2011, at 9:37 AM, Martin Landa wrote:

2011/2/1 Michael Barton <Michael.Barton@asu.edu>:

the fact that the dialog is modal

done in r45278.

Martin

--
Martin Landa <landa.martin gmail.com> * Studijní program Geodézie a kartografie – GeoWikiCZ

Martin, the GUI for import it still does not completely work for vector data:

- I can select shp file now but, as Michael pointed out, I cannot define its new name
- If I select directory, nothing shows up in the list of OGR layers and Import button is greyed out
- If I click File button again, I cannot select the shp file (as before)
- Import under command dialog works

The raster import worked except for the issues mentioned by Michael.

Helena

On Feb 1, 2011, at 10:39 PM, Michael Barton wrote:

Martin,

Thanks for the quick work. I'm at home now and am able to test this. I updated to GRASS 6.4 release branch r45278 and compiled. No errors.

I've just tested the raster common import dialog.

The dialog is no longer modal and now it recognizes different file types (at least *.tif and *.png). A big improvement.

There are several things left to do on this.

1) I still cannot find where I can have it create a new location for a file I'm importing in a different projection from the one I'm in.
2) There is no way to specify a new name in GRASS for the imported file; it will only use the existing file name.
3) The load settings combo box does not work.
4) Clicking the "import" button closes the dialog, regardless of what happens. If there is an error or you want to load more than one file, you must reopen the dialog and browse to the file again.

I think that all of these affect the vector version too. So if it is a common wxDialog instance, then fixing it for raster should fix it for vector too I hope.

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

voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

On Feb 1, 2011, at 9:37 AM, Martin Landa wrote:

2011/2/1 Michael Barton <Michael.Barton@asu.edu>:

the fact that the dialog is modal

done in r45278.

Martin

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

Here is more feedback on legends as we are trying to figure out how to reduce
the new users struggles (all of the below tested on GRASS6.4.release branch compiled yesterday):

- the legend does not get drawn and in fact scale bar and title gets erased if there are
wrong numbers defined by use= (see the error below).
This can happen easily if a legend is drawn with use= correctly defined,
then a new map is displayed and a new legend is defined without opening the Advanced Tab.
The categories from the previous map are remembered and if they are not present
in the new map it leads to error below, legend is not drawn and barscale and title disappears
as well causing quite a confusion.

Probably the best option to avoid this error would be to clear the use= numbers if
a new map is defined, although I can imagine cases when there are maps that one needs to
draw with legends that keep the same use= numbers. If the later is the desired behavior,
perhaps a more meaningful error message to guide the user to open the Advanced tab
would be helpful. I can provide an example, if it is not clear what I am talking about here.

- would it be possible to grey out or hide the button "Use mouse to size and place legend"?
everybody switches it on and tries to size the legend with mouse without success
(there is no hint anywhere that this does not work), I notice it is not there in GRASS7

- would it be possible to change the text:
"Placement as percentage of screen coordinates" to
"Size and placement as % of screen (should it be display?) coordinates"?
Unless you read the man page very carefully it is hard to find out how to size the legend.

One issue with Add text - when I click on Set font button to change the font,
the font menu just flashes - it closes instantly so there is no way to chose the font.
Set font from GUI settings>Display works

These are perhaps just cosmetics (at least I always treated them as such) but they make
a big difference in class and for new users in general,

Helena

Traceback (most recent call last):
  File "/Users/helena/grassrel6/grass64_release/dist.i386
-apple-darwin10.4.0/etc/wxpython/gui_modules/gdialogs.py",
line 528, in OnOK

self.parent.MapWindow.UpdateMap()
  File "/Users/helena/grassrel6/grass64_release/dist.i386
-apple-
darwin10.4.0/etc/wxpython/gui_modules/mapdisp_window.py",
line 840, in UpdateMap

for img in self.GetOverlay():
  File "/Users/helena/grassrel6/grass64_release/dist.i386
-apple-
darwin10.4.0/etc/wxpython/gui_modules/mapdisp_window.py",
line 699, in GetOverlay

if os.path.isfile(overlay.mapfile) and
os.path.getsize(overlay.mapfile):
  File "/System/Library/Frameworks/Python.framework/Versions
/2.6/lib/python2.6/genericpath.py", line 29, in isfile

st = os.stat(path)
TypeError
:
coercing to Unicode: need string or buffer, NoneType found

On Feb 2, 2011, at 8:55 PM, Helena Mitasova wrote:

Martin, the GUI for import it still does not completely work for vector data:

- I can select shp file now but, as Michael pointed out, I cannot define its new name
- If I select directory, nothing shows up in the list of OGR layers and Import button is greyed out
- If I click File button again, I cannot select the shp file (as before)
- Import under command dialog works

The raster import worked except for the issues mentioned by Michael.

Helena

On Feb 1, 2011, at 10:39 PM, Michael Barton wrote:

Martin,

Thanks for the quick work. I'm at home now and am able to test this. I updated to GRASS 6.4 release branch r45278 and compiled. No errors.

I've just tested the raster common import dialog.

The dialog is no longer modal and now it recognizes different file types (at least *.tif and *.png). A big improvement.

There are several things left to do on this.

1) I still cannot find where I can have it create a new location for a file I'm importing in a different projection from the one I'm in.
2) There is no way to specify a new name in GRASS for the imported file; it will only use the existing file name.
3) The load settings combo box does not work.
4) Clicking the "import" button closes the dialog, regardless of what happens. If there is an error or you want to load more than one file, you must reopen the dialog and browse to the file again.

I think that all of these affect the vector version too. So if it is a common wxDialog instance, then fixing it for raster should fix it for vector too I hope.

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

voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

On Feb 1, 2011, at 9:37 AM, Martin Landa wrote:

2011/2/1 Michael Barton <Michael.Barton@asu.edu>:

the fact that the dialog is modal

done in r45278.

Martin

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

_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Helena wrote:

- would it be possible to grey out or hide the button "Use
mouse to size and place legend"?
everybody switches it on and tries to size the legend with
mouse without success
(there is no hint anywhere that this does not work),

a wrapper script would be needed, similar to v.type.
see `d.legend --script` for a template.
I'd prefer that to changing the wording of the flag's description, as "for interactive xmons only" is too hard to explain to the new
GUI user in just a few words.

maybe module --interface description man-in-the-middle hijacking + ad-hoc override is possible in the wxPy code. ...? but it wouldn't be pretty.

I notice it is not there in GRASS7

all interactive Xmon capabilities were removed in GRASS 7.

- would it be possible to change the text:
"Placement as percentage of screen coordinates" to
"Size and placement as % of screen (should it be display?)
coordinates"?

I agree "coordinates" may be a bit redundant/confusing, but
grammatically it seems to want some word at the end. ...?

I do like to spell out the whole word instead of just "%".

Technically it's relative to the current display frame. But
the new GUI/GRASS user knows nothing of the d.frame architecture.
Another problem is that once set you can drag the legend around
the wx.canvas, at which point only the range of the values you
gave have meaning, the absolute values become meaningless.

Do you use xmons/d.frame in your course? is this complaint
related to that? As long as the legend overlay is not dragged
over the page, I think it should work as the GUI user would
expect.
?

Unless you read the man page very carefully it is hard to
find out how to size the legend.

is the "at: bottom,top,left,right" text not showing up above the
wxPy module GUI's at= entry box, as it does in the tcltk module
GUI? I thought Martin had implemented that recently.

Hamish

- would it be possible to change the text:
"Placement as percentage of screen coordinates" to
"Size and placement as % of screen (should it be display?)
coordinates"?

I agree "coordinates" may be a bit redundant/confusing, but
grammatically it seems to want some word at the end. ...?

I kept the coordinates - it just got wrapped to next line

I do like to spell out the whole word instead of just "%".

I am sorry, I have caused some confusion here - all what I wanted to be added is the word "size"
everything else can remain the same - so the suggested text could be:

Size and placement as percentage of screen coordinates

I changed percent to % because I thought that after adding the word Size the text will be too long

Technically it's relative to the current display frame. But
the new GUI/GRASS user knows nothing of the d.frame architecture.

that is exactly right, and it is not clear what is meant by screen, because the place
on the computer screen where the legend is posted is called "Map Display"

Another problem is that once set you can drag the legend around
the wx.canvas, at which point only the range of the values you
gave have meaning, the absolute values become meaningless.

you are exactly right there too - so the at= option for the GUI user is there mostly
to control the relative size of the legend (in a rather non-intuitive way, but people can deal with it).
Placement still applies when you want your legend to be placed in a predefined location
rather than move it by mouse - so "Size and placement" reflects well what the numbers do

Do you use xmons/d.frame in your course? is this complaint
related to that? As long as the legend overlay is not dragged
over the page, I think it should work as the GUI user would
expect.
?

Given that xmons are going away in GRASS7 and most students are on Windows 7
(forget labs with pre-installed software - students bring their own laptops to class these days)
I avoid xmon, although we use command line a lot.
And the firs thing users do is drag legend over the page as it is suggested by d.legend GUI
"Drag legend object with mouse in pointer mode to position"

I still use d.mon a lot in my research work because I am so used to it and a few things I still
like better there, but I am trying to adapt to life without d.mon and Martin has been
doing a great job making it easier.

I am not asking for any big changes - just adding the word "Size" to the GUI for at= option.

Unless you read the man page very carefully it is hard to
find out how to size the legend.

is the "at: bottom,top,left,right" text not showing up above the
wxPy module GUI's at= entry box, as it does in the tcltk module
GUI? I thought Martin had implemented that recently.

yes it is there - but you need to have a pretty creative thinking to associate
Placement as percentage of screen coordinates (0,0 is lower left) at=bottom,top,left,right with size.
Most people read just the word Placement and then click "Use mouse to size and place legend"
Adding the word "Size" will make it much clearer.

My point here is that you try to focus the student attention to all kinds of sophisticated and advanced
analysis and visualization and they get bogged down on legends and you cannot skip the legends because then the maps don't mean anything. It does not need too much and it will be great,

Helena

Hamish

Hi,

2011/2/4 Hamish <hamish_b@yahoo.com>:

Helena wrote:

- would it be possible to grey out or hide the button "Use
mouse to size and place legend"?
everybody switches it on and tries to size the legend with
mouse without success
(there is no hint anywhere that this does not work),

a wrapper script would be needed, similar to v.type.
see `d.legend --script` for a template.
I'd prefer that to changing the wording of the flag's description, as "for interactive xmons only" is too hard to explain to the new
GUI user in just a few words.

maybe module --interface description man-in-the-middle hijacking + ad-hoc override is possible in the wxPy code. ...? but it wouldn't be pretty.

I have implement it as `blackList` defined in menuform.py. In this
case `-m` flag is hidden only when dialog is launched from the GUI,
see r45552. Backported to devbr6. After some testing it could be
applied in relbr64 too.

Martin

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