[GRASS-dev] Zooming issue in gis manager

[Maciej Sieczka]

Glynn Clements wrote:
> Maciej Sieczka wrote:
> 
>>> This sounds like there is no good reason to set this for interactive zooming
>>> by default. If someone wants to use this feature, they could explicitly set
>>> it in g.region.
>> gis.m zoom tools should preserve the resolution while zooming, and set
>> the region extents properly. That's because there are tools in gis.m to
>> set WIND to match gis.m display, and to make the display match the
>> current region - thus these two operations should not lead to region or
>> display settings the user not wanted. The problem is that they do, because:
>>
>> 1. If -a is not used in g.region calls in mapcanvas.tcl (like it was
>> originally, few months ago), the gis.m zoom tools don't preserve the
>> resolution while zooming; and I don't see a reason why the resolution
>> should change while zooming, but do I see obvious reason why it
>> shouldn't. Thus, I suggested a solution: use the g.region with -a. It
>> fixed the resolution issue.
> 
> While -a will preserve the resolution, it does more than that. It
> doesn't just force the size of the region to be an exact multiple of
> the resolution, but also forces its position to be an exact multiple
> of the resolution.
> 
>> 2. But, now it showed that if g.region -a is used in mapcanvas.tcl, the
>> region extent is often not set properly. This is not acceptable either,
>> is it?
>>
>> Removing the -a flag should fix issue 2, but it will bring the issue 1
>> back. What do we do then?
> 
> 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?

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.

> 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.

> 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?

Maciek