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

[Dylan Beaudette]

On Wednesday 16 August 2006 01:20, Glynn Clements wrote:
> 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.

Agreed. Lets tackle this after r.interpolate (?) is ready.


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

Looks like the bicubic interpolation is almost there
-- 
Dylan Beaudette
Soils and Biogeochemistry Graduate Group
University of California at Davis
530.754.7341