[GRASS-user] Criteria for v.clean tool=rmdangle
needels at translucida.com
Sun Jun 14 15:18:24 EDT 2009
On Jun 14, 2009, at 3:00 AM, Markus GRASS wrote:
> Dwight Needels wrote:
>> The rmdangle tool in v.clean usually behaves exactly the way I would
>> expect it to, but occasionally it does not.
>> I have a vector generated from a raster using r.thin and r.to.vect
>> that has numerous dangles. In the attached screenshot there are what
>> appear to be two dangles with lengths of ~2 and ~5 ft. The two
>> terminal polylines of what appears to be the core vector are 16 ft
>> 11 ft (27 ft combined). The pre-clean vector is gray, the cleaned
>> vector is red, vertices are displayed as points derived using
>> After running v.clean tool=rmdangle thresh=30 the resulting vector
>> red) removes one of the dangles plus what appears to be the two
>> terminal polylines of the core vector, while leaving the smaller
>> dangle attached. I tried running v.edit tool=merge or
>> v.build.polylines before cleaning, but got the same results.
>> How does v.clean decide which line segment to remove as a dangle? Is
>> there a way to force it to remove the line segment that leaves the
>> longest possible remaining vector?
> AFAIU, tool=rmdangle does not remove line segments, it only removes
> whole lines. In GRASS terminology, a line has two end nodes, any
> of vertices and (n vertices - 1) segments. In your case, it may be
> necessary to snap lines first, then break lines at intersections, then
> remove dangles. Something like v.clean tool=snap,break,rmdangle
I see what you mean... it does remove entire lines. The way these
vectors are generated (from r.thin/r.to.vect) seems to create vectors
that don't need snapping or breaking, and the vectors look correct in
v.digit (green nodes at intersections, red nodes at terminii). I tried
your suggestion just in case with a 1 ft snap threshold followed by
break and rmdangle, and got the same result.
> v.build.polylines would rather prevent tool=rmdangle to find
> anything to
As far as I can tell, v.build.polylines leaves existing nodes at line
intersections. At any rate, I get the same result whether or not I run
this command first.
> BTW, have you tried r.to.vect on the original GPS tracks, then
> v.generalize, instead of r.buffer/r.grow/r.thin?
I'm not sure that I follow what your are suggesting. I left out the
fact that the reason for going through r.buffer/r.thin is to average
multiple GPS tracks, so r.to.vect insists on running r.thin first. If
you are suggesting something else that I am missing, I would
appreciate a clarification.
I am still confused about how v.clean chooses which line to remove as
a dangle when there is a choice.
More information about the grass-user