[GRASS-dev] Vote for your favorite zoom out

Michael Barton michael.barton at asu.edu
Sun Oct 1 02:25:18 EDT 2006

Zooming in with a zoom box is pretty straight forward. But zooming out is
conceptually and computationally somewhat more complex, and is done in
various ways (or not at all) in other graphics/GIS programs.

After working off list on various approaches to zooming out with a zoom box,
I want to give you all several alternative proposals and let you vote on
them. It gives us a chance to try out the voting procedure. I think that
we¹d said that we¹d have 2 or 3 days. Since it¹s the weekend, I¹ll take
votes through Tuesday Arizona time (Markus, if this is too short a time,
please let me know and I¹ll extend it.). I¹ll try to get this in the cvs as
soon as possible after Tuesday.

Vote for options (I¹m willing to do either 1a/b or 2a/b, and personally
favor variants 1a or 2a):

1a: 1+
1b: 0+
2a: 1+
2b: 0+
3:  1-


Here is an explanation of the options:

1a. The current region is fit into the zoom box where the zoom box is drawn:

1b. The current region is fit into the zoom box and centered in the display:

Issues: This is the easiest to explain and the most directly opposite of a
zoom in box (where the box defines the new region extents). The box defines
the amount of zoom in (i.e., new region extents) in both dimensions. The
main drawback is that the resulting region geometry (aspect ratio) is the
inverse of the box geometry. Because the smaller the box, the more the
region is extended (to make the original region appear smaller in the
display). This means that a tall, narrow box will extend the region a lot in
the E-W dimension and less in the N-S dimension, producing a short, wide
region. If we go to this, kind of zoom out, I like 1a because it gives the
user even more control over zooming (kind of zooming and panning in one fell
swoop), though is more complicated. However, if 1b gets more votes, I¹ll go
with that instead.

2a. The box directly defines the geometry of the new region and the box¹s
longest dimension determines the amount zoomed out (how much the region is
extended to make the current map appear smaller). The new region is centered
in the display. That is, a long, short box will produce a long, short region
that is larger than the original region (making the map appear to be

2b. The box directly defines the geometry of the new region and the box¹s
shortest dimension determines the amount zoomed out. The new region is
centered in the display.

Issues: Unlike zooming in, the zoom out is controlled only by a single box
dimension, giving the user less control. However, the resulting region
matches the geometry of the zoom box, with might be more what a user has in
mind. To my mine, 2b zooms out too fast, which is why I prefer 2a. For
example, a long, narrow zoom out box will produce a slightly zoomed out,
long, narrow region with 2a, but a very zoomed out, long, narrow region with

3. The box causes the the display to zoom out, but either does not control
the amount of zoom out (e.g., region is extended by some set amount) or
doesn¹t control the region geometry (e.g., the display window controls the
geometry regardless of the shape of the zoom out box).

Issues: I see no point in going to the trouble of coding a zoom box if it
doesn¹t give a user control over the region extents (i.e., both the amount
of zoom and the resulting region geometry). We already have a nice quick,
1-click zoom in and zoom out that I¹ve cleaned up a bit more over what is
now in the cvs.


In all cases, drawing a zoom out box outside the region extents or a zoom
out box whose geometry is very different from the existing region geometry
may produce visual results that are a little odd, even when the zooming is
following the rules correctly. I can put in some traps for this depending on
the algorithm used. However, in any case, it *will* zoom out, allowing the
user to see more of the map than before and other tools (quick 1-click
zooming or zoom in box) can be used for fine tuning if needed.

So let the voting begin

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

More information about the grass-dev mailing list