[GRASS5] New release candidate 3 of GIS Manager 2

Maciek Sieczka werchowyna at epf.pl
Mon Feb 13 16:40:16 EST 2006

On Mon, 13 Feb 2006 10:02:00 -0700
Michael Barton <michael.barton at asu.edu> wrote:

> I just committed to the CVS and posted to my website
> <http://www.public.asu.edu/~cmbarton/files/grass_gismgr> the
> (hopefully) final release candidate for the new GRASS GIS Manager. It
> has many updates. I think I've fixed all reported bugs or anomalous
> behavior‹and a number of unreported ones. A few of the highlights.
> A fix for the Œblack canvas that some people have been getting.

Is OK now, great!


> ŒSticky' zooming‹by popular demand.

Better, as to me. But still it is not a continous zoom mode, like it
used to be. Could this be brought back as well? For now one has to
re-click the zoom button to do another zoom, and once more, and once
more... This is not optimal I believe. In my practice I'm almost never
satisfied with the first zoom, so I need to re-click zoom button several
times until I set up the view as needed. Or think of a situatioan
when you want to zoom in and out quickly back to bring back the
context. While in the continous zoom this was avoided, all you had to
do was to click right mouse button to quit the zooming tool once you
are done. Who else preffered the old mode?

> show up in the status area at the bottom of the screen instead of a
> little message window that  you have to click to get rid of.

Now I see what was your intention. But was this really such a big
problem to single right-click once you are done? In my opinion having to
re-select the zoom tool (move mouse pointer, click) several times
agian and again is much worse...

Moreover, I don't understand why I need to select a rectangle to
_unzoom_. Am I missing something? Zoom out tool should... zoom out
once I click the button, why select region and confirm? Too much mouse
action for no purpose, I think.

> A few added convenience features. The one I like the best was
> inspired by Peter Misovic's questions about displays and queries. You
> can now save the results of a display query‹in the vector display‹to
> a new vector file (using v.extract).

I haven't used that yet, but sounds cool!

> Thanks for all the suggestions and testing. When this release
> candidate goes through testing and any remaining bugs are removed, I
> hope to make this the default GUI for GRASS.

More problems I can see:

"Zoom" tools, "Redraw" and other change region resolution! This is a
very bad idea IMHO. Why should they? Once I set up the region
resolution it should be changed only at my request I believe, and only

I. Display anything.
II. Zoom in -> current region changes.
III. Run g.region, redraw in gis.m -> g.region changes get discarded.

Why does gis.m doesn't honour the changes in current region any other
than those of his own? Doesn't make sense to me.

I. Click "Pan" tool.
II. Left-click+hold button on the canvas but _don't_ drag.
III. Release the button.

can't read "to_x": no such variable
can't read "to_x": no such variable
    while executing
"scrx2mape $to_x"
    (procedure "MapCanvas::pan" line 11)
    invoked from within
"MapCanvas::pan $mon"
    (command bound to event)

My destop switcher freezes, using over 90% CPU, have to kill and
restart it to continue Gnome operation (Ubuntu 5.10 Breezy/Gnome).

Resize the "Map Display" window with mouse very _excessively_.
Some of following errors are possible:
ERROR - eof from graphics monitor.
ERROR - eof from graphics monitor.
    while executing
"close $input"
    (procedure "MapCanvas::drawmap" line 44)
    invoked from within
"MapCanvas::drawmap $mon"
    (procedure "MapCanvas::do_resize" line 12)
    invoked from within
"MapCanvas::do_resize 3"
    ("after" script)
can not find channel named "couldn't execute "d.mon": too many open
files" can not find channel named "couldn't execute "d.mon": too many
open files" while executing
"close $input"
    (procedure "MapCanvas::drawmap" line 44)
    invoked from within
"MapCanvas::drawmap $mon"
    (procedure "MapCanvas::do_resize" line 12)
    invoked from within
"MapCanvas::do_resize 5"
    ("after" script)
can't read "map_e": no such variable
can't read "map_e": no such variable
    while executing
"expr abs(1.0 * ($map_e - $map_w))"
    (procedure "MapCanvas::mapsettings" line 33)
    invoked from within
"MapCanvas::mapsettings $mon"
    (procedure "MapCanvas::do_resize" line 11)
    invoked from within
