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

[Dylan Beaudette]

On 8/20/06, Glynn Clements <glynn at gclements.plus.com> wrote:
>
> 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.
>

wow. so this new functionality can deal with the resolutoin switching
issues - or was there a cleaner implementation? I am exctied about
testing these against the results from the raster-vector-raster
approach to aggregation that I posted a while back.

does r.aggregate make sense for a module name ?

Dylan

thanks for the hard work.