msieczka wrote (Mon, Nov 27 2006 21:26:26):
hamish_nospam@yahoo.com wrote (Mon, Nov 27 2006 02:56:42):
another test:
v.build.polylines in=ditch_1205 out=ditch_1205_single
v.buffer ditch_1205_single out=ditch_1205_single_b4 type=area buffer=4
The ditch_1205_single_b4 is an empty vector for me (0 features).
Sorted out. This happens because v.build.polylines removes categories from
centroids, while v.buffer works only on features that have cats.
(This is another bug in v,build.polylines, or bad feature at least - why
should it remove the cats from centroids?).
Once I add the category to the centroid back, by
$ v.category in=ditch_1205_single type=centroid option=add
out=ditch_1205_single_addcat
the output of
$ v.buffer ditch_1205_single_addcat out=ditch_1205_single_addcat_b4 type=area
buffer=4
is OK! (visually, at least; but there are 8 redundant nodes in it!)
Even taking the #4249 bug into consideration and aplying the 'v.clean
tool=prune thresh=0' workaround on ditch_1205_single_b4, and buffering it's
result, the v.buffer output is still empty
This step is not required; IOTW, the buffer is OK in spite of bug #4249, which
causes that the ditch_1205_single, and its's "child" ditch_1205_single_addcat
have doubled vertices on the boundary; but this doesn't mean the bug #4249 is
gone :), only it doesn't do harm in this case.
(BTW - strange, I couldn't reproduce bug #4247 with ditch* data; I need to
look into this tomorrow).
Sorted out. For the bug #4247 to crop out, the input boundary has to be a
polyline already (ie. v.build.polylines corrupts only boundary polylines). See
my recent notes on http://intevation.de/rt/webrt?serial_num=4247.
So, how does that look now to you? (if bugs in v.build.polylines where fixed
we could avoid some cofussion).
Maciek
-------------------------------------------- Managed by Request Tracker