"MapCanvas::do_resize 5"
    ("after" script)
couldn't create pipe: too many open files
couldn't create pipe: too many open files
    while executing
"exec g.gisenv get=GRASS_MESSAGE_FORMAT"
    (procedure "run_panel" line 4)
    invoked from within
"run_panel $cmd"
    (procedure "GmVector::display" line 95)
    invoked from within
"GmVector::display $node"
    ("vector" arm line 2)
    invoked from within
"switch $type {
        group {
            GmGroup::display $node
		raster {
			GmRaster::display $node
		labels {
			GmLabels::display $node
    (procedure "GmTree::display_node" line 6)
    invoked from within
"GmTree::display_node $n"
    (procedure "GmGroup::display" line 14)
    invoked from within
"GmGroup::display "root""
    (procedure "MapCanvas::drawmap" line 31)
    invoked from within
"MapCanvas::drawmap $mon"
    (procedure "MapCanvas::do_resize" line 12)
    invoked from within
"MapCanvas::do_resize 5"
    ("after" script)

The result is the same as in case #2. - desktop switcher freezes, using
over 90% CPU, have to kill and restart it to continue Gnome operation.

gis.m creates many "dispmon_1.ppm" like files in my $HOME. Please don't.
It is my $HOME. This issue was already pointed out by someone else I
recall. Grass TEMP should be used instead.

Each dipslay action is followed by dozens of:

PNG: collecting to file: dispmon_2.ppm,
Graphics driver [gism] started
Monitor 'gism' terminated

in the terminal. I recall you explained it this is due to d.mon design
and nothing you could do about it in d.m. Still? Could these be send
to /dev/null or whatever? This is really bad.

Separate layer trees is a great thing. But, the given "Map Display"
layer tree is not updated in main gis.m window until I redraw in the
given "Map Display". Could it be updated once the given "Map Display"
window is only selected with mouse? Would be much better. Current
behaviour is problematic and time consuming. Say there are 3 "Map
Displays". Which one is the one I need? Let's see. (30 seconds of
rendering). Nope. Maybe this one. (Another 15 seconds). Must be the 3rd
one then... yes! Only 1 minute and all sorted out ;o).

When I move my mouse pointer over _any_ "Map Display" canvas, the cursor
position is _still_ printed in the _currently_ active "Map Display"
window, while it shouldn't. And it is calculated as if _any_ map canvas
was an extension of the _current_ map canvas.

The "run", "clear", "save", "open output window" buttons in the bottom
of main gis.m window get hidden when I drag the layer display
options window to the bottom. Could they be permanent, not possible to
hide? (We don't want to hide them, what for?)

New layers are still added in the very end of the list, like in d.m.
This requires going down to the end of the list and dragging the layer
to it's destination. Pain. Could this be avoided in gis.m? Adding it
right after the currently highlited layer should be a reasonable

The display within "Map Displays" is always alligned to left. In old 
display monitors it is centered. Is there a reason for the change?
Centering looks more natural to me than alligning the display to either
side of the canvas...

I. Open new "Map Display". It is no 2.
II. Close "Map Display" no 1.
III. Open new "Map Display". It is no 3. But shouldn't it be the first
umber available, which is no 1 one then? Just asking, not sure myself.

> Along with this, I'd encourage updates to additional modules to make
> this all work even more seamlessly. For example...
> -a new i.gcp module to replace i.points and i.vpoints. i.gcp would
> accept input coordinate pairs x1,y1,x2,y2 (for existing point
> coordinates and desired georeferenced coordinates), manage the ascii
> points file, and calculate rms errors. Graphic could be handled by a
> GUI.

In addition to this, IMVHO it would be cool to have the Grass5
d.fix.ortho funtcionality included - which is to move a layer to
another location interactively, based on 1 point source an target
location only. I'm finding it usefull from time to time, when the
raster is already warped but not georeferenced, and r.region is too
much hassle or impossible - eg. only the inner part of the image is
properly warped, while the outer part is deformed (due to bicubic
warping of an image with too little GCPs at it's edge).


W polskim Internecie są setki milionów stron. My przekazujemy Tobie tylko najlepsze z nich!

More information about the grass-dev mailing list