[GRASS-dev] v.surf.idw: a improvement

[Benjamin Ducke]

Thanks, Jorge and Hamish for elaborating on this.

If I understand correctly, then Jorge's additions could be integrated
seamlessly into v.surf.idw, that is without breaking/changing its
default behaviour? If so, I am in favour of integrating these additions
into SVN.

I agree that we should stick with the established terminology. I think
the best we might be to extend the module description to something
like:

"Surface interpolation from vector point data by Inverse Distance
Squared Weighting and Radial Basis Functions" ???

Some additional details for the HTML man page would also be good.

Ben


Hamish wrote:
> Benjamin wrote:
>> A bit of web searching for  "Interpolation Distance Weight" or
>> "Exponential Interpolation" (i.e. related to GIS and spatial
>> interpolation). did not produce anything meaningful for me.
>> Could you point me to some literature where I can find
>> more information on this?
> 
> do a search for "radial basis functions".
> 
> e.g. a quick visit google finds:
>   http://en.wikipedia.org/wiki/Radial_basis_function
>   http://www.cs.ualberta.ca/~sutton/book/8/node7.html
>   http://www.ncgia.ucsb.edu/conf/SANTA_FE_CD-ROM/sf_papers/fogel_david/santafe.html
> 
> 
> my knowledge of it is mostly from its application to interpolating 2 or
> 3 coupled-component velocity vectors between sampling sites. e.g. this
> from the Journal of Geophysical Research Sept 2006:
>  http://www.otago.ac.nz/marinescience/po/pdfs/VennellBeatsonADCPtidalRBF2006preprint.pdf
> 
> 
> you can play with some simple decay function variations in the v.surf.icw
> and r.surf.volcano scripts in wiki addons.
> 
> e.g. 1/d^2 gives better transitions for interpolations, but 1/d^3 better
> deals with minimizing errors due to unconstrained boundaries for
> extrapolations.
> 
> 
> 
> IMHO the well known meaning of the "IDW" acronym shouldn't be changed by
> us as people may try a search for the known meaning. Augmented, well
> have fun, especially if you can cite a validation in the literature.
> 
> Personally my main hope for GRASS in this area is to see the segmentation
> code improved in the RST modules so that the "block effect" in areas of
> high point-density gradient can be automatically tuned away. ie. for 
> most situations why worry much about simple IDW when you have a much more
> advanced thin plate spline solution already there as a drop-in replacement?
> 
> oh yeah, and update r.surf.contour from its current GRASS 4-era level.
> (0 elev in input data is treated as null; integer-only output)
> 
> 
> Hamish
> 
> 
> 
>       
> 
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
> 
> 


-- 
Benjamin Ducke
Senior Geospatial Consultant

Oxford Archaeology
Janus House
Osney Mead
OX2 0ES
Oxford, U.K.

Tel: +44 (0)1865 263 800 (switchboard)
Tel: +44 (0)1865 980 758 (direct)
Fax :+44 (0)1865 793 496
benjamin.ducke at oxfordarch.co.uk




------
Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information.