[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:17 hamish]:
 > Replying to [comment:15 hamish]:
 > > > any idea about the lambda_i setting?
 > Replying to [comment:16 mmetz]:
 > > 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.
 >
 > in trunk and devbr6 I have changed it to 0.01 now. I would suggest to
 backport to 6.4svn ASAP before it harms any more data, but would like to
 test it with some meter-based LIDAR data first, as I've only tried with
 lat/lon srtm so far.

 Tested with LiDAR datasets, lambda=1 is too high, synced in 6.4 to
 trunk/devbr6 with default lambda=0.01.
 >
 >
 >
 > > I think it is not easy to avoid segmentation artifacts with RST (very
 high
 > > npmin, very low segmax maybe).
 >
 > for r.fillnulls I'd expect the 3-cell buffer of most holes not to fall
 on segmentation boundaries. it wasn't that it had obvious segmentation
 lines in it, rather it just didn't follow the ridges and valleys in such a
 natural way. (qualitative eyeball analysis) I've been convinced for years
 that there must be a way to avoid the segmentation artifacts without
 massively overlapping the quadtree boxes.. still keeping an eye out.

 I had obvious segmentation lines with RST. From my testing with the
 bspline method I think that there is no way around massively overlapping
 quadtree boxes.
 >
 >
 > > Hmm. One of the two r.buffer's should probably be deactivated, after
 > > comparative testing with latlong and real projections.
 >
 > I get 4.3sec for a test in r.buffer.py, 0.140 sec for r.buffer.c, for a
 simple test starting at a single cell, with visually identical results.
 Actually I was pleasantly surprised that r.buffer.py did the right thing
 in lat/lon and made a pear-shaped buffer for the plate carree display,
 wider nearer to the poles.

 In trunk, r.buffer.c loads both input and output completely to memory,
 whereas r.buffer.py using r.grow.distance doesn't. Therefore r.buffer.c is
 faster for smaller maps but will freeze the system if it goes into swap
 space. r.buffer.py keeps the disk busy, but the system remains responsive.

 Markus M

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