[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 glynn):

 Replying to [comment:6 kyngchaos]:

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

 Yes.

 > It would be a little (lot?) slower, but easier to maintain.

 Any slowdown probably won't be significant.

 One option is to inline p_nearest(), as that's trivial, and if it produces
 a null result, p_bilinear() and p_cubic() will also produce a null result.
 If p_cubic() succeeds, the overhead of p_cubic() (16 cells and 5 cubic
 evaluations) will dwarf the (unnecessary) p_nearest() calculation, and if
 p_cubic() fails, you've saved a fair amount of computation.

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

 Adding special-case code for lat/lon wraparound to individual modules
 doesn't make sense, IMHO. I gave up on trying to get this right in
 r.resamp.interp (the same issue will also affect r.resamp.stats, and
 probably similar modules). Pushing this into the libraries should be
 simple enough, at least for rasters. This will have to be reserved for
 7.x, though.

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