[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 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).

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

 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.

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