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
<<inline: v.clean_snap_break.png>>
_______________________________________________ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
