[GRASS-user] r.thin quirk

[Dwight Needels]

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 at 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