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

[Glynn Clements]

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

I've moved the aggregates from r.series/r.neighbors into a separate
library (lib/stats).

I have also written the aggregate resampling module; it supports all
of the existing aggregates which make sense for a resampling module,
namely: average,median,mode,minimum,maximum,quart1,quart3,perc90.

I'll commit it once a name has been agreed upon.

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