[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:  fillnulls    |    Platform:  All                      
      Cpu:  All          |  
-------------------------+--------------------------------------------------
Changes (by hamish):

  * milestone:  6.5.0 => 6.4.3


Comment:

 * applied in devbr6 by MarkusN in r50114, with sie,sin = 3*res and the
 default lambda_i=1.
  * applied to trunk by luca in r50128 with sie,sin = 1*res and the default
 lambda_i=1.

 see above comments for MarkusM's recommendation for using si=2*res and
 lambda=0.005.
 shall we apply those coeff's?  MM: are those numbers going to be dataset
 dependent, or are they generally good for the way r.fillnulls works by
 extracting the centers of the 3 cell buffer pixels as the vector starting
 points?


  * in 6.5svn I added a step which zooms into the minimum region containing
 all holes before running v.surf.rst. For my data this made the region
 about half the size and r.fillnulls ran twice as fast. beforehand
 v.surf.rst and v.surf.bspline bicubic methods took about the same amount
 of time (6.5svn versions..), so for my particular srtm data the v.surf.rst
 method was now twice as fast as the v.surf.bspline bicubic method. I tried
 running v.surf.bspline with the region zoom but it made no difference
 besides using 30 subregions (with a few empty) instead of the original 77
 subregions (with a lot empty). actually for bspline with the region zoom
 it took about 10-15% longer, so I only applied it to the RST method, i.e.
 processing time was mostly independent from region settings. I suspect the
 original subregion segments were slightly more efficient than the zoomed
 version due to a bit of luck of where the points were & what subregions
 were empty.

 both RST and bspline results were (very nearly) identical to without the
 zoom.

 nominating both the method= and the RST zoom patch for inclusion in 6.4.3.

 trialing bspline in grass7 now... rst time was about the same as in
 devbr6, a wee bit faster due to partial OpenMP support.


 Hamish

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