[GRASS-dev] Re: [GRASS GIS] #1088: r.fillnulls: support other
interpolation methods
GRASS GIS
trac at osgeo.org
Sun Feb 12 20:58:18 EST 2012
#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>
More information about the grass-dev
mailing list