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

[Maciej Sieczka]

Glynn

Thank you for looking into this. Please read below.

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

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

Maciek

P.S.

If this is usefull, Hamish made some guess about a possible nature of
the problem about a year ago; please read on
http://intevation.de/rt/webrt?serial_num=3613, message dated: Thu, Sep
8 2005 02:48:20.