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

[Glynn Clements]

Maciej Sieczka wrote:

> >> How about this: 
> >> 1. keep r.resample and update the documentation accordinly. 
> >> 2. toss r.bilinear, possibly leave a note somewhere in the docs
> > 
> > Or replace it with a script which calls "r.interpolate method=bilinear".
> > 
> >> 3. create a new module 'r.resample.3' (?) for the three methods that it would 
> >> do? or 'r.interpolate' (?)
> > 
> > I prefer r.interpolate.
> 
> If I may not agree - *inter* suggests this module will be able to fill
> null gaps.

Not really; r.fillnulls is probably the correct name for that.

> This is not the case. It will even make the opposite - make
> the gaps bigger in the output for method= bilinear and bicubic, if nulls
> are present in the input.
> 
> This module is for re-sampling and r.resample is the only good name I
> can think of currently.

For the bilinear/bicubic methods, the values in the output map aren't
samples, but interpolates of samples.

> 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.

"r.<whatever> method=nearest" isn't compatible with r.resample. Even
if you can get the arithmetic such that it exactly matches the current
behaviour of libgis' built-in resampling, there are no guarantees that
this will remain true in future Or even that it will be true for all
combinations of compilation switches (e.g. -ffast-math etc).

IMHO, there needs to be at least one module which does exactly what
r.resample does now, i.e. writes out *exactly* the same data which any
normal raster module will get from G_get_raster_row() etc.

As r.resample already does this, I propose to leave it untouched.

> If it is necessary to mantain r.bilinear compatibilty, make it a script
> that calls r.resample method=bilinear.

I don't have any problem with either r.bilinear to a script.

-- 
Glynn Clements <glynn at gclements.plus.com>