[GRASS-dev] Re: gis.m zooming: 2 new bugs

[Michael Barton]

My original (lengthy) explanation was stopped from being posted to the list
for some reason, so I'm attaching it below for reference. Comments in
response to your reply are below.

Michael


__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

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



> From: Maciej Sieczka <tutey at o2.pl>
> Date: Wed, 20 Sep 2006 11:20:17 +0200
> To: Michael Barton <c.michael.barton at gmail.com>
> Cc: Moritz Lennert <mlennert at club.worldonline.be>, grass-dev
> <grass-dev at grass.itc.it>
> Subject: Re: [GRASS-dev] Re: gis.m zooming: 2 new bugs
> 
> Michael Barton wrote:
> 
>> I hope this helps explain what is going on better. What do you think?
> 
> I think that box-zoom-in and box-zoom-out should behave the same. They
> don't - which is a bug in terms of usability. Since box-zoom-in does
> update the region extent properly, taking into account the whole area
> within the zoom box, the box-zoom-out should do that too.

The box zoom-in and zoom-out CANNOT operate the same mathematically, as I
tried to explain below. It is impossible. Given that, the question is what
kind of result do you want to see. Currently, both update the region in both
dimensions exactly as defined by the zoom box. You suggest that it gives
visually undesirable results. Updating the region "properly" is meaningless
(sorry). This depends on what is meant by "properly". I'm not splitting
hairs. The question is what kind of view/display result is desired when a
display tool is used. For any desired result some are possible and others
are not.

The possibility that I *think* you'd prefer is described below also. I kind
of like this better too. It makes the tools behave even more differently
mathematically (and "incorrectly" from the perspective of treating one kind
of zoom box as a user error and ignoring it), but produces a visual output
that is probably more desirable.

> 
> As to single-click-zoom-in it should behave the same as
> single-click-zoom-out, which you have fixed recently. Ie. it should
> only modify the zoom level and not modify the X,Y proportions at all,
> which is unfortuantely happening now.
> 
> The single-click-zoom-in and -out should also center-pan to cursor
> location - simply because the cursor is involved. And since it is, I,
> user, expect it to be significant where I click on the map canvas. If
> we want a zoom tool that doesn't pan-center, it shouldn't involve cursor.

A similar issue is here. We can have a one-click zoom in preserve display
region geometry and zoom to the center of the current region, regardless of
where you click (i.e., decrease all region extents by the same proportion)
OR we can have it zoom in to the spot where you click (the way it works now,
and the way this tool works in other programs), disregarding the display
region geometry. Neither one or the other is the "proper" way to zoom. Both
have advantages and disadvantages. The question is which is most desirable.

> 
> Maciek
> 
> 

Maciej,

I've relooked at the code, math, and concepts behind the one-click and
box-defined zooming and they are behaving in a completely consistent,
logical, and proper way. This doesn't necessarily mean that they are
behaving in the way that you expect, of course. After reading the
explanation below of what is happening with the zooming, I'd like to hear
how you might expect zooming to behave. This might or might not be
realistically doable and might or might not be what others expect. But it
would be good to know in any case.

First, keep in mind that the way that GRASS works, the display acts as a
fixed-size window on the region. Zooming varies the region, not the window.
Every time the map is displayed, we calculate the number of pixels needed
(height and width) to create graphic PPM image of the size to exactly fit
into the display window so that all of it is visible in normal mode. In
'explore mode' the region is reset so that the extents are proportional to
the display window geometry and the resolution equals the number of pixels
needed to make a graphic file that exactly and completely fills the display.

1) When you draw a zoom in box, we calculate the n,s,e,w extents of the box
in geographic coordinates. Then the display region is reset to match those
extents. Finally the calculations are are done as above to create the
graphic file to display in the window.

2) When you do a one-click zoom in, there is no box drawn. A virtual box is
drawn, 1/(square root of 2) * the current screen height and width. The box
is centered on the place where you click, allowing you to zoom in to a
particular spot. The region extents are set to match this box, as described
above. There is no apriori way to know what kind of zoom box a user might
actually want but this is a reasonable way, given that no zoom box is drawn,
although it is not the only way to calculate this zoom box. Zooming could
also be done to simply set the new extents this same fraction of the
previous extents. Essentially, this zooms into the center of the current
region, regardless of where you click. One-click zoom out works this way in
reverse. However, this does not let you zoom in to a particular spot. It
seems to me that zooming in to the spot where you click is probably more
useful than zooming to the center of a region that maintains a constant
proportion. Keep in mind, too, that what you see is not what you get in
terms of the computational region--which does not change on zooming
anymore--it's just what you see.

