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

[Dylan Beaudette]

On Saturday 12 August 2006 16:11, Glynn Clements wrote:
> Maciej Sieczka wrote:
> > > I've attached a modified version of r.bilinear which does
> > > nearest-neighbour, bilinear and bicubic interpolation. It's only been
> > > lightly tested, but the case where the source and destination regions
> > > match (exact copy) has been tested. It could use some testing at more
> > > extreme scale factors.
> > >
> > > It would be possible to speed it up a bit, at the expense of
> > > simplicity, by caching the horizontal interpolates for each row.
> > > However, even in its present form, it's still likely to be a lot
> > > faster than using the functions in sample.c.
> >
> > I have tested and compared your r.bilinear to gdalwarp output. I took
> > care to run gdalwarp and r.bilinear with identical settings.
> >
> > In case of naearest neigbor the output is identical.
> >
> > In case of biliner and bicubic there is a minor difference between the 2
> > programs output, min=-0.000002 and max=0.000002. Exactly the same in
> > case of both methods. But this is propably due to the bug that r.in.gdal
> > forces FCELL on output http://intevation.de/rt/webrt?serial_num=4897
> > while your r.bilinear outputs DCELL. So I guess it is not important.
>
> 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).
>
> > 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.

After a bit more testing I can see some interesting differences.

using the customized r.bilinear code previously posted:

#set the region
g.region res=10 -ap

#cutout a sample
r.mapcalc "c = elev_meters"

#"resample" 10m DEM data to 1m

# 1. via r.bilinear method=nearest
r.bilinear in=c out=c_n_1m method=nearest
# 2. via r.bilinear method=bilinear
r.bilinear in=c out=c_bc_1m method=bicubic
# 3. via r.bilinear method=bicubic
r.bilinear in=c out=c_b_1m method=bilinear

#visual comparison of slope computed at 1m
r.slope.aspect elev=c_b_1m slope=c_b_1m.slope
r.slope.aspect elev=c_bc_1m slope=c_bc_1m.slope
r.slope.aspect elev=c_n_1m slope=c_n_1m.slope

#reset the colors for each map
r.colors map=c_n_1m.slope color=gyr
r.colors map=c_b_1m.slope color=gyr
r.colors map=c_bc_1m.slope color=gyr

#see images:
##NN
http://169.237.35.250/~dylan/temp/raster_sampling/c_n_1m.slope.png

##Bilinear
http://169.237.35.250/~dylan/temp/raster_sampling/c_b_1m.slope.png

##Bicubic
http://169.237.35.250/~dylan/temp/raster_sampling/c_bc_1m.slope.png


note that the slope computed from the bicubic algorithm looks very similar to 
the NN slope map -- all computed via the new r.bilinear code. I was under the 
impression that the cubic output would be similar to the bilinear, 
but "smoother"...

Thoughts?




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