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

[Glynn Clements]

Dylan Beaudette wrote:

> > 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).
> 
> Looks like getting the aggregation to work within a C module will be a bit 
> difficult. r.neighbors was my initial thought for this type of functionality, 
> but it might complicate the tool chain as you have said down thread...

The main reason why I suggest r.neighbors is that it already has a set
of aggregate functions.

Hmm; so does r.series. It's been suggested before to make a library of
aggregate functions which could be used by multiple modules. Such
discussions have tended to get bogged down with issues related to
modules such as r.statistics, which need to compute aggregates over a
large number of samples.

If we have 3 modules which need to compute aggregates over a
relatively small number of samples, it's probably worth making a
library from the code for r.series and/or r.neighbors to use with such
modules. We can leave the more complex case (r.statistics) for later.

But first, I need to figure out what's wrong with the updated bicubic
interpolation equations.

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