[GRASS-dev] Re: [GRASS GIS] #1088: r.fillnulls: support other interpolation methods

GRASS GIS trac at osgeo.org
Wed Feb 15 02:29:07 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:  r.fillnulls  |    Platform:  All                      
      Cpu:  All          |  
-------------------------+--------------------------------------------------

Comment(by hamish):

 Replying to mmetz:
 > I have modified r.fillnulls in trunk to use r.resamp.bspline
 > which is designed for raster interpolation instead v.surf.bspline.

 my test 2x3 deg srtm mosaic takes 40 seconds to complete with
 'r.resamp.bspline method=bilinear' as the backend and 2 minutes using
 bicubic (slightly better results). v.surf.bspline was taking ~4-6 minutes
 for bicubic, and  r.surf.rst takes about 4 minutes with the zoom-to-data
 trick. both rst(no zoom) and v.surf.bspline's bicubic took about 8 minutes
 in grass 6 (no OpenMP for both there [still inefficiently used, but helps
 a bit]).


 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.

 (as long as the two r.buffer2/r.grow.distance backends give identical
 results, which visually they do)


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


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


 Hamish

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



More information about the grass-dev mailing list