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