[gdal-dev] Interesting issue with ogr2ogr and -tps
Even Rouault
even.rouault at spatialys.com
Tue Jun 27 04:58:14 PDT 2017
On mardi 27 juin 2017 07:34:59 CEST Rahkonen Jukka (MML) wrote:
> Hi,
>
> There is a well written question in gis.stackexchange about how the -tps
> option in ogr2ogr behaves
> https://gis.stackexchange.com/questions/245391/ogr2org-tps-spline-method-cr
> eates-progressive-error
>
> Does anybody have a clue about what happens?
TPS is supposed to be exact at GCP, and interpolate between them. That said, it looks from
this report like there might be a numerical stability issue. There are 2 solvers for the TPS
transformer: a built-in that does matrix inversion "at hand" using Gauss-Jordan elimination
method (the one that is taught at school if I remember well -:) ), and another one that uses
the armadillo library that is faster and relates underneath on well proven numerical
computation libraries (blas/lapack). I don't think osgeo4w builds use armadillo (actually I
don't see anything in the nmake.opt related to armadillo).
That said, I see that the Gauss-Jordan implementation usd uses the "partial pivonting"
mentionned in
https://en.wikipedia.org/wiki/Pivot_element#Partial_and_complete_pivoting so this should
normally account for most numerical stabilities issues.
So either the user is rather unlikely and has encountered a case where numerical instability
occur, either his test/GCPs are wrong.
And I wouldn't have anticipated that numerical stabilities issues have such a north-to-south
pattern, but perhaps...
Even
--
Spatialys - Geospatial professional services
http://www.spatialys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20170627/241190c7/attachment-0001.html>
More information about the gdal-dev
mailing list