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

[Markus GRASS]

Dwight Needels wrote:
> Markus:
>> 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.
Then there was nothing snapped? You can see what happened with v.clean
--verbose. Just to make sure I understand you correctly, have a look at
the attached image. I guess you want to remove the line segments
indicated by the arrows? Then the two lines need to be broken where the
red crosses are, and in order to break there with tool=break, snapping
may be needed first, at least for the left cross.
>
>>
>> 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. 
The lines connecting to these nodes were not merged, otherwise the node
should have disappeared and only a vertex should be in its place.
> 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. 
Error in my suggestion, sorry! No r.to.vect needed, I thought about the
vector you got from v.in.ogr, using that directly as input for
v.generalize. Unless you have multiple GPS tracks for the same
track/hiking route, then v.to.rast->r.buffer->r.thin->r.to.vect seems fine.
> 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.
A line is a dangle if at least one of its two nodes is not connected to
another line (dead end). A dangle is removed if it is smaller than
threshold, if threshold is < 0, all dangles are removed. I want to
update the v.clean manual when I get the time...

Markus M

-------------- next part --------------
A non-text attachment was scrubbed...
Name: v.clean_snap_break.png
Type: image/png
Size: 8566 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/grass-user/attachments/20090615/211ea02e/v.clean_snap_break-0001.png