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

[Hamish]

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