[GRASS-user] integration of sample.c algorithms into r.resample

[Dylan Beaudette]

On 8/14/06, Maciej Sieczka <tutey at o2.pl> wrote:
> Glynn Clements napisa?(a):
> > Dylan Beaudette wrote:
> >
> >> When I use your new version of r.bilinear method=nearest on a CELL image, the
> >> output is DCELL. While this can be fixed with r.mapcalc it shouldn't be too
> >> hard to add this to the new module (?) .
> >
> > It's easy enough to change, although I'm not sure whether it's the
> > right thing to do. It's arguable that the *only* difference between
> > the methods should be the way in which the result is calculated. Out
> > of the nine possible combinations of CELL/FCELL/DCELL input and
> > nearest/bilinear/bicubic methods, at least 8 of them will produce a
> > floating-point output map, so consistency would favour doing likewise
> > for the one remaining combination.
>
> > Whilst it would be possible to forcibly convert a CELL result to
> > FCELL/DCELL with r.mapcalc in cases where that was required, it might
> > not necessarily be obvious that a conversion is necessary until the
> > first time you actually use method=nearest and end up having to figure
> > out what happened.
>
> Glynn,
>
> That's right. But there is one situation when the output *will* be CELL
> for sure - if the input is CELL and method=nearest. Maybe your resample
> module could take that into account?
>
> Other combinations are indeed hard to predict, as the most appropriate
> output datatype will also depend on the combinations of output region
> extent and input/output cell size and shape. So I guess defaulting to
> DCELL is very good idea.
>
> Maciek
>

I agree with Maciek, in all cases but one defaulting to DCELL seems
like a good idea. However, it might be overly confusing / complicated
when an input map and NN interpolation produce a DCELL map. However, I
found that truncating the DCELL to CELL values worked perfectly well.

Dylan