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



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


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

 yeah, the man page needs quite a bit of work actually.. and I can't quite
 figure out what the WARNING is trying to get you to delta against with
 r.mapcalc to verify the interpolation. seems an impossible task, since if
 you knew the correct answer you there'd be no reason to interpolate.


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


 Hamish

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