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

[Maciek Sieczka via RT]

tlaronde at polynum.com wrote (Mon, Nov 27 2006 08:24:51):

Thierry (CCing Hamish),

Thanks for trying to help but your analysis is mostly worng. Please read below.

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

But yes *it is snapped*. Otherwise the boundary would not be closed, and there
would be no area - while there is:

$ v.info -t ditch_1205
nodes=4
points=0
lines=0
boundaries=3
centroids=1
areas=1
islands=1
faces=0
kernels=0
primitives=4
map3d=0

And the bug is that this topological area is not buffered properly, unless I
disjoin it's boundary and join it back.

> Hence even if visually the area edges are connected, they are not

But yes *they are connected*; the picture [4] shows that (ditch_1205 in
v.digit, before any edit). The picture [5] shows what the colors in v.digit
would be if the boundaries would be not connected.

> since they end with distinct nodes (that are equal but not identical).
> 
> I suspect that the offending node is:
> 600727.68682251 5677973.32091602

In what sense? All nodes coordinates are identical in vectors ditch_1205 and
ditch_1205_edt (see my previous message to learn how they were created). Only
the sequence of of boundaries is different between the 2 vectors.

> I imagine that with the new vector engine you still have a '-s' option
> to v.support(1) or equivalent.

v.clean tool=snap

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

Wrong. It doesn't help, and doesn't change anything in the data. And that's as
expected, because all nodes are already snapped in the problematic vector
ditch_1205, like I wrote above.

[4]http://kufaya.googlepages.com/ditch_1205_edt1.png
[5]http://kufaya.googlepages.com/ditch_1205_edt2.png

Maciek


-------------------------------------------- Managed by Request Tracker