[gdal-dev] ogr2ogr -tps with more than 1000 control points

[Martin.Franzke at telekom.de]

Hi Jan,

I had a similar problem, which was solved by normalizing the TPS equations. The patch (https://github.com/OSGeo/gdal/commit/c85c58ac781ef781cd126006d91cb5eed2dd53e2) is included in gdal versions >= 2.4. This may help you as well.

Martin

-----Ursprüngliche Nachricht-----
Von: gdal-dev <gdal-dev-bounces at lists.osgeo.org> Im Auftrag von Jan Hartmann
Gesendet: Freitag, 9. August 2019 21:18
An: Even Rouault <even.rouault at spatialys.com>
Cc: gdal-dev at lists.osgeo.org
Betreff: Re: [gdal-dev] ogr2ogr -tps with more than 1000 control points

Yes, I already noticed that. But a run with thousand gcp's is still quite fast. I am looking for a smart way to segment these large maps. 
You cannot rubbersheet them in many  parts, because then the borders won't fit any more. The only thing I can come up with at the moment is creating common points on the borders of adjacent parts, and adding them to the control points. If you have any ideas, let me know.

Jan

On 8/9/2019 8:19 PM, Even Rouault wrote:
> On vendredi 9 août 2019 20:08:31 CEST Jan Hartmann wrote:
>> Thanks Even. GDAL was built with Armadillo, so I'm going to test the
>> GCP's. Just wanted to be sure there was no possibility of a buffer
>> overflow, or something like that. The program should be able to handle
>> an unlimited number of control points, right?
> I'd rather say there's no hard-coded limit ;-) But the processing time will
> increase with the number of GCPs: linearly when applying the result of the GCP
> adjustment for each point transformed, and with an initial computation cost of
> the adjustment coefficients that has a complexiy a bit below O(n^3).
>
> Even
>

_______________________________________________
gdal-dev mailing list
gdal-dev at lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev