[GRASS-dev] Zooming issue in gis manager

Glynn Clements glynn at gclements.plus.com
Wed Nov 1 20:40:41 EST 2006


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>




More information about the grass-dev mailing list