Die TPS-Spline-Methode ogr2ogr erzeugt einen progressiven Fehler


8

Ich versuche, ein Shapefile mithilfe der Spline- Transformation von ogr2ogr mit cmd-Befehlen wie den folgenden anzupassen :

C:\OSGeo4W64\bin\ogr2ogr.exe -f "ESRI Shapefile" C:\path\output.shp -tps --optfile C:\path\gcp.txt C:\path\input.shp

Ich habe mehr als 1000 Kontrollpunkte (sie befinden sich also in einer separaten Datei ). Und ich habe seltsame Probleme mit der Präzision dieser Methode. Ich habe in dieser Frage bereits gesehen , dass die Spline-Methode von ogr2org nicht wirklich genau ist. Aber mit meiner Anzahl an GCP und dem Umfang meines Datensatzes sehe ich, dass die Genauigkeit von Nord nach Süd dramatisch abnimmt. So was: Spline-Fehler

Im Norden ist die Methode fast genau (0,001 m Fehler), dann verliert sie sanft die Präzision und im Süden erzeugt sie einen Fehler von etwa 60 m.

Ich berechnete den RMSE für jeden GCP und zeichnete ihn gegen die Koordinaten und die ID-Nummer des Kontrollpunkts auf (ich erstellte den GCP hauptsächlich von Norden aus). Und ich habe:

y Fehler x Fehler ID-Fehler

Ich habe versucht, den Quellcode von gdal zu finden und zu lesen (ich habe die Module gdal_tps , thinplatespline und ogr2ogr_lib gefunden ), aber ich kenne diese Sprache (C ++?) Nicht und verstehe nicht, wie die Methode funktioniert. Die Polynome 1, 2 und 3 in der Reihenfolge ogr2ogr funktionieren einwandfrei (es handelt sich nicht um exakte Methoden, aber der Fehler schreitet nicht voran).

Warum nimmt die Spline-Genauigkeit in Abhängigkeit von der Y-Koordinate logarithmisch ab? (Für die X-Koordinate sehe ich alle 16000 m Präzisionssprünge). Wie ist das möglich? Wie funktioniert diese Anpassungsmethode? Wie kann ich dieses Problem lösen? (Ich habe Windows 7, 64 Bit)


2
Der GDAL-Entwickler hat eine vorläufige Analyse in lists.osgeo.org/pipermail/gdal-dev/2017-June/046816.html durchgeführt . Vielleicht sollten Sie sich dieser Diskussion anschließen.
user30184

Können Sie die GCPs teilen? Überprüft die Ergebnisse, überprüft die Koeffizienten usw. Das Denken kann erklärt und die Instabilität minimiert werden. Vielen Dank!
David

Antworten:


4

Die Antwort des GDAL-Entwicklers Even Rouault hat mir wirklich geholfen, die richtige Richtung anzugeben.

Da ich wusste, dass dies ein Fall numerischer Instabilität ist und (aus meiner CFD-Erfahrung) wusste, dass Instabilität durch sehr kleine Datenwerte verursacht werden kann, analysierte ich meine Kontrollpunkte. Ich konstruierte TIN, berechnete Abstände zwischen GCP und stellte fest, dass 2 Punkte versehentlich extrem nahe beieinander lagen (fast übereinstimmend, 3 m Abstand zwischen ihnen). Als ich einen von ihnen entfernte, funktionierte Spline perfekt.

Dieses Punktepaar befand sich ganz im Norden, sodass die Instabilität von Norden nach Süden begann.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.