[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                      
--------------------------+-------------------------------------------------
Comment (by kyngchaos):

 Replying to [comment:5 glynn]:
 > 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.

 Ah, this clarifies the logic of the algorithms.

 > The requested interpolation always '''works'''. Sometimes the (correct)
 result is null; that isn't the same thing as not working.
 ...
 > 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.

 Understood, though I was thinking of a flag, but that would have gotten
 real messy.

 OK, I'll work on separate methods.  Is it OK for an interp function here
 to call another interp function?  ie, instead of duplicating the code in
 cubic, bilinear and nearest, I could call each, as I outlined to do in
 main.c.  It would be a little (lot?) slower, but easier to maintain.

 Any comments on the wraparound stuff?  I noticed Markus Metz's comment on
 the list about extending latlong locations beyond +-180 deg.  This would
 make my wraparound patch more difficult.  Though your idea of Euclidifying
 regions might solve it (but that sounds like something for GRASS 7).

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