[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.
> >
> > 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 Clements <glynn at gclements.plus.com>