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

[Glynn Clements]

Maciej Sieczka wrote:

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

No. I mean that one pair (both horizontal or both vertical) will
normally be visible, while the other two should each have a 50/50
chance of being visible.

In the latter case, various factors may combine to affect the actual
ratio. E.g. the fact that the transformation is rooted at the
north-west corner will typically mean that the top/left edges always
result in an exact zero, producing the same result every time.

As with anything related to floating-point, the architecture and any
compilation options may affect the outcome.

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

This is correct behaviour. One pair of region edges will always
exactly touch the corresponding edges of the frame, while the other
pair will usually have a margin.

For an edge which exactly touches the frame, any line which follows
that edge will get clipped down the middle.

If the aspect ratio of the region exactly matches that of the frame,
all four edges will coincide, and all four lines should be half-drawn.

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

No, I mean that anything else would be 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.

No, I mean that it's a case where a "point" is neither inside nor
outside but on the boundary.

The term doesn't refer solely to geometry. In any context where some
continuous (non-discrete) space is partitioned into distinct
categories, you get values which fall on the boundary between
categories. E.g. if you partition the real numbers into positive and
negative, which is zero?

-- 
Glynn Clements <glynn at gclements.plus.com>