interpolation, rast.to.sites

[Michael Hill]

On Fri, 2 Jul 93 18:02:28 EST, Simon Cox wrote:

>
>I have been told that s.surf.tps is the "best" interpolater available
>in grass.  Why is this?  My little experience with it has shown
>that it is certainly not quick!  What are its relative merits,
>in comparison with idw and idw2?
>
>What is the easiest way to convert a raster to a site list, so
>that I can use the s.surf.tps interpolater?  Is it necessary to
>go via an ascii intermediate step?
>
>Thanks for your advice.
>
>Simon Cox
>

Simon,

I should plead guilty to an oversimplification in my comment to you about 
interpolators in grass. I have been interested to read the various 
responses on the grassu-list. Interpolation is a complicated issue, since 
by its very nature one is trying to "put data where none exists".

I am currently heavily involved in using interpolators of all sorts, from 
the idw type, through ArcInfo's tin, to s.surf.tps, to the spline software 
developed by Mike Hutchinson which allows the use of independent variables 
and/or covariates to "improve" the quality of a surface where something is 
known about the relationship between your target data, and another 
variable for which you have more data points, or even a grid.

Where you have sparse data, with a poor coverage, s.surf.idw does a good 
job of giving you a surface which reflects the data you have, and nothing 
more. But with sparse data, as I have from a model run on eastern 
Australia, you get all sorts of unsatisfactory  spots and regions which 
you know do not reflect the real response surface. A tin (triangular 
irregular network can do a little better job and readily restrict you 
surface to a convex hull about your points, avoiding the strange 
happenings which can occur for instance with splines.

I feel that s.surf.tps is a great innovation for grass ( the proposed 
semivariogram kriging routine will also be a great addition), however it 
does require a good even coverage of points, and fiddling with the tension 
and other parameters to avoid the spectacular over- and under-shoots which 
can occur in "data holes" and bare edge patches. 

Dealing as I do with pasture models, requiring long runs of complete 
climate data sets, inevitably I end up with a sparse set of data points. 
However, if my model output is, say, dry matter yield, I have a good basis 
for saying that independent grids of rainfall, elevation, temperature etc 
will have quite predictable relationships with my model output. It is in 
this area, that the algorithms which Hutchinson has developed, using 
covariate relationships or independent variables, are hard to beat.

As I remember it, you were trying to contour a raster map. I guess my 
experience with the grass raster contouring is the same as yours. Very 
slow. Being an impatient soul, and flipping from program to program, I 
prefer to regard rasters as simply arrays of points and to operate on 
them, or subsamples of them, as such. Arc/Info has a nice "very important 
point" (VIP) extraction routine to overcome the time and processing 
problems of contouring, etc., very dense grids or point sets.

Interpolation is an area where different routines suit different tasks, 
and sometimes the most simple say idw may be quite appropriate since it 
represents the data, and does not OVERSTATE the precision. 

I would repeat my suggestion that if you are unhappy with the speed of r.
surf.contour, try extracting a representative subsample of your grid cells 
as points and see what s.surf.tps will do. You should have a good coverage 
of points. The only reservation is that it would be better to extract the 
say 10% of cells which statisically best describe the variation in your 
data. I am not sure that there is a way to do this in grass.

Just a final important general point. Surface generation is all about a 
better representation of sparse real data. The primary concern should 
always be with not overfitting the surface, retaining a suitable humility 
about the error levels in your surface, and the respect for the 
limitations imposed by the quality, accuracy and portability of the base 
data.



Apologies to those not interested in this, but I don't often burden you 
with my thoughts


Michael Hill


Michael J Hill
Research Scientist
CSIRO Pastoral Research Laboratory, Armidale, NSW, Australia,2350.
E-Mail address: mhill at chiswick.anprod.csiro.au