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

[Dylan Beaudette]

On Monday 14 August 2006 18:49, Glynn Clements wrote:
> Dylan Beaudette wrote:
> > Indeed the methods involved are
> > traditional _interpolation_ algorithms. As such, they might not be as
> > useful for moving from small grid sizes to larger grid sized
> > (aggregating).
>
> When used for downscaling, the result for each cell is still an
> interpolate of the 2x2 or 4x4 window of source cells surrounding the
> centre of the destination cell.
>
> This isn't necessarily wrong, but it's a completely different process
> to aggregation.
>

Agreed. I was having some terminology issues :) . A simple overview of this 
interpretation can be found here:

http://local.wasp.uwa.edu.au/~pbourke/colour/bicubic/

Therefore, I would suggest that we name the new version of (incorporating all 
three methods) r.resample - with suggestions on how to keep the original 
functionality further down:

> > > This module is for re-sampling and r.resample is the only good name I
> > > can think of currently.
> >
> > I also like the name r.resample, as it is a bit more general. perhaps
> > r.resample could be a script that calls r.interpolate / r.aggregate
> > based on the shift in resolution.
>
> The existing r.resample needs to remain, even if it is renamed to
> allow something else to use that name.

Yes. lets keep the _current_ r.resample functionality, but lets re-name it to 
something like r.resamp.default or r.resamp.g or r.resample.g ... (?) 
something to denote that this module is mimicking the internal NN resamplng.

> Also, I'm not sure that automatically choosing between interpolation
> and aggregation depending upon the scale factor is sensible. While
> aggregation is meaningless for scale factors below 1 (and largely
> meaningless for scale factors only marginally above 1), interpolation
> is meaningful for both reduction and enlargement.

Yet another good point Glynn. To keep things simple lets strive for keeping 
the concept of r.resample (its future self) consistant across scales.

> It all depends upon whether your cell values represent samples at
> specific points, or aggregates over a rectangular area. Both are
> meaningful.

This can be a tricky definition, and one that is a regular source of trouble: 
i.e. grid vs pixel registration, etc....

> [There's also the case where the scale factor is < 1 in one direction
> and > 1 in the other.]
>
> > > IMHO: drop r.bilinear, replace r.resample. To provide compatibility
> > > with old r.resample (that performed nearest neighbor only) set the
> > > default method=nearest. This will keep things simple and backward
> > > compatible.
> >
> > This also works, but I think that we will need to address the
> > aggregation problem soon.

just to follow this above comment up: yes. drop r.bilinear, re-name current 
r.resample to (?) and create new r.resample based on Gylnn's code - with some 
fixes for the bicubic case, as it appears to be broken.

> Aggregation should probably be done through a modification of
> r.neighbors. Rather than using a sliding window at the current
> resolution, you would compute the aggregate over the set of source
> cells corresponding to a single destination cell.
>
> As with r.bilinear, you would need to repeatedly switch regions to
> read the source at its native resolution while writing the result at
> the current resolution.
>
> Unlike r.bilinear, where the window size is determined solely by the
> method, an aggregation module would have the window size determined by
> the scale factor.
>
> 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...

Cheers,

-- 
Dylan Beaudette
Soils and Biogeochemistry Graduate Group
University of California at Davis
530.754.7341