FW: [GRASS-dev] Zooming issue in gis manager

[Michael Barton]

The original post here didn't make it past the list file size filter. So
I've reduced it to one graphic that should make it. I've also done a few
more tests.

In addition to what I mention below, g.region run without the -a flag
creates rounding errors in resolution--minimal but annoying.

Without the -a flag, the number of cells displayed accurately reflects the
actual display region setting. So if you save the display region to the WIND
file, and reset the display to match the new current region (i.e., WIND
file), it looks the same as before. But, as noted below, it does this by
shrinking the cells a bit to make them squeeze into the PPM output created
by the PNG driver (could the X-driver be doing this differently???).

With the -a flag, the number of rows or columns displayed is one or two less
than the number in the display region. This is not noticeable (and maybe
doesn't even happen) when there are a lot of cells in the display, but can
be noticeable when there are very few cells in the display. The result is
that if you copy the display region to the WIND file and display it back
again, you see more cells than you started with. This is the "correct"
number of rows and columns, but it not what was displayed. However, there
are no rounding errors in the resolution as reported by g.region.

Is this all happening in g.region? The display driver? Or both? As I say
below, I can't think of how gis.m could compensate for this. In the region
computation, it would involve 'rounding' to the nearest resolution value.
But how can you round to the nearest 0.0001543 degrees? ...or even the
nearest 25m? There is no 'starting place' to round from, since the region
boundary can potentially be anywhere theoretically.

I'm going to put the -a flag back into gis.m to keep the resolution rounding
errors out. If you want to set region with precision, especially in a
close-up view with few cells showing in a raster, you need to use g.region.
If you want to display a region in a close-up view of a raster, where the
cell sizes are large compared with the display and pixel size, you'll need
to use explore mode for now at least. As documented below and in the
attached graphic, this does a good job of making a display with accurately
rendered raster cells. Vectors either don't face these issues or have
different ones, as they are not behaving parallel to rasters in this.

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


------ Forwarded Message
From: Michael Barton <michael.barton at asu.edu>
Date: Wed, 01 Nov 2006 22:01:24 -0700
To: Glynn Clements <glynn at gclements.plus.com>
Cc: grass-dev <grass-dev at grass.itc.it>
Conversation: [GRASS-dev] Zooming issue in gis manager
Subject: Re: [GRASS-dev] Zooming issue in gis manager

Glynn,

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 [THIS GRAPHIC IS NO LONGER ATTACHED; YOU JUST
HAVE TO IMAGINE IT]

"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
__________________________________________
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>

------ End of Forwarded Message

-------------- 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/15506007/explore_mode.obj