• Willkommen im Geoclub - dem größten deutschsprachigen Geocaching-Forum. Registriere dich kostenlos, um alle Inhalte zu sehen und neue Beiträge zu erstellen.

Gesucht: Umrechnung WGS84 nach Lambert (Österreich)

pfeffer

Geowizard
1. EDIT: Proj4 hat 2 Möglichkeiten für den Datums-Übergang
a) mit 3-Parametern: "hermannskogel", "towgs84=653.0,-212.0,449.0", "bessel", "Hermannskogel", (Datei pj_datums.c)

b) mit 7 Parametern: <31287> +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 <>
( http://svn.osgeo.org/metacrs/proj/trunk/proj/nad/epsg )

Zu b): b) sind die gleichen Parameter, die wir auch verwenden und hier ebenso zu finden sind: http://www.bev.gv.at/pls/portal/docs/PAGE/BEV_PORTAL_CONTENT_ALLGEMEIN/0200_PRODUKTE/PDF/KOORD-SYS.PDF .

Überhaupt ist http://svn.osgeo.org/metacrs/proj/trunk/proj/nad/epsg eine tolle Datei. Da kann man für alle EPSG-Codes schnell nachgucken, was es ist und vor allem, wie man es in WGS84 umrechnet.

2. auch bei dem WMS-Server von Niederösterreich http://www.intermap1.noel.gv.at muss ich die Lambert-Projektion mit 47,5° rechnen, um die richtigen Karten zu erhalten. Wenn man die Koordinaten-Umrechungsfunktion auf der Webseite nutzt, dann rechnet der jedoch mit 48°. Langsam tendiere ich zu der These, dass all die Umrechner auf den Seiten der Landesämter (und Transdat) fälschlicherweise mit 48° rechnen (genauso ist es mit http://www.geoland.at ).
Einen Interessanten Hinweis habe ich von Axel2 erhalten: http://www.geoclub.de/viewtopic.php?f=40&t=36673&start=10

