[GRASSLIST:10281] Re: [GRASS5] New release candidate 3 of GIS Manager 2

[Michael Barton]

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 at epf.pl>
> Date: Mon, 13 Feb 2006 22:40:16 +0100
> To: Michael Barton <michael.barton at asu.edu>
> Cc: <grass5 at grass.itc.it>, <GRASSLIST at 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 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!
> 
> <snip>
> 
>> Œ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?

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 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:
> 
> 
> 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/
>