s.surf.tps

[Precision Farming Project]

In article <199603252141.PAA04862 at rogue.gis.uiuc.edu>, 
helena at gis.uiuc.edu says...
>
>
>>One of my users recently  started (or trying) using the
>>alpha/garden routine s.surf.tps.  At least on our site,
>>this routine is worse than useless.  My users first attempt
>>was on a fairly large data set (20,000 points: combine trajectory
>>data), and the only response was floating point exception.
>>Working with small data sets (less than 400 points), with no
>>mask file, I can get s.surf.tps to ``surface'' 1, 2, 3, or 6
>>data points out of 347.  All other points are ignored for
>>being out of the region (even thought the site list file
>>shows them to be in the region).  If I somehow stumble across a
>>set of parameters (dmin, tension, smooth, segmax, npmin) that
>>will surface through 6 points, and immediately re-run s.surf.tps
>>with EXACTLY the same parameters, it only surfaces through 3 points.
>>This seems likely to be a problem of using some value somewhere
>>in s.surf.tps BEFORE it is set.
>
>Has anybody used s.surf.tps with this version of GRASS?
>Do you get any warnings or error messages from
>the program, have you checked your region and resolution properly
>(run d.sites with the same region you are using when running
>s.surf.tps)

Using d.sites and d.rast, the 1, 2, 3 or 6 data points it
manages to fit are all within the displayed region, as are
the 34x sites it says are not in the region.

>as well as the format of your site data? (it should be x|y|#z, but
>if it is not, you should get warning from the program).
>The selection of points which are taken for the interpolation is 
 completely
>controled by g.region. The program would remove the data points
>within the given region if they are closer to each other than dmin,
>but that would mean that your region has only couple of rows and
>columns when you get only 6 points, so I guess that the problem
>is in the region.

I can set d.min to ridiculously small or large values, based on
the point density, with NO effect on the number of points
chosen (well, if I set d.min to more than about half that maximum
distance in the region, it only finds one or two points, instead
of 3 or 6).

The fact that re-running the program with the SAME DATA and the
SAME command line parameters, and yet the ``supposed'' number of
valid data points changes between the two runs leads me to
believe that the problem is not with the data or the command
line parameters.  The most likely suspect is (IMHO) the use
of some variable in s.surf.tps before it is set.  Was s.surf.tps
run through lint at some time (this would catch this kind of problem).

>20,000 points shouldn't be a problem, the program was used  with
>much larger data sets. Please send me everything what program writes
>and if that is not enough I can try to run the program here
>for your data subset with our version of s.surf.tps, just to make sure
>that nobody has changed anything in s.surf.tps for the release
>you are using.
>
>Helena Mitasova
>GMS Lab
>University of Illinois
>

Gordon Haverland, P.Eng.
Precision Farming Project
Alberta Agriculture
ghaverla at freenet.edmonton.ab.ca
goddard at gpu.srv.ualberta.ca