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 <gl...@gclements.plus.com> _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