EDIT2: Meine Vermutung verstärkt sich, dass die webbasierte-Koordinaten-Umrechnung und Transdat, die mit 48° rechnen, falsch ist. Wenn man nämlich den umrechnungsservice auf geoland.at per .csv-Datei nutzt ( http://www.geoland.at/geolandcoord/eingabe.aspx ), dann erzeugt er die Koordinaten korrekt mit 47,5°. Schon krass: ein- und derselbe Anbieter rechnet mal mit 47,5° und mal mit 48°. Ich glaub, ich ruf da morgen mal an.

Ich habe noch eine tolle Seite entdeckt, die alle EPSG-Codes online umwandeln kann: http://www.synectics-tc.com/resources/downloads/coordinate-reprojection.html
Die rechnet EPSG:31287 korrekt mit 47,5° um. Allerdings habe ich dann noch Abweichungen von 32m (Rechtwert) und 101m (Hochwert) gegenüber meinen Berechnungen. Ich vermute, dass dort der Datumsübergang nur sehr rudimentät (wenn überhaupt) implementiert ist. SChließlich enthält
SRID.csvunter DemoWebApp/App_Data keine Datumsübergangsinformationen für Österreich.

3. weiß ich nichts neues.

Gruß,
Pfeffer.
 

pfeffer

Geowizard
1. Ich habe per Email genauere Transformationsparameter erhalten:
<31287> +proj=lcc +lat_1=49 +lat_2=46 +lat_0=47.5 +lon_0=13.33333333333333 +x_0=400000 +y_0=400000 +ellps=bessel +units=m +no_defs no_defs <>
+towgs84=577.326,90.129,463.919,5.136599,1.4742,5.297044,2.4232

Leider sind das nur zusätzliche Nachkommastellen, die Verschiebung um ca. 20m bleibt gleich. Deswegen stelle ich hier mal meinen Code ein, vielleicht sieht ja jemand den Fehler:
Code:
 	public static final TransformParameters LAMBERT_AUSTRIAN_TO_WGS84 =  new TransformParameters(
 			-577.326, -90.129, -463.919, -5.136599, -1.4742, -5.297044, 2.4232);
	protected void set(double dxi, double dyi, double dzi, double exi, double eyi, double ezi, double si, boolean addinverted) {
		dx = dxi; dy = dyi; dz = dzi; 
		ex = exi * Math.PI/180/3600;
		ey = eyi * Math.PI/180/3600; 
		ez = ezi * Math.PI/180/3600;
		s = 1 - si* Math.pow(10, -6); // 1/(1 - si * Math.pow(10, -6));
		if (addinverted) {
			inverted = new TransformParameters(this, false);
			inverted.invert();
		} else inverted = null;
	}
	private static XyzCoordinates transform(XyzCoordinates from, TransformParameters transParams) {
		Matrix coos = new Matrix(3, 1);
		coos.matrix[0][0] = from.x;
		coos.matrix[1][0] = from.y;
		coos.matrix[2][0] = from.z;

		Matrix shift = new Matrix(3,1);
		shift.matrix[0][0] = transParams.dx;
		shift.matrix[1][0] = transParams.dy;
		shift.matrix[2][0] = transParams.dz;


		Matrix rotate = new Matrix(3,3);
		rotate.matrix[0][0] = 1;						rotate.matrix[0][1] = transParams.ez;			rotate.matrix[0][2] = - transParams.ey;
		rotate.matrix[1][0] = - rotate.matrix[0][1];	rotate.matrix[1][1] = 1;						rotate.matrix[1][2] = transParams.ex;
		rotate.matrix[2][0] = - rotate.matrix[0][2];	rotate.matrix[2][1] = - rotate.matrix[1][2];	rotate.matrix[2][2] = 1;
		 
		rotate.MultiplyByScalar(transParams.s); // scale

		rotate.Multiply(coos);
		coos = rotate;
		coos.add(shift);
		
		return new XyzCoordinates(coos.matrix[0][0], coos.matrix[1][0], coos.matrix[2][0]);
	}
aber vielleicht liegt der Fehler auch in der Umrechnung Lat/Lon -> XYZ und zurück?

2. (47,5° versus 48°) wird nun im Amt in Österreich geprüft.

Gruß,
Pfeffer.
 

pfeffer

Geowizard
1. ok, es waren doch die Vorzeichen. Ich dachte, ich hätte das schon probiert - kam ja mit 20m-Abweichung schon recht nahe. Echt blöd, dass es da keine andere Möglichkeit als ausprobieren gibt. Die Daten auf http://www.crs-geo.eu/nn_124392/crseu/EN/CRS__Description/crs-national__node.html?__nnn=true sind leider nicht konsistent :-( mal muss man das der Verschiebungen ändern, mal das der Rotationen (DHDN-Nord im Vergleich zu Austrian). Damit hatte ich nicht gerechnet.

EDIT: Die Daten sind doch konsistent. Ich hatte in meinem Programm an der falschen Stelle die Vorzeichenumkehrroutine aufgerufen.

Gruß,
Pfeffer.
 

KajakFun

Geowizard
Wer sucht wird fündig.
Die Differenzen beruhen auf unterschiedlichen Vorzeichen in der Matrix für die Helmert Transformation bezüglich der Richtung des Drehwinkels.
Im Wikipedia Artikelüber die Helmert Transformation findet man folgende Matrix:
93468bf861d5e613a3ca3fc4e696aa12.png

Bei der Online Umrechnung bei www.ottmarlablonde.de sind für die Transformation WGS84->Bessel die Koeffizienten für den Drehwinkel in der Matrix mit umgekehrtem Vorzeichen angegeben.
Shift_20018.JPG


Mit der Rotationsmatrix von ottmarlablonde und den WGS84->MGI Parametern
cx=-577.326
cy=-90.129
cz=-463.919
rx=5.137/3600/180*pi
ry=1.474/3600/180*pi
rz=5.297/3600/180*pi
s=-2.423E-6
bekomme ich für die Werte lam=12.69417 phi=47.07472 h=0
Bessel Ellipsoid phi,lam 47.0752078 12.6947942
für die Lambert Projektion die Werte
Rechtswert 351525.086
Hochwert 352993.26
Diese Werte decken sich auch mit der http://vogis.cnv.at online Umrechnung beim Landesamt für Vermessung Vorarlberg.
 

pfeffer

Geowizard
ja, genau, so ist es!

Das bedeutet, dass die XYZ-Angaben und lat/lon im Bessel-Ellipsoid, Hermannskogel hier im Thread auf http://www.geoclub.de/viewtopic.php?f=54&t=23912&start=20 von KajakFun vom 2008-05-18, 01:54 falsch sind. Auch damit hatte ich nicht gerechnet.

Außerdem ist anzumerken:
Du hast von http://vogis.cnv.at/ das Ergebnis der Projektion Lambert_neu wiedergegeben, obwohl eigentlich wir hier Lambert_alt rechnen. Das Ergbnis Lambert_alt auf http://vogis.cnv.at/ ist jedoch falsch (weil sie mit 48° statt mit 47,5° als Ursprungsbreitengrad rechnet) - wie bei allen Landesvermessungsämtern Österreichs, wenn man über den Klick auf x/y-Button in der Karte die Umrechnung startet Z.B. auch hier: http://www.geoland.at/geoland2/(lue...ansfrom=wgs84.pr4&x=12.69417%B0&y=47.07472%B0

geoland.at hat noch einen anderen Umrechnungsservice, der richtig rechnet: http://www.geoland.at/geolandcoord/eingabe.aspx
Code:
Er ergibt für wgs84: E 12.69417° N47.07472°
Lambert_neu: 351519,74	353054,33
Lambert_alt: 351525,08	352993,27
Im Ergbnis stimmt das Ergebnis von der x/y-Karten-Button-Umrechnung für Lambert_neu mit der korrekten Lambert_alt überein (und ist damit nicht Lambert_neu), während Lambert_alt einfach falsch ist.

Meine Behauptung "falsch" und "richtig" beruhen auf den EPSG-Angaben:
Lambert_alt: EPSG:31287
Lambert_neu: EPSG:3416 <--- habe ich nicht selbst nach gerechnet.
Der Unterschied zwischen Lambert_alt und _neu ist, dass sich _alt auf Bessel, Hermannskogel und _neu auf ETRS89 bezieht.

Gruß,
Pfeffer.

EDIT: URL zum x/y-Karten-Button-Umrechner klickbar gemacht.
 

KajakFun

Geowizard
Ja, die Drehung macht die 17 bzw. 20 Meter Differenz aus.
Hier nochmal meine neuen Werte zum Vergleich
WGS84 lat 47.07472 lon 12.69417 h= 0
-----Kartesisch WGS84---------
X 4245242.08
Y 956252.729
z 4647426.01
----Nach der Transformation xyz bez. Bessel Ellipsoid Ursprung-----
X 4244645.81
Y 956167.006
z 4646957.35
---Wnkelgrade im Bessel Ellipsoid--
phi 47.0752078
Lam 12.6947942
Höhe h -47.91061
--Lambert Projektion---
Lambert Parallels 46° 49°
Origin 47°30'' & 13°20''
False East 400000, False North 400000
x 351525.086
y 352993.26

Der Unterschied von Lambert y=352993,21 zu Lambert alt y=297425,04 bei vogis.at macht exakt 0.5 Grad Winkeldifferenz aus.
Die Lambert alt Werte werden dort offensichtlich NACH dem Übergang ins Bessel Ellipsoid mit 48 Grad gerechnet und die Lambert neu Werte mit 47°30'' (EPSG 31287)

Die Frage ist nur ob für die Lambert Projektion (EPSG 3416) kein Übergang ins Bessel Ellipsoid mehr erforderlich ist und die Projektion direkt aus dem WGS84 Ellipsoid mit Ref=47.30'' erfolgt?
Das würde bei mir ergeben x =351471.365 y=352934.172
 

pfeffer

Geowizard
KajakFun schrieb:
Der Unterschied von Lambert y=352993,21 zu Lambert alt y=297425,04 bei vogis.at macht exakt 0.5 Grad Winkeldifferenz aus.
Die Lambert alt Werte werden dort offensichtlich NACH dem Übergang ins Bessel Ellipsoid mit 48 Grad gerechnet und die Lambert neu Werte mit 47°30'' (EPSG 31287)
ja, genau. Hier ( http://www.geoland.at/geolandcoord/eingabe.aspx ) steht die Zuordnung von Lambert_alt zu EPSG 31287 und Lambert_neu zu EPSG 3416.

KajakFun schrieb:
Die Frage ist nur ob für die Lambert Projektion (EPSG 3416) kein Übergang ins Bessel Ellipsoid mehr erforderlich ist und die Projektion direkt aus dem WGS84 Ellipsoid mit Ref=47.30'' erfolgt?
Das würde bei mir ergeben x =351471.365 y=352934.172
So verstehe ich EPSG:3416. Allerdings stimmen Deine Werte nicht mit der .csv-Variante von geoland.at für EPSG3416 überein ( http://www.geoland.at/geolandcoord/eingabe.aspx ), von der ich bisher davon ausging, dass sie richtig rechnet.

Gruß,
Pfeffer.
 

KajakFun

Geowizard
So verstehe ich EPSG:3416. Allerdings stimmen Deine Werte nicht mit der .csv-Variante von geoland.at für EPSG3416 überein ( http://www.geoland.at/geolandcoord/eingabe.aspx ), von der ich bisher davon ausging, dass sie richtig rechnet.
Ist mir auch schon aufgefallen aber sie stimmen überein mit den Werten von Transdat mit Zielbezugssystem WGS84.
 

pfeffer

Geowizard
Ich komme auch auf Deine Werte für Lambert_neu. Also auch ein Fehler in der csv-Umrechnungsvariante?
Der Mensch von dem österreichischen Landesvermessungsamt, mit dem ich gesprochen habe, hat gesagt, sie würden Proj4 verwenden.
Deswegen habe ich grade mal bei Proj.4 geguckt ( http://svn.osgeo.org/metacrs/proj/trunk/proj/nad/epsg ):
Code:
# ETRS89 / Austria Lambert
<3416> +proj=lcc +lat_1=49 +lat_2=46 +lat_0=47.5 +lon_0=13.33333333333333 +x_0=400000 +y_0=400000 +ellps=GRS80 +units=m +no_defs  <>
sieht mir eigentlich korrekt aus.
Sehr seltsam.

Gruß,
Pfeffer.
 

pfeffer

Geowizard
Der freundliche Mensch vom Landesvermessungsamt hat nun für mehr Klarheit gesorgt:

1. geoland.at hat den Umrechner wegen meiner Fragen aktualisiert. Der Grund für die Verwirrung war: Es gibt 3 Lambert-Systeme in Österreich:
1. "Lambert neu" (EPSG:3416) basiert auf ETRS89.
2. "Lambert alt" (EPSG:31287) basiert auf BESSEL, Hermannskogel mit zentralem Breitengrad 47,5°
3. "Lambert ganz alt" (hat keinen EPSG-Code, evtl. mal 31297 gewesen?): identisch mit "Lambert alt", allerdings mit 48° als zentralem Breitengrad.

Offensichtlich lieferte bis heute vormittag die X/Y-Klick-Variante "Lambert ganz alt", das hat der freundliche Mensch vom Landesvermessungsamt nun auf "Lambert alt" geändert.

Und was für mich für den Kartenabruf in Cachewolf wichtig ist: Auf geoland.at sind die Karten im Original in "Lambert alt".

Gruß,
Pfeffer.

EDIT: Ich hab noch gegoogelt: Die Verwirrung um die 48° versus 47,5° ist wohl vor 10 Jahren eigentlich abgestellt worden: EPSG:31297 ( http://spatialreference.org/ref/epsg/31297/ ) enthält genau die gleiche Spezifikation wie EPSG:31287 mit 47,5° - sollte aber wohl eigentlich 48° enthalten (meine Spekulation). Ich spekuliere weiter: weil die EPSG:31297 nun einmal in der Welt war und möglicherweise bereits irgendwo so implementiert war, dass sie funktionierte (d.h. entgegen der Spezifikation mit 48°) hat man lieber auf einen neuen EPSG-Code (EPSG:31287) mit den gleichen Spezifikationen umgestellt.

EDIT2: ää - nein, das ist es nicht. in EPSG:31297 waren Nord- und Ostwert vertauscht. Sehr komisch. http://spatialreference.org/ref/epsg/31287/html/ gegen http://spatialreference.org/ref/epsg/31297/html/
 

Wallraff

Geocacher
Du Glücklicher !
Du Charmebolzen ?


Meine Email-Anfrage wurde vor einem Jahr wie folgt beantwortet
(wundersamerweise habe ich sie wiedergefunden?)

>Sehr geehrter Herr ...,
>> der Unterschied liegt darin, dass in Geoland die Lambert-Projektion sich
>> auf das Referenzsystem MGI/Bessel (national) bezieht.
>> Das zweite angeführte Koordinatenpaar (in Lambert) bezieht sich auf
>> WGS84/GRS80 (international).
>>
>> Mit freundlichen Grüßen
>>Fr. Ing. ...
Danach hatte ich mich ganz entspannt dem Streicheln der Katze zugewandt ...

Grüße Wallraff
 

KajakFun

Geowizard
Code:
Er ergibt für wgs84: E 12.69417° N47.07472°
Lambert_neu: 351519,74   353054,33
Lambert_alt: 351525,08   352993,27
Offensichtlich haben sie nun auch die Umrechnungsvorschrift in Lambert "ganz neu" (WGS84 System ) geändert. :D
Code:
Lambert ETRS89 (EPSG 3416)	351471	352934
 

pfeffer

Geowizard
ja, die Lambert_neu (Lambert_ETRS89) beim X/Y-Button-umrechner arbeitet jetzt auch korrekt.

Und seit heute Mittag auch die Umrechnung per csv auf Lambert_ETRS89:
auch die Umrechnung per csv liefert jetzt die korrekten Lambert_ETRS89 (=Lambert_neu) Werte :) Die Du ausgerechnet hast.

Beste Grüße,
Pfeffer.
 

KajakFun

Geowizard
Echt streng die ganze Hin- und Her Rechnerei.
Wie sollen da Aussenstehende durchsteigen wenn selbst die Vermessungsämter keine verlässlichen Daten mehr abliefern an denen man sich im Zweifelsfall orientieren könnte. :kopfwand:
Immerhin sind jetzt wenigstens einige der Ungereimtheiten beseitigt. :gott:
 

pfeffer

Geowizard
ja, bei geoland.at wird jetzt richtig umgerechnet. Aber bei den (anderen) Landesvermessungsämtern immernoch falsch, z.B. bei http://vogis.cnv.at/dva04/(S(rp4cgxfbwop0nz45mlmma3a4))/init.aspx Aber irgendwie sehe ich nicht meine Aufgabe darin, nun alle östereichischen Landesvermessungsämter anzuschreiben. Vielleicht macht es ja mal jemand anders.

Gruß,
Pfeffer.
 

chri86kbg

Geonewbie
Hallo, nach langem suchen im Internet bin ich auf eure Seite gestoßen!

Ich habe leider ein sehr großes Problem. Gleich mal vorweg, ich kenne mich nicht so gut aus mit Koordinaten umrechnen aus.

Mein Plan => Anhand einer google Maps Karte die Posdaten auslesen und diese dann in Lambert Wert(Österreich) umzurechnen...

Das auslesen selbst funktioniert sehr gut. Habe dies mit JQUERY realisiert.

Nur bei der Umwandlung scheitere ich komplett, ich hab eine PHP Klasse gefunden jedoch fehlen mir die "richtigen Daten"...

http://www.phpclasses.org/browse/file/14315.html

Ich habe zb. Daten vom Hauptplatz meines Ortes
(Korneuburg - Österreich)
LAMBERT => Hauptplatz 622386,59056 442553,2847
WGS84 => 48.344684,16.333451

INFO::
Code:
$myLocation->configLambertProjection ($falseEasting, $falseNorthing, $longOfOrigin, $latOfOrigin, $firstStdParallel, $secondStdParallel);

This function sets up a number of important parameters needed to define and calculate a particular Lambert Projection. $falseEasting & $falseNorthing are just an offset in meters added to the final coordinate calculated. $longOfOrigin & $LatOfOrigin are the "center" latitude and longitude of the area being projected. All coordinates will be calculated in meters relative to this point on the earth. $firstStdParallel & $secondStdParallel are the two lines of longitude (that is they run east-west) that define where the "cone" intersects the earth. Simply put they should bracket the area being projected.

SCRIPT::
Code:
$myLocation->configLambertProjection('40000', '40000', '16.333451', '48.344684', 33.33333, 38.6666);

Danke für eure Hilfe!! Ich stehe echt an!

Aja genau, dies sollte ein Hydrantenplan für meine Freiwillige Feuerwehr werden!

lg Christopher - Korneuburg / Austria
 

KajakFun

Geowizard
Ich vermute die Eingabewerte für das Skript stimmen nicht.
Für die false Easting und Northingwerte 400.000 statt 40000
dito die Werte für den Referenzmeridian und den 1. u. 2. Breitenkreis.
false Easting 400000
false Northing 400000
Ref. Meridian 13°,20' Grad, 47°,30' ->in Dezimal umrechnen...
1. und 2. Breitenkreis 49° und 46°
 

pfeffer

Geowizard
Hallo!

1. In welches der 3 in Österreich verwendeten Lambert-Projektionen möchtest Du umrechnen? (siehe http://forum.geoclub.de/viewtopic.php?f=54&t=23912&start=50#p584674 )

2. Wie genau soll die Umrechnung sein? Hintergrund der Frage: die Lage und Größe der "Erdkugel" (Ellipsoid), die den österreichischen Lambert-Koordinaten zugrunde liegen, sind anders als die im WGS84-System. Wenn man genauer als auf wenige 100 Meter umrechnen will, dann muss man eine Transformation der unterschiedlichen Ellipsoide vornehmen. Auf den ersten Blick scheint mir dies die Funktion nicht zu bieten.

Viele Grüße,
Pfeffer.
 
Oben