DE talk:JOSM/Plugins/epsg31287

Details / Diskussion zu den bekannten Fehler im EPSG:31287 Plugin

• Bei mir klappt der Upload von durchgeführten Änderungen mit geladenen WMS-Hintergrund nicht. JOSM (Vers. 3592) frisst dabei zuerst eine geraume Zeit (30sec - 60sec) nur CPU-Zeit, dann kommt die Fehlermeldung, dass JOSM der Speicher ausgegangen sei. Der für mich funktionierende Workaround besteht darin die Datenebene lokal abzuspeichern, mit einen anderen neu gestarteten JOSM ohne geladenes Geoland-Plugin bzw. WMS die lokalen Daten laden und updaten. Der Fehler tritt nicht unmittelbar nach aktivieren des Geoland-WMS auf, aber wann man ein bisserl etwas editiert und auch neue Bereiche im WMS nachgeladen werden, dann tritt der Fehler bei mir schnell auf. -- Hetzi
  • weiterer Workaround: vor dem Upload den WMS Layer rausnehmen und die Projektion wieder auf Mercator zurückstellen.
  • Update 18.10.2010: das plugin stellt jetzt vor dem Upload automatisch auf Mercator (bzw. auf zuvor aktive Projektion) um. -- Fichtennadel
    • Ja, das funktioniert nun problemlos, Danke -- Hetzi

