On Jun 11, 2009, at 12:50 AM, Dwight Needels wrote:
On Jun 11, 2009, at 12:01 AM, Dwight Needels wrote:
On Jun 6, 2009, at 11:36 PM, Dwight Needels wrote:
Hi all. I have run into a quirk using r.thin, but I am not sure
whether or not it is a bug. I have a raster that was generated
from multiple GPS tracks using v.rast followed by r.buffer. Using
r.thin followed by r.to.vect creates a vector that must then be
cleaned using v.clean to remove dangles (so far, so good).
The quirk is that r.thin occasionally creates a triangle at the
intersection of two lines instead of two intersecting lines. All
of the examples I have seen involve relatively acute angles (less
than 25 degrees??). I have attached a screenshot that shows the
raster in magenta, the vector with dangles in white, and the
cleaned vector as (a thinner) green. There are numerous acute
angles that generate the vectors I would expect, with one
exception in the center.
Is this expected behavior? If so, is there an easy way to search
for all such resulting triangles in a vector or to remove all such
extra lines in a vector? If not, is there a way to fix it?
Thanks, -Dwight
<r.thin.png>
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Although I figured out how to file a bug report on this, http://trac.osgeo.org/grass/ticket/636
, I am not sure how to respond directly to comments on the ticket.
Hamish, I used the screenshot showing the vectors because I had
already created it to look for artifacts. The extra line that makes
the triangle is also present in the thinned raster (screenshot
attached).
Thanks, -Dwight
<r.thin_raster.png>
Follow-up... the two examples of this happening in this particular
file each have a single white pixel surrounded on 7 out of 8
directions by red pixels, but still touching a white pixel on a
corner in the 8th direction (see two screenshots). I suspect that
r.thin is treating this as a hole even though it is touching an
edge. Another way of saying this is that the two red pixels touching
in 1 out of the 8 directions are treated as a line.
Perhaps there could be a flag to control this behavior.
Thanks, -Dwight
<r.thinpinched_1.png><r.thinpinched_2.png>
It does appear that the observed quirk is caused by the way r.thin
treats pixels that touch only at their corners. I thought I could work
around this my using r.neighbors method=mode. Although this does
eliminate single empty pixels, it sometimes generates new ones
elsewhere. Although I am sure there is a clever way to use r.mapcal, I
ended up inverting the map, running r.grow, and inverting again (the
equivalent of what could be called r.shrink). As far as I can tell,
this eliminates single pixel holes without generating new ones.
Can someone who understands the way r.grow works confirm that this
will always be the case?
In the workflow where I discovered this (averaging GPS tracks), I
ended up using r.buffer on the inverted map instead of r.grow. In
addition to apparently eliminating triangles at intersections, it also
reduces the number of dangles generated by r.thin by smoothing the
raster before thinning.
-Dwight
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
