Maciek,
Thanks for going over this thoroughly. Responses below.
Michael
______________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402
USA
voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
From: Maciek Sieczka <werchowyna@epf.pl>
Date: Mon, 13 Feb 2006 22:40:16 +0100
To: Michael Barton <michael.barton@asu.edu>
Cc: <grass5@grass.itc.it>, <GRASSLIST@baylor.edu>
Subject: Re: [GRASS5] New release candidate 3 of GIS Manager 2
On Mon, 13 Feb 2006 10:02:00 -0700
Michael Barton <michael.barton@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
behaviorand 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!
<snip>
Sticky' zoomingby 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?
let's see what response is to this one
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...
Info display not connected with zoom mode.
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.
Zoom out rectangle give you greater control over you 'unzoom'. With a
zoom-out rectangle, your current map 'shrinks' to fit into the rectangle. So
you can decide to zoom out a little (big rectangle) or a lot (small
rectangle). Or you can use g.region.
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 queryin the vector displayto
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:
0.
"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
then.
Zoom does NOT change resolution, only EXTENTS. In GRASS zoom is controlled
by g.region. Nothing I can do about that. But as per earlier discussion,
this is not a bad thing. Note that each map display now has its own zoom. So
when you change the EXTENTS in one display, it doesn't affect the extents in
another display. I'm not sure what else you could want with this. Zoom
(change extents) and not zoom (don't change extents) at the same time? I
don't understand.
1.
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.
Use the new zoom to current region button. This will zoom to whatever you
have set using g.region. Any redraw will subsequently stay with that region
setting until you change it in some other way.
2.
I. Click "Pan" tool.
II. Left-click+hold button on the canvas but _don't_ drag.
III. Release the button.
Error:
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).
I'll try to fix this.
3.
Resize the "Map Display" window with mouse very _excessively_.
Some of following errors are possible:
Due to the way that GRASS displays work at the moment, if you excessively
resize the window, it will eventually bomb. I don't think this will be a
problem in normal work. But we'll have to see. Until the underlying GRASS
display mechanisms are rewritten, this will be a potential problem. But I
hope it won't be much of an issue really.
---------------------------------------------------------------------
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.
4.
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.
I plan on working on this when I change how maps are composited and
displayed. I agree, it's better to put these into your home director. OTOH,
if you DO have a crash of some kind, your most recent displays can be easily
salvaged as accessible *.ppm files.
Also, these are deleted whenever you close a map display and whenever you
quit the GIS Manager.
5.
Each dipslay action is followed by dozens of:
PNG: GRASS_TRUECOLOR status: TRUE
PNG: collecting to file: dispmon_2.ppm,
GRASS_WIDTH=530, GRASS_HEIGHT=482
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.
No way to fix this until the underlying GRASS display drivers are rewritten.
But given that there is now a nice clean command console and separate output
window included in the GIS Manager, this shouldn't be much of a problem.
Just make the ugly terminal window small since you don't need it much
anymore 
6.
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).
It will change whenever you click on a map display window. You don't have to
redraw. But you do have to select the map display you want to work with. I
don't have it change with random waves of the cursor; you need to actively
select the window. But you only have to click it, not run d.mon select=x1.
7.
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.
As per above, the coordinates under the mouse are for whatever map display
you have actively selected. Otherwise, what would happen if you had
overlapping windows?
8.
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?)
I don't understand what you are doing here.
9.
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
default.
What you suggest is probably possible, though a bit complicated. But is this
a good idea? What do others think?
10.
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...
The map in the canvas is aligned to the upper left for accurate conversion
between screen coordinates and geographic coordinates.
11.
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.
Open 1, 2, 3, 4, 5
Close 2,4
Open a new display.
It's hard to track which has been closed and which needs to be open. Much
easier just to increment at the end of the series. Also avoids potential
problems of duplicating map display numbers (need to be unique for
independent layer trees, region settings, etc.)
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).
I agree.
Hope this is helpful
Michael
Maciek
--------------------
W polskim Internecie są setki milionów stron. My przekazujemy Tobie tylko
najlepsze z nich!
http://katalog.panoramainternetu.pl/
