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

[Glynn Clements]

Maciej Sieczka 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.
> 
> That's right. But there is one situation when the output *will* be CELL
> for sure - if the input is CELL and method=nearest.

In that case, the output can be converted to CELL without loss of
precision, but the output isn't actually CELL. This matters if you
feed the result to r.mapcalc, where the result of e.g.
"r.mapcalc out = in / 2" will produce different results for integer
and floating point inputs.

> Maybe your resample module could take that into account?

As I said, personally I don't think that's a good idea. It's usually
better to let the user handle "special cases" themselves *if* they
want to, rather than handling them automatically then forcing the user
to try to "undo" them.

As the processing "pipeline" gets longer, special cases tend to
combine exponentially, with the end result that the overall process
becomes impossibly hard to document or even understand.

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

Note that the region parameters are all C "double" values, so anything
that involves arithmentic using the interpolation fractions needs to
produce a DCELL result. For the "nearest" method, you could use the
force the output type to match the input type (i.e. CELL in gives CELL
out, FCELL in gives FCELL out, etc).

But if further methods were added (and there is essentially no limit
to the number of interpolation methods available), every method except
nearest would naturally produce DCELL output. IMHO, it's preferable to
simply always produce DCELL output than to create a special case for
one specific method.

In any case, anyone who wants the output to values to exactly match
the input values for the nearest case may as well use the existing
r.resample (which needs to be retained, even if it is renamed to
allow something else to use that name).

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