#465: r.proj.seg thins along null areas and raster bounds for bilinear and cubic methods --------------------------+------------------------------------------------- Reporter: kyngchaos | Owner: [email protected] 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>
_______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
