[GRASS5] Suggestions for gui discussion

GRASS GIS GRASS GIS developer
1

I am very happy about all the interest and comments generated by the proposal for the next generation GUI for GRASS. I will compile these and hope to work with people interested working on this part of the GRASS project to come up a set of UI specs and proposed roadmap for consideration by early next year. In the meantime, please continue with the comments and suggestions. They are very helpful and represent thoughts about how to make GIS useable from the people who are actually using GIS on a daily basis.

A couple things would help me and others to begin to parse the your ideas into a coherent proposal. Christian Wygoda suggested that we begin to use the grassgui list. This has been a largely inactive list for awhile. But this seems like the perfect time to reactivate it, especially as it has a pretty large member list.

So I’d request that you cross-post any general comments on the gui proposal to grassgui@grass.itc.it
For nitty-gritt discussions about the gui, it may be best to focus primarily on the gui list. Is this OK with everyone? I’m happy to cross-post all to the developer’s list if this is desired, but don’t want to fill everyone’s mailboxes with double posts.

Second, for any comments that involve comparisons with the current GRASS GUI (I like this, but…; I really don’t like this…; I like how x is done better in [name your GIS/interface]), it would be helpful if you could specify which GRASS version you’re working with. Even better, it would be helpful if you are using the current 6.1 cvs version. The reason is that the GUI (even the TclTk GUI) has evolved considerably since version 6.0 and is a completely different experience from 5.4. This will also help in making improvements to the current UI (which must still serve for awhile) while we’re developing a new one.

Thanks again for all the interest. It is greatly appreciated.

Michael

Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

2

I would vote against reactivating the gui list. I am subscribed to many ML,
and I wouldn't like to have one more. I do not think we'll generate enough
traffic on a mid-term to justify a separate ML.
pc

At 07:11, martedì 15 novembre 2005, Michael Barton has probably written:

So I¹d request that you cross-post any general comments on the gui proposal
to grassgui@grass.itc.it

--
Paolo Cavallini
email+jabber: cavallini@faunalia.it
www.faunalia.it
Piazza Garibaldi 5 - 56025 Pontedera (PI), Italy Tel: (+39)348-3801953

3

Paolo Cavallini wrote:

I would vote against reactivating the gui list. I am subscribed to many ML, and I wouldn't like to have one more. I do not think we'll generate enough traffic on a mid-term to justify a separate ML.

I agree. I think the fundamental discussion should stay on the developers list, and once a decision is made, then implementation can be discussed on the gui list if really justified.

Moritz

4

On Tue, 15 Nov 2005, Moritz Lennert wrote:

Paolo Cavallini wrote:
> I would vote against reactivating the gui list. I am subscribed to many ML,
> and I wouldn't like to have one more. I do not think we'll generate enough
> traffic on a mid-term to justify a separate ML.

I agree. I think the fundamental discussion should stay on the
developers list, and once a decision is made, then implementation can be
discussed on the gui list if really justified.

This seems to be a sensible view, because these are strategic issues.

Roger

Moritz

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

--
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Helleveien 30, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43
e-mail: Roger.Bivand@nhh.no

5

On 11/15/2005 08:11 AM, Michael Barton wrote:

Second, for any comments that involve comparisons with the current GRASS GUI
(I like this, but...; I really don¹t like this...; I like how x is done
better in [name your GIS/interface]), it would be helpful if you could
specify which GRASS version you¹re working with. Even better, it would be
helpful if you are using the current 6.1 cvs version. The reason is that the
GUI (even the TclTk GUI) has evolved considerably since version 6.0 and is a
completely different experience from 5.4. This will also help in making
improvements to the current UI (which must still serve for awhile) while
we¹re developing a new one.