• Ich hab mir heute mal die Muehe gemacht den Fehler in der Umrechnung vom epsg31287 plugin nachzuvollziehen. Gemacht habe ich das indem ich die Koordinaten eines exemplarischen Punktes in WGS84 aus JOSM genommen habe und den mithilfe des Umrechnungstool von geoimage.at (http://www.geoland.at/geolandcoord/eingabe.aspx) transformiert habe und mit dem Ergebnis der JOSM-plugin Umrechnung verglichen habe. Herausgekommen ist dabei fuer einen Punkt in Linz 14,2833092 ; 48,3098392 (das ist der POI des Buergerservices Linz eine Abweichung von 17,11 Meter in X Richtung und -20,63m in Y Richtung, daher in Summe 26,8m. Diese Abweichung ist aber eben leider nicht konstant. Bei einen anderen Punkt ca. 31km Luftlinie NW von Linz war der Fehler 30,3m. Was ich damit zumindest habe machen koennen ist mir ein eigenes privates epsg31287 plugin zu erstellen, wo der damit ermittelte genaue lokale offset enkompiliert ist. Das geht indem man in der ProjectionEPSG31287.java Datei ab Zeile 39 die +x_0=400000 bzw +y_0=400000 mit dem ermittelten Offset anpasst. Meine Versuche den Rechenfehler irgendwie selber nachzuvollziehen sind leider an meinen mangelnden JAVA-Kenntnissen kombiniert mit nur oberflaechlichen Verstaendnis der genauen Koordinatenumrechnung leider klaeglich zum Scheitern verurteilt gewesen. Achja, bei meinen Umrechnungsversuchen bin ich noch auf ein zweites Umrechnungstool (http://www.synectics-tc.com/resources/downloads/coordinate-reprojection.html) gestossen, aber Achtung das Teil rechnet bei EPSG:31287 selber um ca. 100m falsch!!! -- Hetzi
  • Kleines update, die Unstimmigkeiten in der Berechnung der Transformation sind schon in proj selber drinnen und nicht erst im plugin entstanden. Daher epsg31287 plugin und proj als commandline tool rechnen gleich, geoland.at bzw. deren WMS-Server rechnen anders. -- Hetzi
  • Lösung! Mithilfe der proj-Mailingliste habe ich herausgefunden worin das Problem des Offsets liegt. Die Umrechnung die das Plugin macht entspricht bei direkten Aufruf von proj.

proj +proj=lcc +lat_1=49 +lat_2=46 +lat_0=47.5 +lon_0=13.33333333333333 +x_0=400000 +y_0=400000 +ellps=bessel +towgs84=577.326,90.129,463.919,5.137,1.474,5.297,2.4232 +units=m +no_defs

Der Aufruf für die korrekte Umrechnung der Koordinaten ist:

cs2cs +init=epsg:4326 +to +proj=lcc +lat_1=49 +lat_2=46 +lat_0=47.5 +lon_0=13.33333333333333 +x_0=400000 +y_0=400000 +ellps=bessel +towgs84=577.326,90.129,463.919,5.137,1.474,5.297,2.4232 +units=m +no_defs

Nur wie man diese Änderung im plugin-sourcecode umsetzen kann, weiß ich bisher nicht. Ich hoffe aber, dass es für Fichtennadel ein leichtes sein könnte! -- Hetzi

• Nochmals Update mit vermutlich einer schlechten Nachricht. Soweit ich es überblicke macht cs2cs im Gegensatz zu proj auch eine geodätische Datumskonversion (was auch immer das ganz exakt ist) und proj nicht. Bei jhlabs, das ja eigentlich im plugin verwendet wird steht aber leider "Coordinate system and geodetic datum conversion is missing." Da scheint es mir nun essig zu sein mit jhlabs für diesen Zweck im JOSM plugin. -- Hetzi
  • Danke für die Analyse. Ich hab mich auch schon etwas weiter mit jhlabs herumgespielt, leider implementiert es nur eine Teilmenge von proj4. Es gibt zwar ein Nachfolgeprojekt von jhlabs, das ist aber noch in einem sehr frühen Stadium, da konnte ich nicht mal die Sourcen aus Sourceforge sauber kompilieren. -- Fichtennadel 07:35, 29 October 2010 (BST)

Wäre es nicht eigentlich auch möglich nicht die teilimplementierte version von proj4 in jhlibs zu verwenden, sondern den cs2cs-Befehl direkt zu verwenden. Einfach so als externes Programm aus aufgerufen? Man bräuchte eigentlich nur den cs2cs Befehl 2x aufzurufen, einmal für die Umrechnung in die eine Richtung, und ein zweites mal fürs zurückrechnen? Und dann eben alle Koordinaten die umgerechnet werden sollen dem jeweils passenden cs2cs Befehl vorwerfen. Das wäre zwar vermutlich nicht so gut für ein offizielles JOSM-Plugin, da ja proj4 zusätzlich extern installiert sein muss, aber damit sollte eigentlich für interessierte eine JOSM-Bastellösung hinzubekommen sein.

Habe ich probiert, leider schaffe ich es nicht, cs2cs in Java als Filter zu verwenden, d.h. ich muss für jede Umrechnung cs2cs erneut aufrufen. Das funktioniert zwar an sich und die Lagegenauigkeit ist mehr oder weniger perfekt, allerdings wird dann JOSM durch die dauernden cs2cs Aufrufe im Hintergrund so langsam, dass es keinen Spaß mehr macht. Ich fürchte, das macht so keinen Sinn. Andere Variante wäre JNI und die dll einbinden, allerdings ist dann mit Plattformunabhängigkeit Essig. Fichtennadel 22:21, 1 November 2010 (UTC)

Ich hab mitlerweile auch versucht die Formeln für die fehlende Umrechnerei selber testweise in Excel zusammenzubasteln. Das ist in Summe echt eine müsame Sache und irgendwo ist in dem Formelwulst bei mir immer noch ein Wurm drin und es kommt noch nicht das raus was rauskommen sollte. Dabei ist die eigentliche Transformation (Helmert-Transformation) selber noch recht einfach und überschaubar, aber davor muss alles erstmal in kartesische Koordinaten umgerechnet werden. Dann die Transformation, und dann mit recht länglichen Formeln wieder retour. (Nachzulesen bei http://www.epsg.org/guides/docs/G7-2.pdf Abschnitt 2.2.1) --Hetzi 22:37, 31 October 2010 (UTC)

Wenn Du das xls fertig hast, lasst es mich wissen, dann versuche ich es im plugin nachzuprogrammieren. Fichtennadel 22:21, 1 November 2010 (UTC)

Irgendwie erscheint mir das Ergebnis meiner Berechnungen immer noch nicht so ganz. Die von der Transformation erzeugten Offsets scheinen mir einfach sehr groß. Die Teile der Umrechnung der WGS84 in Kartesischen Koordinaten und retour sollten eigentlich passen. Zumindest landet man bei Rücktransformation der Unveränderten Werte wieder am Ausgangspunkt. Mein OpenOffice Calc Dokument ist unter http://140.78.94.22/~hetzi/Helmert-Trans.ods abgelegt. --Hetzi 09:01, 3 November 2010 (UTC)

Jetzt mal wirklich gute Nachrichten :-) Bei den Leuten von der proj4 Mailingliste sind die echten Genies mit der Umrechnerei daheim. Mikael Rittri hat da eine andere Methode der Projektion umgesetzt. Indem statt der echten Datumsprojektion diese gleich in die proj-Prarameter direkt miteingerechnet werden. Resultat ist die proj Befehl:

proj +datum=WGS84 +proj=lcc +lat_1=46.0103424 +lat_2=48.988621 +lat_0=47.5 +lon_0=13.33616275 +x_0=400268.785
+y_0=400057.553

Der liefert annähernd gleiche Resultate wie der eigentlich "richtige" cs2cs Befehl von oben.

Jetzt hab ich die Parameter in die pluginsources ergänzt und leider festgestellt, dass damit noch ein ca. 100m konstanter Offset in JOSM erzeugt wird ... keine Ahnung warum eigentlich. Experimentell mit OSM-Datenvergleich hab ich damit aber diesen Offset noch korrigiert und Resultat bei den Parametern im ProjectionEPSG31287.java File ab Zeile 34:

                        "+datum=WGS84"
                        ,"+proj=lcc"
                        ,"+lat_1=46.0103424"
                        ,"+lat_2=48.988621"
                        ,"+lat_0=47.5"
                        ,"+lon_0=13.33616275"
                        ,"+x_0=400183.985"
                        ,"+y_0=400010.553"
                        ,"+units=m"
                        ,"+no_defs"

Damit stimmt der WMS-Server bei mir recht gut mit den OSM-Daten in JOSM überein. Eventuell sollte man noch versuchen irgendwas diesen letzten Offset genauer auf den Grund zu gehen! --Hetzi 13:22, 3 November 2010 (UTC)

Wer das modifizierte Plugin direkt ausprobieren will, ohne selber das plugin aus den Sourcecode zu erzeugen, kann es gerne unter http://140.78.94.22/~hetzi/epsg31287.jar runterladen und ins lokalen Pluginverzeichnis hinterlegen, bzw. das offizielle epsg31287.jar ersetzen. Soweit ich es bisher quer über Österreich ausprobiert habe, sind GPS-Tracks bzw OSM Daten weitgehend deckungsgleich mit den WMS-Bildern --Hetzi 14:17, 3 November 2010 (UTC)

neue Version (24044) verfügbar, Update über die JOSM Einstellungen -- Fichtennadel 18:09, 3 November 2010 (UTC)