[GRASS-user] Criteria for v.clean tool=rmdangle

[Dwight Needels]

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  
>> and
>> 11 ft (27 ft combined). The pre-clean vector is gray, the cleaned
>> vector is red, vertices are displayed as points derived using
>> v.to.points.
>>
>> After running v.clean tool=rmdangle thresh=30 the resulting vector  
>> (in
>> 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  
> number
> 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
> thresh=X,0,X.

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


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.

Thanks, -Dwight