[GRASS-dev] Re: [GRASS GIS] #1088: r.fillnulls: support other interpolation methods

[GRASS GIS]

#1088: r.fillnulls: support other interpolation methods
-------------------------+--------------------------------------------------
 Reporter:  kyngchaos    |       Owner:  grass-dev@…              
     Type:  enhancement  |      Status:  new                      
 Priority:  normal       |   Milestone:  6.4.3                    
Component:  Raster       |     Version:  svn-develbranch6         
 Keywords:  r.fillnulls  |    Platform:  All                      
      Cpu:  All          |  
-------------------------+--------------------------------------------------

Comment(by hamish):

 > Replying to [comment:20 hamish]:
 > > hmmm, what if r.buffer.py checks rows*columns and decides
 > > which backend it should call based on the result. small regions
 > > get sent to one, large ones to another, & best of both worlds.
 Replying to [comment:21 mmetz]:
 > Small and large is relative to the amount of free memory. You
 > would need to check for that first before you decide what is
 > small and what is large. IMHO too complicated, I would just use
 > the safer method.

 see attached patch for a rough idea. check free memory is not a road I
 want to go down, so set a default at 12000x12000 cells (I just picked a
 number), and if it's bigger than that use the r.grow.distance method,
 otherwise the fast but memory intensive method. Add an option to allow the
 user to override the default.

 4.5 sec for .py vs. 0.140 sec for .c. I know I've got at least one script
 which runs r.buffer in a loop for thousands of starting points, I don't
 want to think how long it will take at 4.5sec each iteration.
 (actually 0.250 sec for r.buffer2 if you use the python wrapper)

 for a 12000x12000 region using r.buffer2: 17.4 sec, 156mb RAM.
 same using r.grow.distance: 10 minutes 7 second, 20mb RAM (takes forever
 reading and writing map, even on a fast RAID [it's CPU bound not IO
 bound])

 20000x20000 region: r.buffer2 takes 51 sec, uses 400mb RAM (1 byte per
 cell). I'm not going to bother to find out how long r.grow.distance would
 take.

 40000x40000 region: r.buffer2 takes 4 min 7sec (~1 min to read, ~1 min to
 buffer, ~2 min to write), uses 1.6gb RAM.
 r.grow.distance, no idea, maybe days to complete.

 95% of work will be smaller than 40k^2 cells. the r.grow.distance method
 seems like it is best left as a footnote + example in the r.buffer2 help
 page.



 > r.fillnulls should do just that, filling nulls, and not do
 > resampling.

 I am not convinced (not even a little). No exceptions to the standard map
 creation conventions unless it is absolutely fundamental to what the
 module does. If this was a edit-in-place module like r.null maybe I could
 buy the argument, but it isn't. Either deal with all of the input map's
 native bounds, or use the current region, not half and half. Using the
 current region settings gives the user the choice of which one they want.


 thanks,
 Hamish

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