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

[Maciej Sieczka]

Hamish wrote:
> Maciek Sieczka via RT wrote:
>> I have revisited this bug and I think I know why you, after your
>> fixes, were able to produce correct buffers using my 'ditches' vector,
>> while I was still obtaining errors (though somewhat different than at
>> the beginning, before your fixes).
>>
>> step-by-step:
>>
>> 1. unpack the bzipped testing location I have sent you
>>
>> 2. enter the location - don't touch anything yet!
>>
>> 3. v.buffer input=ditches output=buf1 type=area buffer=1
>>
>> 4. display 'buf1'; you should see the wrong buffer around the parcel
>> that has cat 1205 in the 'ditches' vector - as I did
> 
> Nope, I still get correct output the first time.

... and I still can't :|. Just extracted the very same package I just
sent you, done

$ v.buffer input=ditches output=ditches_buf1b type=area buffer=1

and the ditches_buf1 has the same artifact it had so far. When I "edit"
it the input vector ditches the way I described in previous email - the
buffer is created OK. Shoot me.

> g.region ditches_buf

Which one is that?

> d.vect buf1
> d.vect ditches col=blue cats=1205
> d.vect ditches col=red cats=1203
> d.vect ditches col=yellow cats=1204
> 
> maybe it has to do with the 1203,1204 ?

Don't think so. Even when I removed them centroids and their boundaries
altogether, the problem was still there - see the output of 'v.buffer
input=ditches output=ditches_buf1b type=area buffer=1' for such a case [1].

> can you isolate the problem with:
> 
> g.region ditches_buf

Which one is that? It's not there in the package I sent you.

> v.in.region problem_box
> v.select ain=ditches bin=problem_box out=problem_areas
> v.out.ascii format=standard in=problem_areas
> v.in.ascii
> v.buffer
> 
> ?
> e.g. is there a single boundary line between 1203,1204 or two (slightly
> not touching) boundary lines?

> "v.clean tool=rmdupl"

Done that before, to no avail.

>> 5. now, open 'ditches' in v.digit, pan to where cat 1205 is and
>> disjoin it's boundary, and the snap the vertiices back as they were
>> originally
>>
>> 6. v.buffer input=ditches output=buf1_new type=area buffer=1
>>
>> 'buf1_new' is OK! - although the command in point 3. and 5. is
>> identical, and although the input data haven't changed a bit - only
>> one vertex was moved, but snapped back to it's original position
>> immadietly.
>>
>> I have no idea why it is like that. Hamish, can you reproduce that?

> no..

>> Strange. The input vector in both cases is virtually the same, in both
>> it is topologicall, error free (according to v.build, v.clean and
>> visuall inspection in v.digit). But somehow, moving one vertex
>> slightly and snapping it back "fixes" the vector so that v.buffer can
>> handle it OK.
>>
>> 'ditches' was hand digitised by me in QGIS 0.74, few months ago.

> maybe it is a FP epsilon problem, which is slightly different machine to
> machine + compiler to compiler? e.g. 123.4000000000002 vs 123.4.

Would that mean v.buffer is supposed to work on some Linuces and not on
the other? That would be a nightmare.

> You mention no errors with these, but did you try running v.buffer with
> the output of v.build and v.clean or just see there was no error reported?

Sure, I tried many ways for cleaing the data and feeding it into
v.buffer. But only manually moving the vertex and snapping it back helps.

> does the error survive v.out.ascii form=standard + v.in.ascii form=standard?

Yes it does:

$ v.out.ascii ditches format=standard | v.in.ascii format=standard
out=ditches2
$ v.buffer input=ditches2 output=ditches2_buf1 type=area buffer=1

Same old bug... [2].

> I see in the buffering output there are 7 areas without centroids, but I
> wonder if these are just "islands" (holes) within areas?

Yes, they are islands.

The point might propably be about the boundaries of the problematic
area being recognized as snapped on your machine, while being
recognized as disjointed on my machine. That'd be nuts tough. Please
watch the swf at [3], where I present step-by-step the two runs of
v.buffer on the problematic dataset - before and after the required
"edit", including how the "edit" looks like. I'm just moving vertex of
a topologically clean boundary a bit and snapping it back. Strange...

Best,
Maciek

[1]1203_1204_removed.png
[2]after_through_asc.png
[3]http://kufaya.googlepages.com/buffer_boundary_issue.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1203_1204_removed.png
Type: image/png
Size: 7706 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/grass-dev/attachments/20061123/1276bdb7/1203_1204_removed.png
-------------- next part --------------
A non-text attachment was scrubbed...
Name: after_through_asc.png
Type: image/png
Size: 7238 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/grass-dev/attachments/20061123/1276bdb7/after_through_asc.png