KooTransSN/GeoTKF: Relevanz des PROJ.4-Fehlers #209

Fragen, Hinweise und Verbesserungsvorschläge
Dereje

KooTransSN/GeoTKF: Relevanz des PROJ.4-Fehlers #209

Beitrag von Dereje » 30. April 2015, 16:26

Laut: http://www.landesvermessung.sachsen.de/ ... .html#faq6
gibt es bei der offenen Bibliothek PROJ.4 einen Fehler (bug Nr. 209, siehe: http://trac.osgeo.org/proj/ticket/209), der lt. Aussage von GeoSN dazu führt, dass mitunter unzuverlässige Ergebnisse am Rand der Subgitter erzeugt werden.

In wieweit ist dieses Problem auch für KooTrans_SN zutreffend, und was könnte man tun, um es zu umgehen? In der oben angegebenen FAQ (siehe obigen link) ist dazu ein Hinweis für QGIS gegeben.

Ich würde mich freuen, wenn es dazu eine klare Aussage gibt, die mir hilft, die zu erwartende Genauigkeit der KooTransSN und GeoTKF-Software einzuschätzen.

Vielen Dank,
Dereje
Benutzeravatar
steffen
Site Admin
Beiträge: 59
Registriert: 22. Mai 2014, 12:36
Kontaktdaten:

Re: KooTransSN/GeoTKF: Relevanz des PROJ.4-Fehlers #209

Beitrag von steffen » 30. April 2015, 20:01

Hallo Dereje,
ich hatte zu diesem Thema schon Kontakt zum GeoSN und habe mir auch den entsprechenden fehlerhaften Koordinatenbereich geben lassen.

Ich kann den beschriebenen groben Fehler bei mir nicht nachvollziehen, d.h. meine beiden Programme arbeiten offensichtlich korrekt.
Beim Transformieren von Koordinaten- und DXF-Dateien erfolgt bei mir außerdem parallel zur ntv2-Transformation eine 7-Parameter Kontrollrechnung. Somit würde beim Auftreten dieses Fehlers sofort "Alarm" geschlagen.
Ich bin mir also sicher, dass der Fehler (keine Datumstransformation im Randbereich) bei KooTransSN und GeoTKF so nicht auftritt.

Ich habe mir QGIS mal testweise installiert und ein massives Problem bei der Darstellung einer UTM-Datei im GK-System mit Hilfe der sächsischen NTv2 festgestellt. Hier werden in einem Bereich von wenigen cm um den Rand der Subgitter Punkte nicht "datumstransformiert", dh. es tritt ein Fehler von > 150m auf.
Diese Problem betrifft aber scheinbar nur die Darstellung und kann durch die von GeoSN beschriebene Kaskade verhindert werden.
Eine Transformation der entsprechenden Datei selbst (z.B. auch mit KooTransSN und GeoTKF) sollte dieses Problem beseitigen.

Die Lage der Randbereiche der Subgitter kann man einfach ermitteln indem man sich die oben verlinkten Subgitter des GeoSN in GeoTKF einliest und analysieren lässt.
Bild

Ein anderes Thema sind Ungenauigkeiten im Randbereich der Subgitter bei der Rücktransformation. Diese bestehen in einem Streifen von 120m um das Subgitter. In diesem Bereich kommt es zu leichten Lageabweichnungen bei der Rücktransformation aus ETRS/UTM System (bzw. korrekter Weise aus den Geokoordinaten) in das RD83/GK System. Diese Abweichungen von weniger als 3 cm treten allerdings bei allen von mir getesteten Programmen auf und lassen sich auch nicht durch die im Link beschriebene Kaskade verhindern.

In der angehängten Exceltabelle befindet sich eine entsprechende Kontrollrechnung mit den Schritten:
RD83GK5 --> GeoKoo --> ETRS89UTM33 --> GeoKoo --> RD83GK5
Subgitter.zip
Kontrollrechnung mit den Schritten:
RD83GK5 --> GeoKoo --> ETRS89UTM33 --> GeoKoo --> RD83GK5
(15.1 KiB) 1618-mal heruntergeladen
Gruß Steffen
Gruß Steffen
Dereje

Re: KooTransSN/GeoTKF: Relevanz des PROJ.4-Fehlers #209

Beitrag von Dereje » 4. Mai 2015, 08:53

Vielen Dank, Steffen, für die fundierte und klare Antwort.

Das hilft uns sehr weiter. Vielen Dank nochmal auf diesem Weg für die praktisch zu handhabende Software, die wir hier in der BfUL im Rahmen unserer Arbeit (Betreuung der Umweltmessnetze Sachsen) nutzen werden.

Einen schönen Tag noch!
Dereje
Antworten