[GRASS-dev] Re: [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:  enhancement  |      Status:  new                      
  Priority:  major        |   Milestone:                           
 Component:  Raster       |     Version:  svn-develbranch6         
Resolution:               |    Keywords:                           
  Platform:  All          |         Cpu:  All                      
--------------------------+-------------------------------------------------
Changes (by glynn):

  * type:  defect => enhancement

Comment:

 Replying to [comment:4 kyngchaos]:

 > > The existing behaviour regarding actual nulls is correct, and will be
 preserved. If you want nulls filled, use e.g. r.fillnulls. Don't go
 stuffing ad-hoc fudges into r.proj.
 >
 > The problem is not when the target input cell is null - that I don't
 have a problem with.  It's when input cell is non-null, but some or all of
 the cells in the surrounding interpolation matrix are null.  The basic
 interpolation algorithms need values in all cells,

 Yes. Yes, they do need values in all surrounding cells. This is not a bug.

 > and I'm suggesting an option to fake those surrounding values (in the
 worst case, the interpolation drops down to a nearest neighbor interp).
 >
 > It comes down to - if there is a cell in the input, I want a cell there
 in the output.

 This assumes that the output cells correspond to input cells. They don't
 (at least, not for bilinear and bicubic). They correspond to the input
 '''surface''', and the surface is undefined within 1 or 2 cells of the
 centre of any null cell.

 > Hmmm, I suppose this would work (could be done from the main.c loop),
 and it would not mess with the algorithms:
 >
 >  * if cubic option, interpolate cell cubic
 >  * if no value yet, or bilinear option, interpolate cell bilinear
 >  * if no value yet, or nearest option, interpolate cell nearest

 IOW, the equivalent of running r.proj with each of the three methods, then
 r.patch-ing the results.

 > This would attempt lower interpolations if the higher one did not work
 because of nulls in the matrix.

 The requested interpolation always '''works'''. Sometimes the (correct)
 result is null; that isn't the same thing as not working.

 In any case, if you want to implement this, the least invasive approach
 would be to extend the "menu" array with:
 {{{
     {p_bilinear_fudge, "bilinear_fudge", "bilinear with fallback"},
     {p_cubic_fudge, "cubic_fudge", "cubic with fallback"},
 }}}
 and add the corresponding functions.

 This would ensure that the existing code paths are completely unaffected.

 I'm wary about doing anything which might possibly affect existing usage,
 as bogus results typically won't be obvious unless you explicitly check
 with e.g. r.slope.aspect.

 The previous calculation was used for at least a decade without anyone
 noticing that it was nonsense (see r22190).

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