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

[Glynn Clements]

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?

If you treat the boundary as an area, then the area which d.vect will
fill is exactly the region, i.e. inside the boundary == inside the
region. But is the boundary itself inside the region?

I'm aware that this may be counter-intuitive, but that isn't the same
thing as being wrong. The problem is that I don't see how to change
this without creating more significant problems.

> And if this doesn't
> happen (as it is currently), I start wondering whether there could be a
> bug in v.in.region, or g.region, or d.vect an so on. Waste of time,
> less trust in GRASS, bogus bug reports etc.
> 
> If it is possible to fix that without too much effort, I would be for it.

How do you propose "fixing" this case without breaking more sensible
cases. Bear in mind that this is (quite literally) a "boundary case".

> > This doesn't allow for thick lines, where the path itself (i.e. the
> > centre-line) might lie just outside the region but the "stroke" can
> > still be visible. It also doesn't allow for the fact that the tiniest
> > rounding error might push the path outside.
> > 
> > Note that the clipping/culling code doesn't make any allowance for the
> > line width. It can't; it doesn't know the line width (R_line_width()
> > does directly to the driver; the display library doesn't get to see
> > it).
> 
> Propably I did not understand something, but as I can see render=c/l
> work well together with width= in d.vect. Did you mean something else?

They only work because:

a) I tweaked the clip/cull tests slightly (changed <0 to <=0), and

b) the coordinates of the region's boundary are integers, so
converting from cartographic coordinates to display coordinates
doesn't suffer from rounding error.

Had the right-hand edge been given a display X coordinate of
640.000001, render=c/l would have discarded the edge, as it lies
entirely outside the region.

The fact that part of the "stroke" (the filled area centred upon the
actual line) would still be visible isn't taken into account when
clipping/culling, as the display library doesn't know about the line
width.

That's why I say that there needs to be a D_line_width() or D_margin()
or similar, so that the clipping/culling code won't discard edges
which lie only just outside the region.

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