[GRASS-dev] bilinear and bicubic raster interpolation

[Glynn Clements]

Markus Neteler wrote:

> >> However, there is another issue with r.proj (7.0) and r.proj.seg
> >> (6.x): bilinear and cubic interpolation give a small number of garbage
> >> results due to incorrect use of the caching mechanism (blocks are
> >> being replaced while references remain). I'll fix this shortly.
> >
> > This should be fixed by r43944.
> 
> The common backport question comes up for this one and r43943...
> Indications welcome.

Yes to both. Note that 7.0's r.proj is r.proj.seg in 6.x, which may
complicate matters.

Also, I believe that the off-by-half issue (r43943) affects the 6.x
r.proj, which will need a similar fix (but which will need to be done
manually). r43944 is only applicable to the newer version (r.proj.seg
and 7.0), not the 6.x r.proj.

FWIW, I found the errors using:

r.plane --o name=plane dip=30 azimuth=45 easting=599505 northing=4921010 elevation=1453 type=double
r.proj --o --q in=plane location=spearfish57 mapset=glynn output=plane.n method=nearest
r.proj --o --q in=plane location=spearfish57 mapset=glynn output=plane.l method=bilinear
r.proj --o --q in=plane location=spearfish57 mapset=glynn output=plane.c method=cubic
r.mapcalc --o 'diff.n = plane.n - plane'
r.mapcalc --o 'diff.l = plane.l - plane'
r.mapcalc --o 'diff.c = plane.c - plane'
r.info -r diff.n
r.info -r diff.l
r.info -r diff.c

[I had to modify r.proj not to complain about the source and
destination being identical. There's no reason why this should cause
problems, although I can't see any use for it other than testing.]

-- 
Glynn Clements <glynn at gclements.plus.com>