[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:20 hamish]:
 > Replying to [comment:18 mmetz]:
 > > 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
 > (ie degrade)
 > > the system if it goes into swap space. r.buffer.py keeps the disk
 > > busy, but the system remains responsive.
 >
 > hmmm, what if r.buffer.py checks rows*columns and decides which backend
 it should call based on the result. small regions get sent to one, large
 ones to another, & best of both worlds.

 Small and large is relative to the amount of free memory. You would need
 to check for that first before you decide what is small and what is large.
 IMHO too complicated, I would just use the safer method.

 >
 > > > 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.
 > >
 > > Oops. Changed in r50803. The grid geometry of the input raster is
 > > still maintained, though.
 >
 > yeah, but if the interp and the orig are patched together on the orig's
 native grid (I'm not sure if it makes a practical difference here, but no
 objection to that), it will still need a 'r.mapcalc "resamp = patched"
 step to follow the rule that output maps are created using the (real)
 current region's grid settings, not the input map's native alignment. the
 alternative is to decalre that r.fillnulls works on the input map's native
 region completely and ignores the current region settings completely. but
 that stops you from working on sub-windows of a larger dataset.

 Working with subwindows is supported, the subwindow is aligned to the
 input, though. Surface resampling is another issue and I would rather
 avoid implicit nearest-neighbour resampling. The standard resampling
 modules for surfaces are r.resamp.interp (anything but nearest) and
 r.resamp.stats. r.fillnulls should do just that, filling nulls, and not do
 resampling. Working with a subregion is fine of course.

 > > > what would it take to get 'g.region vect=' to work with a
 > > > level 1 map?
 > >
 > > The routines are already in v.info (trunk).
 >
 > shall we move vector/v.info/level1.c into libvector as
 Vect_level1_describe(Plus_head *) or similar? seems quite reusable.

 Could make sense, I would like to think a bit about it.

 Markus M

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