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
_______________________________________________
grass-user mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-user
