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

E. Jorge Tizado ejtizado at ono.com
Tue May 26 15:01:22 EDT 2009


Hi,

> 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? 

Yes.
I send a the proposed files. 
The only apparent change of default behaviour is (now) a required value to 
power parameter (no 2.0 by default) to be more conscient with the real weight 
applied to squared distance (and it is not default for gaussian).

The gaussian function is implemented with the flag -g.
I remove the previous 'bandwidth' parameter and use the power parameter to do 
it (less changes and optimizing resources).

> 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" ???

I like this description. Set in main.c

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

few details added to description.html


Jorge

> 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/sant
> >afe.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/VennellBeatsonADCPtidalRBF20
> >06preprint.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



-- 
E. Jorge Tizado
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/grass-dev/attachments/20090526/076f2732/description-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: main.c
Type: text/x-csrc
Size: 15796 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/grass-dev/attachments/20090526/076f2732/main-0001.bin


More information about the grass-dev mailing list