[gdal-dev] Interesting issue with ogr2ogr and -tps

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[gdal-dev] Interesting issue with ogr2ogr and -tps

jratike80

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-creates-progressive-error

 

Does anybody have a clue about what happens?

 

-Jukka Rahkonen-


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Interesting issue with ogr2ogr and -tps

Even Rouault-2

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


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Loading...