[GRASS-dev] [GRASS GIS] #2368: Python version of r.grow does not support shrinking

[GRASS GIS]

#2368: Python version of r.grow does not support shrinking
----------------------------------------------------------------+-----------
 Reporter:  wenzeslaus                                          |       Owner:  grass-dev@…              
     Type:  enhancement                                         |      Status:  new                      
 Priority:  normal                                              |   Milestone:  7.1.0                    
Component:  Raster                                              |     Version:  svn-trunk                
 Keywords:  r.grow, r.grow.distance, r.buffer, r.buffer.lowmem  |    Platform:  Unspecified              
      Cpu:  Unspecified                                         |  
----------------------------------------------------------------+-----------

Comment(by wenzeslaus):

 Replying to [comment:1 glynn]:
 > Replying to [ticket:2368 wenzeslaus]:
 >
 > > While C version of `r.grow` supports shrinking (negative
 distance/radius) since r59735, the Python version of `r.grow` based on C
 module `r.grow.distance` and `r.mapcalc` expression supports only growing
 (positive distance/radius). Shrinking (negative buffer) is a useful
 feature, so I think we should add it.
 >
 > For me, the question isn't whether it's useful, but whether it belongs
 in r.grow, as opposed to a separate r.shrink module. The two operations
 are quite different (growing has to determine the correct value for "new"
 cells, shrinking only discards data).
 >
 `r.shrink`, this makes sense. But maybe the difference is not so big. What
 about shrinking the original values but putting there some new ones.

 > > I'm not sure if negative distances can be added to `r.grow.distance`.
 >
 > Shrinking can be implemented using r.grow.distance by first generating
 an "inverted" map (null if the input is non-null, non-null if the input is
 null), growing the inverted map, inverting the result, then using it as a
 mask.

 Creating yet another intermediate map, this is what I'm afraid of, this is
 always slow.
 >
 > Whether this will be faster than the C version depends upon the size of
 the buffer and the proportion of non-null cells. The worst-case time for
 r.grow.distance is proportional to the size of the input, whereas the
 worst-case time for the C version of r.grow is also proportional to the
 size of the buffer (specifically, to its area, i.e. the square of its
 radius).
 >
 > For a sufficiently large buffer, r.grow.distance will be faster. Unless
 the cross-over point is unreasonably large, it may be worth implementing
 an r.grow.distance-based version even if the C version of r.grow is
 provided.

 Having two versions of the same module is inconvenient. What about moving
 C version of `r.grow` to addons under a different name. I don't have any
 suggestion right now but perhaps somebody else has.

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/2368#comment:2>
GRASS GIS <http://grass.osgeo.org>