[GRASS-dev] [GRASS GIS] #465: r.proj.seg thins along null areas and raster bounds for bilinear and cubic methods

[GRASS GIS]

#465: r.proj.seg thins along null areas and raster bounds for bilinear and cubic
methods
-----------------------+----------------------------------------------------
 Reporter:  kyngchaos  |       Owner:  grass-dev at lists.osgeo.org
     Type:  defect     |      Status:  new                      
 Priority:  major      |   Milestone:                           
Component:  Raster     |     Version:  svn-develbranch6         
 Keywords:             |    Platform:  All                      
      Cpu:  All        |  
-----------------------+----------------------------------------------------
 Due to the nature of the bilinear and cubic interpolation methods, when
 any of the surrounding matrix of cells is null, the interpolated cell is
 set to null, instead of making do with what is available.  With the
 bilinear, thinning occurs to the right and bottom of the interpolated
 cell, with cubic it will occur on all sides.

 Since the bounds of a raster have effectively null cells outside the
 bounds, it also occurs at raster boundaries.  This is especially noticable
 when projecting latlong rasters across the +-180 meridian -- there will be
 a line of cells missing where 180 E joins with 180 W.

 ''This is a change from the previous r.proj'', which set any surrounding
 nulls to the "nearest" cell temporarily.

 Patches attached to handle both issues.  Some notes:

 The wraparound case I decided to limit only to latlong input projections.
 This does not need any option to enable/disable it, but each r.proj
 interpolation method needs an extra flag in its function call (see
 r.proj.h).  It also only needs to wraparound when the interpolated cell is
 within 2 cells of +-180 long or +-90 lat, (oops, I just realized that +-90
 lat doesn't wrap the same as +-180 long).  The +-180 and +-90 values are
 hardcoded in, maybe there is a better way to handle maximum latlong
 extents (like the case where it's 0-360 long)?

 The null filling case could be optional, with a module flag.  This would
 have to be passed to each r.proj interpolation function with another flag
 alongside the wraparound flag.

 For now, the surrounding cells are filled with the "nearest" input cell to
 the interpolated cell, like the original r.proj did.  This works for the
 bilinear interp, but could cause odd interpolation in the cubic method, so
 the cubic null filling needs some work.

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/465>
GRASS GIS <http://grass.osgeo.org>