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

[Dylan Beaudette]

On Tuesday 15 August 2006 14:12, Maciej Sieczka wrote:
> Dylan Beaudette napisa?(a):
> > just to follow this above comment up: yes. drop r.bilinear, re-name
> > current r.resample to (?) and create new r.resample based on Gylnn's code
>
> Glynn opts for keeping the old r.resample untouched, and I agree he has
> a point. So I won't insist on replacing it, anymore.

good enough for me.

> Out of other names already suggested, having considered Glynn's
> clarifications about interpolation vs resampling, I find r.interpolate
> best, in this case.

ok. Len Coop also suggested 'r.spatial.rescale' thoughts?

> > - with some
> > fixes for the bicubic case, as it appears to be broken.
>
> Are you refferring to your observations of "weird" slope derivatives of
> dems treated with bicubic, ie.
>
> > ##Bicubic
> > http://169.237.35.250/~dylan/temp/raster_sampling/c_bc_1m.slope.png
>
> ?

I was referring to the fact that the bicubic implementation from sample.c (and 
revious by Glynn) is not producing the correct output. This is resulting in 
both strange output and strange derivative output.

> If so, how does 'gdawalrp -rc' perform for you? Semething like:
>
> $ r.out.gdal input=dem type=Float32 output=dem.tif
>
> $ gdalwarp -te 589980 4913685 609000 4928040 -tr 1 1 -rc dem.tif
> gdal_dem.bic.tif
> # you need to control the working window with -te switch explicitely to
> # mimic Grass region handling
>
> $ r.in.gdal input=gdal_dem.bic.tif output=gdal_dem.bic
> $ r.slope.aspect ...
>
> (I'm asking this becaues I always found 'gdalwarp -rc' output correct,
> so the eventuall difference might be a pointer.)
>
> ???
>
> Maciek

For the time being, I am quite sure that the bicubic interpolation is not 
working within the currently modified r.bilinear. 

However:

1. when using the new equations [1], i get correct results when my input 
raster 
actually extends beyond the current region, and when I move from small res to 
large res : 10m to 100m. 

2. when I try the same, but with a raster that _does not_ extend beyond the 
current region, i get odd results, from what looks like accessing an array 
with a bad index (?):


1.
DCELL c0 = (u * (u * (u * (c30 - 3*c20 + 3*c10 - c00) + (-c30 + 2*c20  -
5*c10 + 2*c00)) + (c20 - c00)) + 2*c10)/2; DCELL c1 = (u * (u * (u * (c31 -
3*c21 + 3*c11 - c01) + (-c31 + 2*c21  - 5*c11 + 2*c01)) + (c21 - c01)) +
2*c11)/2; DCELL c2 = (u * (u * (u * (c32 - 3*c22 + 3*c12 - c02) + (-c32 +
2*c22  - 5*c12 + 2*c02)) + (c22 - c02)) + 2*c12)/2; DCELL c3 = (u * (u * (u
* (c33 - 3*c23 + 3*c13 - c03) + (-c33 + 2*c23  - 5*c13 + 2*c03)) + (c23 -
c03)) + 2*c13)/2; DCELL c  = (v * (v * (v * (c3  - 3*c2  + 3*c1  - c0 ) +
(-c3  + 2*c2   - 5*c1  + 2*c0 )) + (c2  - c0 )) + 2*c1 )/2;


In summary, it looks like we almost have the naming figured out, but there is 
still something not quite right with the bicubic method: both the one from 
sample.c and the recently corrected version by Glynn.

Cheers,

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