You asked for it. So here comes. (; Georeferencing UI is EXTREMELY bad.
When I run I.points I also have to open qgis with another map of the
same location to get the real co-ordinates. it would be nice to be able
to force GRASS to open 2 windows. One with the map to be rectified and
another of the correct location (as an option, since one might not know
the co-ordinates) (as was my case). Then one should be able to pick a
point in one window and then either enter the co-ordinates or click in
the other window for the corresponding window. Oh and BTW the CPU spikes
up to 100% and my laptop fan starts to go on overdrive everytime I run
i.points... Is there a busy loop somewhere in the code?

--Wolf

6

Oh and BTW the CPU spikes up to 100% and my laptop fan starts to go on
overdrive everytime I run i.points... Is there a busy loop somewhere
in the code?

It's a long standing bug in GRASS 6 which happens any time you use the
mouse, e.g. d.zoom too.

feel free to fix it!

Hamish

7

Hopping into the discussion, four points:

On 11/15/05, Wolf Bergenheim <wolf+grass@bergenheim.net> wrote:

On 11/15/2005 08:11 AM, Michael Barton wrote:

You asked for it. So here comes. (; Georeferencing UI is EXTREMELY bad.
When I run I.points I also have to open qgis with another map of the
same location to get the real co-ordinates. it would be nice to be able
to force GRASS to open 2 windows. One with the map to be rectified and
another of the correct location (as an option, since one might not know
the co-ordinates) (as was my case). Then one should be able to pick a
point in one window and then either enter the co-ordinates or click in
the other window for the corresponding window.

point 1: This has been asked before. The (proprietary, commercial) GIS
GeoConcept has a mode with a split screen, where both views are linked
in position and zoom but the visibility of the "objects" (it¶ fully
object-oriented, so the concept of "layer" is quite strange to it) is
independent. This is GREAT for digitizing, visual analysis and so on.

Such a linking between two monitors (maybe just thoughtfully using
g.region save) would be a good addition to d.m.

Other nice (and differentiating) features of QGIS are:

point 2: "Configurable" thumbnail views and

point 3: Location bookmarks.

Feature 3 I guess could be easily implemented using g.region save; as
for 2, a button for png saving at subresolution and putting back the
image into another button shouldn't be much of a headache. But
indicating current region as a frame within the thumbnail is (AFAICT)
a little harder.

point 4: Something that is currently lacking a bit in QGIS (I'd say
JUMP has the best support of current FLOSS GISes) is thematic
cartography: classifiers, color selection and so on. That is a huge
work in UI design. I would dare to suggest that most novice GIS users
do begin with thematic cartography, not raster processing, so maybe
this is a strategic area for adoption. But then, personally I think
that this would yield the most benefit if done in QGIS, and not GRASS.

Just my S/. 0.07

Daniel.

8

Wolf,

I agree that the old interactive xterm interface (including i.points,
d.zoom, and others) needs to be updated. These interactive, mouse intensive
activities would probably benefit most by a new, better integrated GUI.

I'm a little puzzled by your wish for functionality, however. Currently,
GRASS (i.points) does open a pair of side-by-side windows that zoom and pan
synchronously, and permit you to click on the map to be georeferenced in one
window and a corresponding georeferenced point in the other. Alternatively,
you can enter the coordinates for a point to be georeferenced. It also
allows you to check the accuracy of your georeferencing and manage the GCP's
that you use to some degree.

Maybe because your (Cygwin?) system drags so much because of the mouse
polling bug, you've never gotten that far in i.points?

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Wolf Bergenheim <wolf+grass@bergenheim.net>
Date: Tue, 15 Nov 2005 15:23:18 +0200
To: grass5 <grass5@grass.itc.it>
Subject: Re: [GRASS5] Suggestions for gui discussion

On 11/15/2005 08:11 AM, Michael Barton wrote:

Second, for any comments that involve comparisons with the current GRASS GUI
(I like this, but...; I really don¹t like this...; I like how x is done
better in [name your GIS/interface]), it would be helpful if you could
specify which GRASS version you¹re working with. Even better, it would be
helpful if you are using the current 6.1 cvs version. The reason is that the
GUI (even the TclTk GUI) has evolved considerably since version 6.0 and is a
completely different experience from 5.4. This will also help in making
improvements to the current UI (which must still serve for awhile) while
we¹re developing a new one.

You asked for it. So here comes. (; Georeferencing UI is EXTREMELY bad.
When I run I.points I also have to open qgis with another map of the
same location to get the real co-ordinates. it would be nice to be able
to force GRASS to open 2 windows. One with the map to be rectified and
another of the correct location (as an option, since one might not know
the co-ordinates) (as was my case). Then one should be able to pick a
point in one window and then either enter the co-ordinates or click in
the other window for the corresponding window. Oh and BTW the CPU spikes
up to 100% and my laptop fan starts to go on overdrive everytime I run
i.points... Is there a busy loop somewhere in the code?

--Wolf

9

That's 4 to keep the initial discussion on the main developer's list and one
against it. I think it's important to have broader input. So I'll keep it
here for now.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Roger Bivand <Roger.Bivand@nhh.no>
Reply-To: <Roger.Bivand@nhh.no>
Date: Tue, 15 Nov 2005 12:09:41 +0100 (CET)
To: Moritz Lennert <mlennert@club.worldonline.be>
Cc: <cavallini@faunalia.it>, <grass5@grass.itc.it>
Subject: Re: [GRASS5] Suggestions for gui discussion

On Tue, 15 Nov 2005, Moritz Lennert wrote:

Paolo Cavallini wrote:

I would vote against reactivating the gui list. I am subscribed to many ML,
and I wouldn't like to have one more. I do not think we'll generate enough
traffic on a mid-term to justify a separate ML.

I agree. I think the fundamental discussion should stay on the
developers list, and once a decision is made, then implementation can be
discussed on the gui list if really justified.

This seems to be a sensible view, because these are strategic issues.

Roger

Moritz

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

--
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Helleveien 30, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43
e-mail: Roger.Bivand@nhh.no

10

On 11/16/2005 08:35 AM, Michael Barton wrote:

Wolf,

I agree that the old interactive xterm interface (including i.points,
d.zoom, and others) needs to be updated. These interactive, mouse
intensive activities would probably benefit most by a new, better
integrated GUI.

That is true. The good thing is that it still works.

I'm a little puzzled by your wish for functionality, however.
Currently, GRASS (i.points) does open a pair of side-by-side windows
that zoom and pan synchronously, and permit you to click on the map
to be georeferenced in one window and a corresponding georeferenced
point in the other. Alternatively, you can enter the coordinates for
a point to be georeferenced. It also allows you to check the accuracy
of your georeferencing and manage the GCP's that you use to some
degree.

I does? I only got one window where I could zoom and pan. And don't get
me wrong. I do think that the option of allowing one to enter
coordinates by hand is a very important feature that should not be
removed. I would for sure use it if I would for example have a set of
GPS coordinates and an aerial photo to rectify. This time I had a
scanned GT map to rectify to a raster map. It is possible that I simply
didn't use i.points correctly...

Maybe because your (Cygwin?) system drags so much because of the
mouse polling bug, you've never gotten that far in i.points?

The strange thing is that the system doesn't really drag, I'm running on
Debian Linux, but the CPU goes crazy and the fan too. (I really hate the
FAN).

--W

11

hi
On Tue, Nov 15, 2005 at 03:23:18PM +0200, Wolf Bergenheim wrote:

On 11/15/2005 08:11 AM, Michael Barton wrote:
>
You asked for it. So here comes. (; Georeferencing UI is EXTREMELY bad.
When I run I.points I also have to open qgis with another map of the
same location to get the real co-ordinates. it would be nice to be able
to force GRASS to open 2 windows. One with the map to be rectified and
another of the correct location (as an option, since one might not know
the co-ordinates) (as was my case). Then one should be able to pick a
point in one window and then either enter the co-ordinates or click in
the other window for the corresponding window.

If I understand it well, this is already the way, i.points works(?) --
one can open 4 frames in GRASS-monitor -- the left half is used for
currlently source location, the right half is used for displaying maps
from target location. it is not necessary to set the coordinates by
hand, you can "click" them in the target map.

or were you not talking about i.rectify?

Oh and BTW the CPU spikes
up to 100% and my laptop fan starts to go on overdrive everytime I run
i.points... Is there a busy loop somewhere in the code?

--Wolf

no idea

jachym

--
Jachym Cepicky
e-mail: jachym.cepicky@centrum.cz
URL: http://les-ejk.cz
GPG: http://les-ejk.cz/gnupg_public_key/
-----------------------------------------
OFFICE:
Department of Geoinformation Technologies
LDF MZLU v Brnì
Zemìdìlská 3
613 00 Brno
e-mail: xcepicky@node.mendelu.cz
URL: http://mapserver.mendelu.cz
Tel.: +420 545 134 514

12

On Thu, 2005-11-17 at 14:43 +0100, Jachym Cepicky wrote:

hi
On Tue, Nov 15, 2005 at 03:23:18PM +0200, Wolf Bergenheim wrote:
> On 11/15/2005 08:11 AM, Michael Barton wrote:
> >
> You asked for it. So here comes. (; Georeferencing UI is EXTREMELY bad.
> When I run I.points I also have to open qgis with another map of the
> same location to get the real co-ordinates

<snip>

If I understand it well, this is already the way, i.points works(?) --
one can open 4 frames in GRASS-monitor -- the left half is used for
currlently source location, the right half is used for displaying maps
from target location. it is not necessary to set the coordinates by
hand, you can "click" them in the target map.

Right, that's the way it works, but it is far from comfortable and
efficient. It's merely usable (oh, we nowadays Grass users are so
spoiled).

I wish i.points functionality could be implemented into QGIS
georeferencer plugin... As well as other warping methods, as presently
QGIS provides only Helmert's AFAIR.

or were you not talking about i.rectify?

BTW - that'd be great if Grass could use Gdal warping - the speed and
reliability.

> Oh and BTW the CPU spikes
> up to 100% and my laptop fan starts to go on overdrive everytime I run
> i.points... Is there a busy loop somewhere in the code?

You haven't heard my laptop yet ;). But what's really bad is that this
bug hampers Grass usability in a network where one machine is a server
for several Grass sessions - imagine all the users trying to use
i.points / other mouse intensive operation in the same time. Has anybody
got an idea how to get rid of this bug?

Maciek

P.S.
Forwarding to qgis-devel to see if there is any feedback in regard to
georefencer plugin improvement.

--------------------
W polskim Internecie s± setki milionów stron. My przekazujemy Tobie tylko najlepsze z nich!
http://katalog.epf.pl/

13

> > You asked for it. So here comes. (; Georeferencing UI is EXTREMELY
> > bad. When I run I.points I also have to open qgis with another map
> > of the same location to get the real co-ordinates
<snip>

> If I understand it well, this is already the way, i.points works(?)

That's i.vpoints I think.

> -- one can open 4 frames in GRASS-monitor -- the left half is used
> for currlently source location, the right half is used for
> displaying maps from target location. it is not necessary to set the
> coordinates by hand, you can "click" them in the target map.

I seem to remember in GRASS 5pre days that i.points would let you use at
least 3 of the four frames for different levels of zooming. These days
only the left two seem to get used?

I wish i.points functionality could be implemented into QGIS
georeferencer plugin... As well as other warping methods, as presently
QGIS provides only Helmert's AFAIR.

..

BTW - that'd be great if Grass could use Gdal warping - the speed and
reliability.

FWIW, GRASS and GDAL's 1st,2nd,3rd order warping are all started out as
the same base code. e.g. they both have the same 3rd order bounds bug.
Difference is that Frank's version was and is better maintained.
Additionally gdalwarp now has a really nice thin-plate-spline warping
method which would be great to use in GRASS. GDAL is a manditory
requirement for GRASS 6, so I am all in favour of ripping out GRASS's
version and using calls to the GDAL warp API instead.

see:
https://intevation.de/rt/webrt?serial_num=3166
https://intevation.de/rt/webrt?serial_num=2952

> > Oh and BTW the CPU spikes
> > up to 100% and my laptop fan starts to go on overdrive everytime I
> > run i.points... Is there a busy loop somewhere in the code?

You haven't heard my laptop yet ;). But what's really bad is that this
bug hampers Grass usability in a network where one machine is a server
for several Grass sessions - imagine all the users trying to use
i.points / other mouse intensive operation in the same time. Has
anybody got an idea how to get rid of this bug?

search the mailing list archives. Trouble (as I understand it) is the
quick-fix-the-symptom solution is to add a usleep() call for a couple of
milliseconds between each check for a mouse event. But the only portable
sleep() function seems to be the one which only lets you sleep for full
seconds, which ruins the responsiveness. A hack solution would be to
check for usleep() or similar and then use if it we have it, otherwise
encounter the 100% cpu usage. That's pretty crappy though.

better to either a) revert the change (no problem in GRASS 5) and/or b)
write something better.

the problem: someone needs to do it.

Hamish

14

Hamish wrote:

> Oh and BTW the CPU spikes up to 100% and my laptop fan starts to go on
> overdrive everytime I run i.points... Is there a busy loop somewhere
> in the code?

It's a long standing bug in GRASS 6 which happens any time you use the
mouse, e.g. d.zoom too.

feel free to fix it!

No, don't!

The mouse interaction aspects of the display architecture totally
suck. The facilities are barely adequate for d.where let alone
anything more involved such as i.points or v.digit.

There is nothing I would like more than to completely remove the
R_get_location_with_* functions from the display architecture at the
earliest possible opportunity.

A far better solution is to move all interactive functionality into
either QGIS, d.m or individual Tcl/Tk programs.

The whole display system would be so much simpler (and easier to
improve) if the (trivial and almost worthless) interactive features
were removed.

E.g. we could kill off XDRIVER and merge the PNG driver into
libraster, so d.* programs can just spit out image files for use by
the GUI. Programs which are currently limited by the minimal
capabilities of the display architecture could use more advanced
techniques for generating the images, e.g. PostScript (via
gs -sDEVICE=pngalpha) or OpenGL (via osMesa).

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