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

[Dylan Beaudette]

On Monday 14 August 2006 19:06, Glynn Clements wrote:
> 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).

Ok. I will accept this. default output to DCELL from the new r.resample sounds 
ok to me.

-- 
Dylan Beaudette
Soils and Biogeochemistry Graduate Group
University of California at Davis
530.754.7341