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

Dylan Beaudette dylan.beaudette at gmail.com
Mon Aug 14 17:17:25 EDT 2006


On Monday 14 August 2006 14:08, Dylan Beaudette wrote:
> 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,CFloat
> > >64 ? 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?

note that i left out a 

g.region res=1 -a

before performing the r.bilinear commands.




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




More information about the grass-user mailing list