[GRASS5] New release candidate 3 of GIS Manager 2

Tue Feb 14 15:12:17 EST 2006

On Mon, 13 Feb 2006 15:11:55 -0700
Michael Barton <michael.barton at asu.edu> wrote:

> > From: Maciek Sieczka <werchowyna at epf.pl>
> > Date: Mon, 13 Feb 2006 22:40:16 +0100

> > Better, as to me. But still it is not a continous zoom mode, like it
> > used to be. <SNIP>

> let's see what response is to this one

So far the only responses I can see are for the old behaviour. But this
might not mean anything. I bet you know people who prefer the new
behaviour.

> >> 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.

I don't understand. Can you explain?

> > 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).

I don't find this any helpfull in practice. Maybe it is only me.

> > 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.

But it really DOES change the region. Try for yourself:

1.
$ g.region rast=u65_10k_rogow -ap
projection: 1 (UTM)
zone:       33
datum:      wgs84
ellipsoid:  wgs84
north:      5681438
south:      5676368
west:       596952
east:       603815
nsres:      1
ewres:      1
rows:       5070
cols:       6863

2.
Display in gis.m, zoom in once.

3.
$ g.region -p
projection: 1 (UTM)
zone:       33
datum:      wgs84
ellipsoid:  wgs84
north:      5679541.73929
south:      5678636.76827
west:       600274.248772
east:       601286.741103
nsres:      0.99996798
ewres:      0.99949885
rows:       905
cols:       1013

As you can see the resolution changed. Please don't do it.

> controlled by g.region. Nothing I can do about that.

Use "g.region -a" instead?

Who can say what d.zoom is doing that it is not changing the res at
zooming in/out?

> 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.

Change the extents as needed - that's what the zoom tool is for. But
don't touch the resolution.

v.digit in Grass=>5.7 is doing the same - changes the resolution, which
leads to crashes when the res get's rapidly finer (I guess), and is a
bad thing in general - e.g. the perception of features in the displayed
raster layer changes during zooming in an unpredictable, non-intuitive
way. See:
https://intevation.de/rt/webrt?serial_num=2962
https://intevation.de/rt/webrt?serial_num=3047

> > 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.

Ahh. I see. Will have to get used to 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. 

Do you mean it should happen as well with gis.m "Map Displays" as with
old monitors? With old monitors it never happens for me, no matter what
a saddist I am...

> > 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 ;-)

Naah, Grass is more powerfull in connection with Unix commands and
variables and Bash.

> > 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.

Right! Thanks! I was only clicking the "Map Display" window title bar,
thought this should be enough. And - could it be enough? Would improve
things I believe.

> > 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.

See the attached screendump: don't let the buttons (1) get hidden when
the slider (2) is drragged to the bottom.

> > 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?

Provided that every single other day turns ourselves into somewhat
different persons, to some extent, today I'm the other one who answers
it is deffinetely a good idea.

> > 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.

I see. Pitty tough.

> > 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.)

Right.

Thanks for reading this and taking care of the issues.

Cheers
Maciek

--------------------
W polskim Internecie s? setki milion?w stron. My przekazujemy Tobie tylko najlepsze z nich!
http://katalog.panoramainternetu.pl/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: otherwords.png
Type: image/png
Size: 13530 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/grass-dev/attachments/20060214/a39a4c24/otherwords.png