[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.5.0                    
Component:  Raster       |     Version:  svn-develbranch6         
 Keywords:  fillnulls    |    Platform:  All                      
      Cpu:  All          |  
-------------------------+--------------------------------------------------

Comment(by mmetz):

 Replying to [comment:8 kyngchaos]:
 > A couple notes/questions:
 >
 > I didn't completely understand the description for the sparse option,
 but it didn't look like it was needed here.  Now it looks to me like it's
 essentially a mask option, like the maskmap option in v.surf.rst.  For
 now, the mask is implied when the results are patched into the original
 raster.  I guess a mask option (if sparse is such) only makes sense if it
 reduces processing time by ignoring the masked areas.

 Right. Unfortunately, using sparse points as input for v.surf.bspline does
 not reduce processing time substantially, although it could be implemented
 similar to what I did for r.resamp.bspline. The sparse points act somewhat
 similar to a mask in the way that only these sparse points are
 interpolated. The matrix calculations are done anyway, a waste of time if
 no sparse points are within the current subregion. Therefore I think your
 approach is much faster for just a few NULL cells in a large surface
 raster.
 >
 > The description says 1 * resolution was good for regularly spaced
 points, which is what we get from a raster.  Why 2* in your method?

 This is a compromise between speed, smoothing, and interpolating both
 small and large gaps. The spline step is similar to tension in RST, larger
 spline step values mean that points influence each other over larger
 distances. 1 * resolution seems to be the best for very small gaps, but
 for larger steps, I would use larger spline steps. I did a bit of testing,
 punching holes into a DEM and interpolating these holes. Spline steps of
 1.5 - 2 * resolution produced best results, i.e. interpolated values were
 closest to real values.

 I have to update the manual for r.resamp.bspline because it uses 1.5 *
 resolution as default spline step. For a gap-free surface, I think 1 *
 resolution of the input raster is best
 >
 > For the lambda, the docs are unclear what orders of numbers have
 effects, beyond "the larger the number the more smoothing applied".  The
 default is one.  You say 0.001-0.01 work well.  I figured 1 was something
 like 1*, or no smoothing.  Can you clarify this option?

 Umm, that's trial and error what I did there. Lambda = 1 did usually not
 provide very nice results, too much smoothing. Lambda and spline step
 influence each other, I tried to find reasonably good default values, but
 sometimes some fine-tuning might be required. I guess more testing is
 needed to determine the smoothing behaviour of different lambda values, or
 there is someone out there who understands the theory behind the code and
 could help.

 Markus M

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