Thanks Martin, I upgraded to GDAL 2.4.2, and now it works. The problem
was with control points being too near to each other. GDAL 2.4.2 even
worked on a testcase with two control points on the same location.
That's important, for I want to rubbersheet historical maps as exactly
as possible, and for that I use interpolated values between the control
point that have been set manually. In some case these interpolated
values end up at very small distances, and now gdal doesn't break on
them any more.
Regards,
Jan
On 13-8-2019 9:42, [email protected] wrote:
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 <[email protected]> Im Auftrag von Jan Hartmann
Gesendet: Freitag, 9. August 2019 21:18
An: Even Rouault <[email protected]>
Cc: [email protected]
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
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
