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

[Dylan Beaudette]

On 8/20/06, Glynn Clements <glynn at gclements.plus.com> 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.
> > > >
> > > > 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.
>
> The new module uses resolution switching: read the source map at its
> native resolution, write the result at the current region's
> resolution. The value in each output cell is an aggregate over the set
> of input cells whose centres lie within the bounds of the output cell.
>
> > does r.aggregate make sense for a module name ?
>
> My local copy is named r.resamp.aggregate, although that might be a
> bit too long.
>

Glynn. This sounds great. module names... some more  ideas:
r.resamp.aggr
r.aggregate (with link and keywords relating it to the other resamp. modules)

looking forward to seeing this in CVS.

Dylan