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

[Glynn Clements]

Dylan Beaudette wrote:

> Indeed the methods involved are
> traditional _interpolation_ algorithms. As such, they might not be as
> useful for moving from small grid sizes to larger grid sized
> (aggregating).

When used for downscaling, the result for each cell is still an
interpolate of the 2x2 or 4x4 window of source cells surrounding the
centre of the destination cell.

This isn't necessarily wrong, but it's a completely different process
to aggregation.

> > This module is for re-sampling and r.resample is the only good name I
> > can think of currently.
> 
> I also like the name r.resample, as it is a bit more general. perhaps
> r.resample could be a script that calls r.interpolate / r.aggregate
> based on the shift in resolution.

The existing r.resample needs to remain, even if it is renamed to
allow something else to use that name.

Also, I'm not sure that automatically choosing between interpolation
and aggregation depending upon the scale factor is sensible. While
aggregation is meaningless for scale factors below 1 (and largely
meaningless for scale factors only marginally above 1), interpolation
is meaningful for both reduction and enlargement.

It all depends upon whether your cell values represent samples at
specific points, or aggregates over a rectangular area. Both are
meaningful.

[There's also the case where the scale factor is < 1 in one direction
and > 1 in the other.]

> > IMHO: drop r.bilinear, replace r.resample. To provide compatibility with
> > old r.resample (that performed nearest neighbor only) set the default
> > method=nearest. This will keep things simple and backward compatible.
> 
> This also works, but I think that we will need to address the
> aggregation problem soon.

Aggregation should probably be done through a modification of
r.neighbors. Rather than using a sliding window at the current
resolution, you would compute the aggregate over the set of source
cells corresponding to a single destination cell.

As with r.bilinear, you would need to repeatedly switch regions to
read the source at its native resolution while writing the result at
the current resolution.

Unlike r.bilinear, where the window size is determined solely by the
method, an aggregation module would have the window size determined by
the scale factor.

This would require some modification to the I/O strategy, specifically
the number of rows kept in memory would vary at run-time, and would
vary from row to row (the number of source rows and columns
corresponding to each destination cell would vary by 1; e.g. a scale
factor 3.5 would result in a destination cell corresponding to 3x3,
3x4, 4x3 or 4x4 source cells).

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