<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font face="Times New Roman, Times, serif">Not sure whether this can
be considered a bug, so I give it for what it is worth. <br>
<br>
I'm doing thin plate spline transformation from one set of
projected coordinates to another. Both sets have values between
-600000 and 600000 (meters). A typical set of gcps looks like:<br>
<br>
-gcp 62402 -74383 181915 315371 \<br>
-gcp -100169 -24213 19685 366661 \<br>
-gcp 118323 233822 239994 623190 \<br>
...<br>
<br>
When transforming the the first two columns of this list with
gdaltransform -tps, using the same gcp-list, the results should be
exactly equal to the last two columns:<br>
<br>
(from gdal_tps.cpp:)<br>
<font face="Courier New, Courier, monospace">* The thin plate
spline transformer produces exact transformation<br>
* at all control points and smoothly varying transformations
between<br>
* control points with greatest influence from local control
points. <br>
* It is suitable for for many applications not well modelled by
polynomial<br>
* transformations. <br>
*<br>
<br>
<br>
<font face="Times New Roman, Times, serif">However, they aren't.
With a few control points the differences are only in
millimeters, but with a few hundred gcps the differences
become meters, and above thousand points the error can get to
fifty meters. The problem gets worse when some control points
are very near to other ones. I was happy to discover that
dividing all numbers by 1000 solves the problem, but there
certainly is a numerical instability in the algorithm.<br>
<br>
Of course, thin plate spline transformations normally use scan
coordinates as input, and these are almost always small
numbers. Even so, I can imagine problems with very large
rasters and the rubber sheeting applications I am working
with. <br>
<br>
Jan <br>
</font><br>
<br>
</font></font>
</body>
</html>