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

[Dylan Beaudette]

On Sunday 13 August 2006 13:52, Glynn Clements wrote:
> Maciej Sieczka wrote:
> > > For IEEE single precision, FLT_EPSILON is ~1.2e-7, so a value of
> > > around 16-17 would have an absolute error of ~2e-6 just due to
> > > rounding error. "r.info slope" indicates that the range of the data is
> > > between zero and 52.5, so that error seems reasonable.
> > >
> > >> (A bit OT: what are the Grass equivalents for Gdal's
> > >> Int16,UInt16,UInt32,Int32,Float32,Float64,CInt16,CInt32,CFloat32,CFloa
> > >>t64? I'd like to put such note into r.out.gdal manual, it always
> > >> puzzles me).
> > >
> > > I'm not sure there are equivalents.
> > >
> > > Internally, GRASS has three types: CELL (C "int", typically 32-bit
> > > signed integer), FCELL (C "float", typically 32-bit IEEE
> > > single-precision floating-point) and DCELL (C "double", typically
> > > 64-bit IEEE double-precision floating-point).
> >
> > OK, thanks for clarification. In that case, what are the *most*
> > appropriate GDAL datatype equivalents for Grass's CELL, FCELL and DCELL?
>
> AFAICT, the GDAL types would be Int32, Float32 and Float64
> respectively.
>
> > >> I was wondering what name should be given to the module. IMO it should
> > >> replace r.resample and r.bilinear should be removed. Is it acceptable
> > >> for Grass 6.3?
> > >
> > > I would suggest keeping r.resample. Its output is the result of GRASS'
> > > built-in resampling, and is exactly what any raster module would
> > > obtain from reading the map with the current region settings. The
> > > output from method=nearest in the module which I sent may differ due
> > > to rounding error.
> >
> > If I do some checking and it shows it doesn't differ, would that change
> > your attitude (even the backwards-compatibility could be assured by
> > setting the default resample method to nearest neighbor (if that's not
> > the case yet))?
>
> It would need to produce exactly the same result for all possible
> regions, which isn't something which can be verified empirically.

How about this: 
1. keep r.resample and update the documentation accordinly. 
2. toss r.bilinear, possibly leave a note somewhere in the docs
3. create a new module 'r.resample.3' (?) for the three methods that it would 
do? or 'r.interpolate' (?)

Note: the r.interpolate name would make sense for moving from larger to 
smaller grid spacing ( 100m -> 10m), however it wouldn't make as much sense 
for moving from smaller to larger grid spacing (10m -> 100m). In this case 
something like r.aggregate  would make more sense. However this potentially 
opens a new can of worms- as there are many ways to aggregate cells... which 
might call for a new vector / raster module.

Cheers,

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