[GRASS5] Bug: vector maps shifted (d.area / d.vect)

[Glynn Clements]

Markus Neteler wrote:

> ... maybe yes - of course we don't want to break the system now.
> But:
>  - d.vect is right
>  - d.area, v.area are wrong
> according to d.rast (and my eyes). 
> So we have to careful where to apply the work-around.

d.vect uses G_plot_line(), and G_plot_line() is wrong. If it happens
to produce the right result, then the 0.5 pixel South-East shift is
cancelling out an equal-but-opposite error elsewhere.

OTOH, if "right" simply means that it matches something else, the
"something else" may be equally wrong.

The fact that removing the shift causes d.vect to match d.area, along
with d.area not having any obvious flaws, strongly suggests that
d.vect is at fault.

BTW, I personally wouldn't consider using r.poly for this kind of test
(i.e. unless it's r.poly that you're testing). The reverse operation
(rasterising) is much more straightforward than feature extraction.

Also, note that "right" is a subjective term when applied to
rasterising geometry. E.g. when filling a polygon, what is the
criterion for setting a pixel to the fill colour? Is it:

a) any part of the pixel lies within the polygon, or
b) all of the pixel lies within the polygon, or
c) the centre of the pixel lies within the polygon, or
d) at least X% of the pixel lies within the polygon, or
e) some other criterion?

Depending upon what you are trying to achieve, any of the above may be
the correct answer.

Also, even when you know what you want, you have to take into account
what you can realistically have. Many primitive graphics APIs
(including X and GD) only allow integer coordinates, so you typically
end up having to modify the geometry (unless you plot individual
pixels).

-- 
Glynn Clements <glynn.clements at virgin.net>