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

GRASS GRASS developer
1

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

2

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@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@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.

3

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@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev

--
E. Jorge Tizado

(attachments)

description.html (3.56 KB)
main.c (15.4 KB)