Re: [GRASS-user] r.thin quirk
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.pngr.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
Re: [GRASS-user] r.thin quirk
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 inline: r.thin_raster.png ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.thin quirk
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 inline: r.thinpinched_1.pnginline: r.thinpinched_2.png___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
