[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 mmetz):

 Replying to [comment:15 hamish]:
 > > Replying to [comment:12 hamish]:
 > > > see above comments for MarkusM's recommendation for using si=2*res
 and
 > > > lambda=0.005.
 > Replying to [comment:14 mmetz]:
 > > The sie/sin settings are the result of guestimation and experimenting.
 >
 > any idea about the lambda_i setting?

 In my tests, 1 is usually way too high, 0.005 seems to do well in
 mountainous areas, 0.1 is better for nearly flat areas.
 >
 > > RST tends to provide more detail at the cost of overshoots,
 >
 > fwiw in my tests yesterday v.surf.bspline bicubic with lambda=0.005 and
 si?=res*3
 > did the best job, v.surf.bspline with default lambda=1 wasn't totally
 horrible, but wasn't great, and rst was fairly obvious something had been
 patched in (but I didn't tune the tension at all).

 I think it is not easy to avoid segmentation artifacts with RST (very high
 npmin, very low segmax maybe).
 >
 > > whereas bspline with method=bilinear does not produce overshoots and
 produces a
 > > smoother surface.
 >
 > but the downside of that is that it lowers the contrast/rounds down
 towards the
 > mean more than a spline fit would..

 Sometimes this is a downside, sometimes not. For hydrological analysis,
 overshoots are a problem and must be dealt with somehow.
 >
 > > Bspline with method=bicubic can produce results very similar to RST,
 but AFAIU the
 > > idea of bspline interpolation is to avoid overshoots and to produce a
 smoother
 > > surface. Therefore r.fillnulls could just as well have the method
 options
 > > rst,bspline with bspline using bilinear by default. The results would
 then be
 > > intentionally different.
 >
 > I personally prefer bicubic to bilinear (will let a job run slower if it
 means a
 > better end result), and I'd vote to keep method=rst,bicubic,bilinear
 instead of
 > method= + method2= options. the user doesn't care about which middleware
 modules,
 > are doing the work, just the beginning and the end.

 Sounds good. Anyway, the manual should also state that r.fillnulls is an
 attempt for semi-automated NULL filling, and if in doubt this must be done
 manually to obtain the desired results.

 >
 > what would it take to get 'g.region vect=' to work with a level 1 map?

 The routines are already in v.info (trunk).

 >
 >
 > > and essentially reduces the processing to r.resamp.bspline -n followed
 by
 > > r.patch.
 >
 > btw, you'll need to move that del_temp_region back to where it was. with
 it still
 > in place when you run r.patch you're cropping the patched result with
 the zoomed-in
 > region.

 Oops. Changed in r50803. The grid geometry of the input raster is still
 maintained, though.

 >
 > > PS: I fixed r.buffer in trunk, it could now be used (again) by
 r.fillnulls
 > > instead of r.grow.
 >
 > you mean r.buffer.py :-) "r.buffer2" (the classic C version) in trunk
 always worked bug free for many years, and is about 50x faster (race them
 with `time`). Perhaps the python version was an old experiment to see if
 some modules could be combined in a single engine?

 Hmm. One of the two r.buffer's should probably be deactivated, after
 comparative testing with latlong and real projections.

 Markus M

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