[GRASS-dev] d.vect render= and corrupted vector display

[Maciej Sieczka]

Glynn Clements wrote:
> Maciej Sieczka wrote:
> 
>>>>> I've changed the clipping/culling code to handle this particular case
>>>>> (i.e. use <= 0 rather than < 0), so #4 and #5 now match the other
>>>>> three.
>>>>> Beyond that, the main issue is that the code which sets up the
>>>>> coordinate mapping (D_setup/D_do_conversions) maps the current region
>>>>> to the current frame *exactly*, without any margin. This is arguably
>>>>> the right thing, even if the net result isn't always ideal (and the
>>>>> result of v.in.region is the worst possible case).
>>>> Don't you think it is confussing for the user? If I do v.in.region, I'm
>>>> right to expect that the whole vector will be displayed when my working
>>>> region matches the v.in.region's output extent.
>>> Hmm; not really. v.in.region generates a vector map corresponding to
>>> the region's boundary. d.vect displays the portion of a vector map
>>> which lies inside the region.
>>>
>>> Is a region's boundary *inside* the region?
>> 1. This is not a boundary, but a line (v.in.region output=frame type=line).
> 
> Note that I mean "boundary" in the general sense, not specifically
> GV_BOUNDARY.
> 
>> 2. Even if it was a boundary - either the *whole* boundary should be
>> displayed, or not. Currently, 75% of the boundary is displayed, while
>> the other 25% is not. This looks strange to the user.
> 
> Typically, two of the region edges will be coincident with the
> corresponding edges of the display frame, while the other two won't

Do you mean that either both horizontal or both vertical lines should
be not visible on display? I don't confirm. Alway a single line is
missing - either the bottom, or the right side edge, depending on the
with X monitor windows's aspect ratio. (Talking of d.vet width=1 here.)

To reproduce:

1. v.in.region output=frame type=line
2. d.vect frame
3. play with X monitor windows's aspect ratio

> (unless the region's aspect ratio exactly matches that of the display
> frame).

If you mean that in such case all edges should be displayed, I don't
confirm. To reproduce:

1. g.region n=4926750 s=4914430 w=594880 e=607200 res=10 -ag
(results is a square region)

2. d.mon x0; d.resize width=320 height=320
(square X display)

3. v.in.region square type=line; d.vect square
(only left and top edge are displayed)

> For a vertical or horizontal line segment which is concident with an
> edge of the display frame, it's essentially a 50/50 chance as to
> whether that edge will lie inside or outside the frame; even the
> slightest rounding error can decide it. Note that it is not guaranteed
> that (x/y)*y == x when using floating point.
> 
> If you go out of your way to create lines which lie exactly on a
> boundary, the results are bound to be unpredictable. Unfortunately,
> that's exactly what v.in.region does.
> 
> Ultimately, the only solution is to stick to even line widths (i.e. 
> width=2, width=4 etc), or use the PS driver. Then you're guaranteed to
> get exactly half of a line on each side (if you don't, that *is* a
> bug).

Hmm. With line width=1 I get the effect as described above. With width
2 or 4 I get the effect that either both horizontal or both vertical
edges (depending on the with X monitor windows's aspect ratio) are
twice that thick as the other pair of lines. If it is not clear what I
mean, please look at the attached screenshot of d.vect frame width=2.
Do you mean this is a bug?

>>> Bear in mind that this is
>>> (quite literally) a "boundary case".

>> I don't agree. This issue might bias user's understanding of GRASS'
>> region, which is not trivial:

> That doesn't have any effect upon whether this is a boundary case.

By "boundary case", do you mean to assume that v.in.region+d.vect is
unlikely to be used? Just curios.

Maciek

-------------- next part --------------
A non-text attachment was scrubbed...
Name: horizontal_edges_thinner.png
Type: image/png
Size: 1862 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/grass-dev/attachments/20070409/1dddaa9f/horizontal_edges_thinner.png
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vertical_edges_thinner.png
Type: image/png
Size: 933 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/grass-dev/attachments/20070409/1dddaa9f/vertical_edges_thinner.png