[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: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? I suggest to change the default to
 0.01, but
 I've only tested with lat/lon srtm data so far. (v.surf.bspline cross-
 validation
 output is now a bit easier to digest in 6.5svn, btw; will port to trunk
 soon)

 for that data res*3.0 seemed to do well for sie,sin. res*1.0 was not
 enough for
 the patched tiles I tried it with.


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

 > 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.. which is an issue because at least for
 srtm the holes usually happen in the mountains. fwiw most of the overshoot
 errors from r.fillnulls are from the masked area afaict, so perhaps can be
 ignored.

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


 > I have modified r.fillnulls in trunk to use r.resamp.bspline which is
 designed
 > for raster interpolation instead v.surf.bspline.

 I'll try it out & see how it does against the others.

 > That avoids the vectorization step

 fwiw with -z that wasn't too costly, but happy to try out a new option and
 see if it
 does as well as v.surf.bspline's bicubic + lambda=0.005 (which _really_
 did nicely).

 also, what would it take to get 'g.region vect=' to work with a level 1
 map? right
 now you get a no-topology error if you try it with 'r.to.vect -b' (& so
 make the
 rst method prep work even smaller/faster/less ram).


 > 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. the python lib create temp region fn includes a on-exit hook to
 automatically
 unset and delete itself when the module ends, so don't worry about
 leftovers.


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


 thanks,
 Hamish

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