[GRASS-dev] [bug #2765] (grass) v.buffer produces strange results

[tlaronde at polynum.com]

On Sun, Nov 26, 2006 at 10:38:08PM +0100, Maciek Sieczka via RT wrote:
> 
> $ v.out.ascii ditch_1205 form=standard | awk 'NR>10'
> B  4
>  600727.68682251 5677973.32091602
>  600739.16582305 5678137.49568095
>  600736.32863997 5678140.4618269
>  600730.63832718 5678056.67823368
> B  2
>  600730.63832718 5678056.67823368
>  600725.02385533 5677974.01131491
> C  1 1
>  600730.04890192 5678035.56666655
>  1     1205
> B  2
>  600727.68682251 5677973.32091602
>  600725.02385533 5677974.01131491
> 
> compared to:
> 
> $ v.out.ascii ditch_1205_edt form=standard | awk 'NR>10'
> B  2
>  600730.63832718 5678056.67823368
>  600725.02385533 5677974.01131491
> C  1 1
>  600730.04890192 5678035.56666655
>  1     1205
> B  2
>  600727.68682251 5677973.32091602
>  600725.02385533 5677974.01131491
> B  4
>  600727.68682251 5677973.32091602
>  600739.16582305 5678137.49568095
>  600736.32863997 5678140.4618269
>  600730.63832718 5678056.67823368
> 
> Note there is no single difference between the 2 *besides* the order in which
> boundaries are listed. Somehow, the ditch_1205 having boundary #4 listed as
> first is wrong for v.buffer (on my machine), while the ditch_1205_edt, having
> the same boundary listed as the last one, is OK.

FWIW, it seems clear that the problem is a snapping one, that is that a
node, whose coordinates appear to be the very same as a previous node
entered is _not_ snapped and is created as a new node. Hence even if
visually the area edges are connected, they are not since they end with
distinct nodes (that are equal but not identical).

I suspect that the offending node is:
600727.68682251 5677973.32091602

I imagine that with the new vector engine you still have a '-s' option
to v.support(1) or equivalent.
Take the non working case, and before buffering snap nodes with a very
small threshold. The problem shall disappear (this is indeed what you do
in v.digit(1), except that for v.digit(1) the snapping threshold is
usually relatively high).

If the diagnostic is correct, one thing to look in your code is the
handling of the 'C' record, I imagine this is the centroid?
I guess that centroid are not snapped, so that the code disallow
snapping when entering a centroid and that this is still in effect with
the next coordinates entered.

Hence, when the 'C' record is---first example, non working---before a
coordinate that is already a node, it is not snapped.

In the second example, since the next coordinate is not already a node
(it is a creation), no snapping is done but this is no harm.

You can confirm by moving the 'C' record in the first example last. It
should then work.

If people that can't reproduce the bug are snapping node before trying,
the difference is understandable.

If they are not snapping nodes before trying, what is to be checked is
is the floating point support linked to the hardware type (FPU, ieee754
support or not etc.).

HTH
-- 
Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>
                 http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C