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

[Glynn Clements]

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,CFloat64?
> >>  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.

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