3) When you draw a zoom out box, the calculations are quite a bit different.
With a zoom in box, the box defines the new display region extents, and the
region then just displayed so that it fills the window. For a zoom out box,
the box does NOT define the new extents. Rather, it is necessary to
calculate new extents that are sufficiently large that the currently
displayed region will fit into the box. This is done first by calculating
the geographic e-w and n-s dimensions of the zoom out box. Then the ratio of
the zoom out box extents to the current region extents are calculated for
the 2 dimensions. Finally, the region is expanded in each of the 4
directions by the distance between the current extent and corresponding zoom
out box extent multiplied by the ratio between the zoom box and region
dimension. This sounds (and is) a bit complicated, so here is an example. 

current region E extent = 200
zoom out box E extent = 100
ratio of zoom out box E-W dimension:region E-W dimension = 2.0
The new region E extent = 200 + (2.0 * (200-100)) = 400

This makes the original region fit inside the zoom out box. In your example,
however, you drew a zoom out box that was smaller than the current region in
the N-S dimension and larger than the current region in the E-W dimension.
So what happened? It did exactly as described above. Because the E-W
dimensions of the zoom out box were larger than region extents, it did not
increase the region much in the E-W dimension. Compare the example below
with the example above.

current region E extent = 100
zoom out box E extent = 200
ratio of zoom out box E-W dimension:region E-W dimension = 0.5
The new region E extent = 200 + (0.5 * (100-200)) = 150

However, it DID increase the N-S region by a much larger amount. This makes
a region with a height to width ratio even greater than before. That is, 
you've drawn a box that increases the N-S extents by a lot more than the E-W
extents. (You can only do that if you make a tall, narrow region to begin
with and then draw a zoom out box that is shorter than the N-S region but
wider than the E-W region.) Then, in order to make the new, taller, thinner
region visible in the display, we must calculate a graphic with the proper
pixel height/width ratio. So the result is a taller (possibly with white
space if the raster information does not extend to the new region extents),
thinner map being displayed.

So the question is, how should a zoom out box that is smaller than the
current region in one dimension but larger than the current region in
another dimension behave? In one sense, such a box isn't even meaningful.
The more important question is, what is a  user potentially trying to
achieve when drawing such a zoom out box given that zoom in GRASS is done by
resetting the region extents, not by changing the view window? One
possibility is treat this as a user error and only allow zooming out in a
dimension if the box is smaller than the current region in that dimension.
Although this means that one or both dimensions of a user zoom box will be
ignored, I'd recommend this if we want to change the zoom out behavior. It
gives results that can appear to make more sense visually, although they are
incorrect mathematically.

4) Finally, we get to one-click zoom out. This simply increases the current
region extents by a set amount (the square root of 2). Unlike zooming out,
it does not recenter the new region on the mouse click. Unlike zooming in,
where you are seeing smaller and smaller space in the display window, you
will always see the locale  where you clicked when you zoom out because the
window will show a larger geographic extent. Recentering with zoom out can
also produce results that appear visual strange, although they are
mathematically correct.

I hope this helps explain what is going on better. What do you think?

Michael

On Sep 19, 2006, at 9:03 AM, Maciej Sieczka wrote:

>   
> 
> Moritz wrote:
>  
>>>  >> Well, this is not really using the zoom-out box the way it should be: in
>>>  >> zoom-out mode, you draw a box to show at which size you would like the
>>>  >> currently displayed portion to be after zooming. So if you draw a box
>>>  >> which is larger then the currently displayed portion, you actually are
>>>  >> zooming in...
>>>  >>
>>>  >> So, in my eyes this is not really a bug, but maybe there could be a
>>>  >> check and a warning: "WARNING: your zoom-out box cannot be larger than
>>>  >> the currently displayed region" or something like this.
>  
>  Michael wrote:
>>  > Moritz is correct. AFAICT from the animation (which is quite helpful, by
>> the
>>  > way), the zoom out box is working exactly as it should. The region is
>>  > "shrinking" to fit in the box.
>  
>  I absolutely don't agree. Re-do the situation but use area zoom-IN
>  instead of zoom-OUT. In spite that you select an area *outside* your
>  initial display extent, the result looks OK - the extent is changed as
>  well as the zoom level.
>  
>  With either zoom-out or zoom-in, if I include an area outside of my
>  current display extent within the zooming rectangle, the resulting
>  region should include this area too. Currently zoom-in does it, while
>  zoom-out does not. The difference makes tools bahave inconsistently.
>  Zoom-in works OK while the zoom-out behavior is counter-intuitive and
>  should be regarded as an usability bug.
>  
>>  > Given the zooming situation, the result looks weird.
>  
>  Because the tool works weird. If it worked OK, the result would look OK.
>  
>  Maciek
>  
>   
>   

 

____________________

C. Michael Barton, Professor of Anthropology

School of Human Evolution and Social Change

PO Box 872402

Arizona State University

Tempe, AZ  85287-2402

USA



Phone: 480-965-6262

Fax: 480-965-7671

www: <www.public.asu.edu/~cmbarton <http://www.public.asu.edu/~cmbarton> >