[GRASS-dev] Zooming issue in gis manager

Michael Barton michael.barton at asu.edu
Thu Nov 2 00:01:24 EST 2006


This may not be the issue, but it does illustrate what you are talking
about. I've shrunk the images quite a bit in the hopes  they make it by the
developer list filter.

Both images are close-ups of Spearfish elevation_dem, with a 30m vector grid
drawn over it (origin at 0,20 to make it align with the raster cells).

G.region is run without the -a flag in both examples.

"normal_mode.jpg" shows the map grid cells in the "normal" display mode that
preserves resolution in the display region settings. Note the 30m resolution
at the bottom of the display

"explore_mode.jpg" shows the same part of the map in the "explore" mode that
greatly increases resolution when zoomed in like this. Note the 0.7m
resolution at the bottom of the of the display.

The overlaid vector grid ought to line up with the cells. In explore mode it
does line up, because the 30m "cells" of the original DEM are actually
composed of >1800 cells in this close-up display. D.rast is aligning with
the tiny new cells, not the original 30m cells, and this is not noticeable
because the new cells are so small compared with the display and pixel size.

In normal mode, the grid cells are indeed 30x30m and d.rast does whatever it
does to squeeze an integer number of cells into the display. This is
noticeable because the cells are large relative to the display. The vector
grid does not line up with the cells.

I have no idea how the GIS Manager displays could compensate for d.rast
behavior like this, though it only is a problem when the cell size is very
large compared to pixel size. Ideally, I guess it should always "snap" to
the grid resolution when displaying rasters (vectors seem to be another
matter). But I haven't the foggiest notion of how this could be done with
continuously variable window sizing and zoom box sizing. I'm not even clear
if this is better done when setting the display resolution somehow (but what
happens if you set the display to match the WIND file or a map?), or if this
should be done when coming up with output PPM geometry (but how do you make
it fit a canvas then?). If someone wants to give it a try, more power to
them. Fortunately, the explore mode approach works quite nicely to produce a
display of zoomed in cells that is precisely rendered. If you want to set
the computational region from the display, switch to normal mode first (I
took out the -a switch today, so this is working fine in that the region
gets set to what it appears to be in the display); then switch back to
explore mode to look at it.

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: Glynn Clements <glynn at gclements.plus.com>
> Date: Thu, 2 Nov 2006 01:40:41 +0000
> To: Maciej Sieczka <tutey at o2.pl>
> Cc: Michael Barton <michael.barton at asu.edu>, grass-dev
> <grass-dev at grass.itc.it>
> Subject: Re: [GRASS-dev] Zooming issue in gis manager
> Maciej Sieczka wrote:
>>> I think that the core problem is that d.rast cannot render an
>>> arbitrary portion of a map; the rendered image has to be aligned to
>>> the cell boundaries.
>> Thanks Glynn. Another question - so how does is happen that the X
>> monitors don't have that problem, while gis.m displays do?
> X displays have exactly the same problem. gis.m might have some
> *other* problems, but the d.rast/libdisplay issue I was discussing
> applies regardless.
>> I mean:
>> 1. When I set a region to match, say, 5 cols/6 rows (using g.region)
>> and d.rast on X monitor - I see 5 cols/6 rows of a raster.
>> 2. And when I use d.zoom and set the display on X monitor so that I
>> see, say, 3 cols/7 rows, and I do g.region -p - I see that my region
>> indeed has 3 cols/7 rows, and the resolution has not changed while zooming.
>> But when gis.m interacts modifies WIND to match it's display, we have,
>> either, only the resolution, or only the number or rows and cols set
>> properly, depending on if the g.region is used with or without -a.
> I would guess that d.zoom adjusts the bounds manually, whereas gis.m
> uses "g.region -a". The latter does more than just preserve the
> resolution; it also aligns the grid with the coordinate system's
> origin, then aligns the bounds with that grid, rounding outwards (i.e.
> enlarging the region).
> Thus, "panning" (moving the region without changing the e-w or n-s
> differences) with "g.region -a" will change the size of the region if
> the requested bounds aren't aligned to the grid, as it will round
> opposing edges in opposite directions.
>>> The region always has an integer number of rows and columns. d.rast
>>> always ensures that the entire region just fits inside the frame; one
>>> pair of edges will always exactly touch the corresponding edges of the
>>> region.
>>> Thus, the rendered image will only ever show whole cells. You will
>>> never get a situation where part of a cell is shown and the other part
>>> cropped.
>> But I don't even want it. I'm saying that gis.m interaction with WIND
>> must not corrupt the resolution or the number of rows and cols. If that
>> is not possible, then we should not ask people to use gis.m yet. Or
>> disable the WIND<->gis.m interaction alltogether.
> So, you're complaining about the fact that preserving the resolution
> means moving the bounds outwards by up to 1 cell in each direction,
> right? Or something else?
> If it's the former, gis.m will need to adjust the bounds itself; there
> isn't any g.region option which will do the right thing (it's possible
> that this was what -a was supposed to do; it would make more sense
> than the existing behaviour).
> If it's the latter, you'll need to explain more clearly.
>>> At magnifications significantly above unity, this is likely to be
>>> problematic for interactive zooming. You either have to adjust the
>>> bounds so that they aligh with the existing cell grid, or adjust the
>>> resolution so that the cell grid aligns with the bounds.
>> So having both bounds and resolution preserved when gis.m interatcs
>> with WIND is not possible, is that what you mean?
> The distance between opposing edges has to be an integer multiple of
> the resolution (i.e. the number of rows and columns must be integers).
> But that should be true even within gis.m. It's possible that gis.m
> fails to enforce this requirement, in which case, it will end up being
> enforced whenever gis.m interfaces with the rest of GRASS, either by
> adjusting the bounds to fit the resolution or by adjusting the
> resolution to fit the bounds.
> That isn't limited to updating the WIND file; it will also affect
> rendering. If gis.m is reporting region parameters which don't satisfy
> the "integer multiple" requirement, it's lying; the numbers will get
> "corrected" as soon as they leave gis.m.
> -- 
> Glynn Clements <glynn at gclements.plus.com>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: normal_mode.jpg
Type: application/octet-stream
Size: 44412 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/grass-dev/attachments/20061101/94f6e0e8/normal_mode.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: explore_mode.jpg
Type: application/octet-stream
Size: 43062 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/grass-dev/attachments/20061101/94f6e0e8/explore_mode.obj

More information about the grass-dev mailing list