[GRASS-dev] Re: gis.m zooming: 2 new bugs

[Maciej Sieczka]

Michael Barton wrote:

> This is getting close to finding out what it is you are wanting to see.

Michael,

It's not about me "wanting to see", but about fixing an issue that
hampers gis.m. I wouldn't bother messing with nice folks just to
enforce some silly feature everybody could live without.

>> That's not what I mean. I mean that the geometry must be preserved
>> exactly the way I set it by drawing the zoom box.

> So in the example you gave what is it that you think ought to be displayed.
> I'm not trying to be a problem, but this is unclear.
> 
> You first used a zoom in box to set a region geometry that was tall (N-S)
> and narrow (E-W). So far so good.
> 
> Then you draw a zoom out box that is smaller in the N-S dimension than the
> current region and larger in the E-W dimension than the current region.

Correct.

> The algorithm increases the N-S region extents so that the parts of a
map at the
> previous north and south edges now fit into the box that you drew on the
> screen.
> 
> What is it you think should happen with the E-W given the box you've drawn?

It should be extended accordingly, like N-S is, including the invisible
part od the display (beyond the region, to the E). So that the
resulting region reflected the proportions of the zoom box.

>> Currently in gis.m,
>> using box-zoom-out, this geometry is preserved OK only when I don't
>> include a part of an empty map canvas in my zoom box. But if I do that,
>> the part of my zoom box that overlaps this empty canvas is not taken
>> into account, so the geometry is set wrong (ie. not the way I drew the
>> zoom box), thus the resulting region extent is also wrong.
>>
>> Is it impossible to fix that?
>>
>>> It would help to know if you are actually trying to achieve some kind of
>>> meaningful result and what that is, or if you are just trying out tools in
>>> various circumstances.
>> No, I'm not teasing you for fun.
>>
>>> I'm have set the zoom out box tool to treat the case of a zoom out box
>>> larger than the current region as undefined, so that it does not change the
>>> display region in that dimension (it won't produce an error). This will
>>> probably give you the visual effects you are looking for, but I'm not sure.
>> IMO the patch should be reverted. It doesn't fix the problem. The issue
>> is that geometry is not handled properly if the zoom box overlaps an
>> empty map canvas when box-zooming-out, which, as result, leads to a
>> bogus region.
> 
> It's not a matter of whether the area is empty (i.e., there is no map data
> there), it's where the edge of the region is located.

Correct. I mean the greyish, "empty" part of the display canvas. The
map data are there under the greyish part, but they are not displayed
due to the region extent.

>> As such situation (zooming over an empty map canvas) is handled OK in
>> the box-zoom-in, I suppose it could also be fixed for box-zoom-out.
>>
>> If I still haven't made myself clear in this email, please ask me on.
> 
> Even though zooming in and out with a box drawn on the screen appear to be
> very much the same, they are not mirror images of each other. The underlying
> algorithms to change the region are very different.
> 
> Try the change to mapcanvas.tcl and see what you think.

I tried it and told you what I thought in my previous email. Have you
read that?

Maciek