Re: [Talk-de] Gauß-Krüger WGS-84 [OffTopic]
On Thu, 19 Mar 2009 10:02:55 + (UTC), Sven Geggus li...@fuchsschwanzdomain.de wrote: Gerrit Lammert o...@00l.de wrote: Ich möchte die Transformation von WGS84 in GK in SQL nachbilden. Weshalb Dinge erfinden, die es schon gibt? Die Postgis Erweiterung der PostgreSQL Datenbank hat selbiges als Teil der Simple Features for SQL bereits eingebaut. Weil ich (wie bereits geschrieben) nicht PostgreSQL sondern MS SQL verwenden muss. Wenn ich frage wie ich etwas in inkscape hinbekomme, brauch ich auch keine Tipps bezüglich Auto-CAD. ;-) Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gauß-Krüger WGS-84 [OffTopic]
Gerrit Lammert o...@00l.de wrote: Ich möchte die Transformation von WGS84 in GK in SQL nachbilden. Weshalb Dinge erfinden, die es schon gibt? Die Postgis Erweiterung der PostgreSQL Datenbank hat selbiges als Teil der Simple Features for SQL bereits eingebaut. Gruss Sven -- If you don't make lower-resolution mapping data publicly available, there will be people with their cars and GPS devices, driving around with their laptops (Tim Berners-Lee) /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gauß-Krüger WGS-84 [OffTopic]
Gerrit Lammert o...@00l.de wrote: Weil ich (wie bereits geschrieben) nicht PostgreSQL sondern MS SQL verwenden muss. ich habe nochmal nachgelesen, in d177bcb986aad0b2858f779be1f7d...@imap.00l.de hattest Du das noch nicht geschrieben sondern erst in 2546fa35dc8ad73a9e33e5535f99f...@imap.00l.de. Ich habe aber auf die erste Email geantwortet. Ich pflege threads von oben nach unten zu lesen. Wenn ich frage wie ich etwas in inkscape hinbekomme, brauch ich auch keine Tipps bezüglich Auto-CAD. ;-) Das war lediglich ein hinweis meienrseits auf das richtige Tool für diesen Zweck und das ist in diesem Fall nun mal eine Datenbank mit Simple Features for SQL Implementierung. Unabhängig davon möchte ich Dich auf die Existenz der Proj4 Bibliothek hinweisen. Sowas muss man doch nicht von Hand machen. Beispiel für die Kommandozeile (Gauß-Krüger (GK2) nach WGS 84): echo 2611045.99 5726063.67 | cs2cs -f %.6f +init=epsg:31466 +to +init=epsg:4326 proj4 ist aber Prinzipiell eine C-Bibliothek, die man auch in eignener Software verwenden kann. Postgis macht das zum Beispiel damit. Sven -- /* Fuck me gently with a chainsaw... */ (David S. Miller in /usr/src/linux/arch/sparc/kernel/ptrace.c) /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gauß-Krüger WGS-84 [OffTopic]
Hi Sven. Sven Geggus wrote: Gerrit Lammert o...@00l.de wrote: Weil ich (wie bereits geschrieben) nicht PostgreSQL sondern MS SQL verwenden muss. ich habe nochmal nachgelesen, in d177bcb986aad0b2858f779be1f7d...@imap.00l.de hattest Du das noch nicht geschrieben sondern erst in 2546fa35dc8ad73a9e33e5535f99f...@imap.00l.de. Ich habe aber auf die erste Email geantwortet. Ich pflege threads von oben nach unten zu lesen. Puh! Nein, ich habe nicht geschrieben, dass es auf dem MS SQL Server stattfinden soll. Ich habe jedoch geschrieben, dass die Transformation in _SQL_, und nicht in einer Bibliothek, einer speziellen Erweiterung, die das magisch macht, oder auf irgendeine andere Art, gemacht werden soll. Weitere Beispiele: Wenn ich frage, mit welcher Buslinie ich von a nach b komme, ist es zwar nett gemeint, wenn man mir erzählt welches Auto das beste Navi hat oder das Taxifahrer bestimmt schneller sind oder das richtige Männer zu Fuß gehen oder sowas. Aber es mag Gründe dafür geben, dass ich explizit nach einer Busverbindung frage... Es ist nett gemeint von Dir, mich darauf hinzuweisen das fertige, gut gepflegte Tools vermutlich genauer, flexibler und besser sind, aber dies war als kurze, wenn-wir-gerade-dabei-sind Frage, gedacht, mit der ich gerade NICHT den Thread übernehmen wollte. Also: Das Problem ist zu meiner Zufriedenheit gelöst. Wenn weiter jemand über proj4 oder ähnliches reden möchte, gerne. Aber ich klinke mich dann mal wieder aus... Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gauß-Krüger WGS-84
Thomas Reincke schrieb: Stefan Dettenhofer (StefanDausR) schrieb: Thomas Reincke schrieb: Die Ergebnisse lagen ~300m daneben. Da fehlte bestimmt der Ellipsoidübergang. Könnte sein, das war auch mein erster Verdacht. http://www.delphi-treff.de/tipps/mathematik/wiki/Geographische%20in%20Gau%C3%9F-Kr%C3%BCger-Koordinaten%20umrechnen/ Aha - den Code hatte ich auch mal vor längerer Zeit in mein Programm eingebaut, bis mir das mit dem Ellipsoidübergang aufgefallen ist. Die Formal von Grossmann liefert in erster Näherung eine Umrechnung in das Deutsche Hauptdreiecksnetz (EPSG: 4314) Die GK-Koordinaten benutzen genauso wie geogr. Koordinaten im DHDN das Ellipsoid WGS72 (Bessel 1841). Du willst aber WGS-84, daher benötigst Du noch den Übergang von Bessel auf WGS84. Ich benutze z.Zt. den Sourcecode von Geotrans. Der ist zwar nicht ganz so genau wie NTv2, aber die Abweichung liegt unter einem Meter (und hier kommen wir ja schon wieder in den Bereich der Plattentektonik und somit zu dem Problem WGS-84 - ETRS89 (GRS80). Noch eine Anmerkung am Rande: Wenn Du vom LVA geographische Koordinaten bekommst, dann kann es durchaus sein, dass die im DHDN (EPSG: 4314) vorliegen. Mir ist das so passiert und daher ist mir damals das Problem mit der Formel von Grossmann erst mal gar nicht aufgefallen. Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gauß-Krüger WGS-84 [OffTopic]
Ist jetzt nicht mehr OSM-bezogen, aber soviele kundige Mitleser muss ich einfach ausnutzen. ;-) http://www.delphi-treff.de/tipps/mathematik/wiki/Geographische%20in%20Gau%C3%9F-Kr%C3%BCger-Koordinaten%20umrechnen/ Aha - den Code hatte ich auch mal vor längerer Zeit in mein Programm eingebaut, bis mir das mit dem Ellipsoidübergang aufgefallen ist. Die Formal von Grossmann liefert in erster Näherung eine Umrechnung in das Deutsche Hauptdreiecksnetz (EPSG: 4314) Die GK-Koordinaten benutzen genauso wie geogr. Koordinaten im DHDN das Ellipsoid WGS72 (Bessel 1841). Du willst aber WGS-84, daher benötigst Du noch den Übergang von Bessel auf WGS84. Ich benutze z.Zt. den Sourcecode von Geotrans. Der ist zwar nicht ganz so genau wie NTv2, aber die Abweichung liegt unter einem Meter (und hier kommen wir ja schon wieder in den Bereich der Plattentektonik und somit zu dem Problem WGS-84 - ETRS89 (GRS80). Ich möchte die Transformation von WGS84 in GK in SQL nachbilden. Ich habe eine gut funktionierende Transformation in c#, aber diese besteht aus vielen Objekten und Unterfunktionen, das ist nur sehr umständlich in SQL zu implementieren. Der Delphi-Code hinter obigem Link ist da deutlich angenehmer. Hab es nun auch schnell hinbekommen, aber natürlich die bereits angesprochene Abweichung von ein paar hundert Metern. Nachdem ich nun den ganzen Vormittag nach einer Möglichkeit gesucht habe, die Ellipsoidtransformation durchzuführen gebe ich auf und bitte Euch um Hilfe. Also, wie bekomme ich den obigen code dazu das gleiche Ergebnis zu liefern wie https://upd.geodatenzentrum.de/auftrupd/ktrans?sprache=deu bei Geo84 - GK3. Ich habe bereits versucht die Werte für e2 und c auf den WGS-ellipsoiden anzupassen, aber das hat nicht geholfen (was ist c überhaupt)? Wäre toll, wenn ihr mir helfen könntet. Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gauß-Krüger WGS-84 [OffTopic]
Hallo Gerrit, Ich möchte die Transformation von WGS84 in GK in SQL nachbilden. Ich fände schön, wenn wir für OSM eine Funktion hätten, mit der wir Koordinaten und Höhen aus jedem System in jedes andere umformen könnten. a) zum Einbauen in beliebige Programme b) als Web-Interface Tobias ist da auch grad dran, die Ergebnisse finde man hier: http://wiki.openstreetmap.org/wiki/de:Altitude Mit herzlichem Gruss, Markus PS: kannst Du diese Tabelle vervollständigen? http://wiki.openstreetmap.org/wiki/de:Altitude#Bezugsystem ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gauß-Krüger WGS-84 [OffTopic]
Hallo Gerrit, Gerrit Lammert schrieb: Ist jetzt nicht mehr OSM-bezogen, aber soviele kundige Mitleser muss ich einfach ausnutzen. ;-) http://www.delphi-treff.de/tipps/mathematik/wiki/Geographische%20in%20Gau%C3%9F-Kr%C3%BCger-Koordinaten%20umrechnen/ (...) Also, wie bekomme ich den obigen code dazu das gleiche Ergebnis zu liefern wie https://upd.geodatenzentrum.de/auftrupd/ktrans?sprache=deu bei Geo84 - GK3. Ich habe bereits versucht die Werte für e2 und c auf den WGS-ellipsoiden anzupassen, aber das hat nicht geholfen (was ist c überhaupt)? Das geht gar nicht, da der o.g. Code keine Ellipsoid-Transformation macht! Diese kann man z.B. mit einer Helmert-Transformatiion erledigen. Du musst dazu einen ganz anderen Code nutzen: z.B. Geotrans oder Proj4 Wenn Du das in SQL lösen willst, dann kannst Du auch gleich eine entsprechende Datenbank nehmen, die die Koordinatentransformationen schon eingebaut hat: Oracle (spatial) kann das und die PostGIS-Erweiterung zu PostgreSQL sicherlich auch. Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gauß-Krüger WGS-84 [OffTopic]
uff - falscher Link. Richtig ist: Tobias ist da auch grad dran, die Ergebnisse finde man hier: http://wiki.openstreetmap.org/wiki/de:Gauß-Krüger Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gauß-Krüger WGS-84 [OffTopic]
Hi Stefan. On Wed, 18 Mar 2009 16:14:34 +0100, Stefan Dettenhofer (StefanDausR) Das geht gar nicht, da der o.g. Code keine Ellipsoid-Transformation macht! Diese kann man z.B. mit einer Helmert-Transformatiion erledigen. Du musst dazu einen ganz anderen Code nutzen: z.B. Geotrans oder Proj4 Jo, hatte inzwischen auch aufgegeben und den gut funktionierenden C#-Code transformiert. Ist zwar eine ziemliche Arbeit (Objektorientiert in SQL erzeugt Unmengen von DECLARE-Anweisungen und meine linke Hand ist ganz ausgeleiert vom @-Zeochen hinzufügen), aber funktioniert jetzt wie es soll. Wenn Du das in SQL lösen willst, dann kannst Du auch gleich eine entsprechende Datenbank nehmen, die die Koordinatentransformationen schon eingebaut hat: Oracle (spatial) kann das und die PostGIS-Erweiterung zu PostgreSQL sicherlich auch. Schön wärs. Die Koordinatentransformation ist nur eine ganz kleine Anwendung. Das ganze läuft auf MSSQL, also keine Geofunktionen (sofern ich weiß). Danke für Eure Hilfe. Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gauß-Krüger WGS-84
Thomas Reincke schrieb: Die Ergebnisse lagen ~300m daneben. Da fehlte bestimmt der Ellipsoidübergang. Es kommt immer darauf an, welche Genauigkeit du brauchst und wie viel Arbeit/Rechenleistung/... Du investieren willst oder kannst. Für Koordinaten, die von einem einfachen GPS-Gerät stammen (absolute Lagegenauigkeit ~ 15m) muss es m.E. nicht unbedingt NTv2 sein, schadet aber auch nichts. Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gauß-Krüger WGS-84
Stefan Dettenhofer (StefanDausR) schrieb: Thomas Reincke schrieb: Die Ergebnisse lagen ~300m daneben. Da fehlte bestimmt der Ellipsoidübergang. Könnte sein, das war auch mein erster Verdacht. http://www.delphi-treff.de/tipps/mathematik/wiki/Geographische%20in%20Gau%C3%9F-Kr%C3%BCger-Koordinaten%20umrechnen/ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gauß-Krüger WGS-84
Hallo Miriam, das gleiche Ergebnis Ja, das hat mich auch irritiert. Damit ich eine Vorstellung der Differenzen bekomme, habe ich eine Tabelle gemacht, wieviel Nachkommastellen wie genau sind: http://wiki.openstreetmap.org/wiki/DE:Genauigkeit_von_Koordinaten (kann das bitte mal jemand prüfe?) Bei Deinen Beispielen beträgt die max. Abweichung Breite: 3,12m Länge: 4,35m*cos(Breite)=2,8m (wenn ich richtig gerechnet habe) Es würde also bei der dezimalen Koordinaten-Darstellung reichen, wenn man 5 Nachkommastellen angibt (der Rest gaukelt eine nicht vorhandene Genauigkeit vor). Und das gilt natürlich auch nur, wenn die ursprünglichen Messergebnisse vor der Umwandlung so genau waren. (in diesem Falle hat man mir 1 dm genannt) Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gauß-Krüger WGS-84
Ich denke, das Problem ist weniger die Rechenungenauigkeit, als die Verwendung verschiedener Algorithmen und unterschiedlicher Parametersätze. Einen schlechten Code erkennt man schon mal daran, dass die Rück-Umrechnung (GK-WGS84-GK) ungenaue Ergebnisse liefert. Hierbei solle es aber nur Abweichungen im cm-Bereich geben. Die verschiedenen Umrechnungsmethoden liefern aber m.W. lokal betrachtet einen absoluten Fehler im bereich von 1-3m. Der differentielle Fehler dürfte geringer sein Die Vermesser nutzen ja immer Referenzpunkte, auf die sie ihre Messung beziehen können. Die gemessenen Werte werden dann später erst in das vorhandene Punktraster eingerechnet und ausgeglichen. Miriam Tolke schrieb: Wolfgang W. Wasserburger [EMAIL PROTECTED] schrieb am Mi, 10.12.2008: Die Umrechnung beinhaltet jede Menge Funktionen (Winkelfunktionen und Wurzeln), die in Computern nicht exakt abgebildet werden und in verschiedenen Programmiersprachen unterschiedlich genau sind. Außerdem sind Iterationen drinnen. Je nach Abbruchbedingung gibt es so auch noch Abweichungen. Also ist nicht nur die Programmierung, sondern auch die Kodierung ein möglicher Grund für Fehler. Es ist sicher ein Unterschied die Konvertierung mal kurz in PHP oder Perl hinzurotzen oder guten Mathe-Libs sorgfältig in Java, C oder Fortran zu verwenden. Trotzdem, sollten nicht zumindest die vom Geodatenzentrum und vom USGS viel Sorgfalt verwendet haben und zumindest auf sechs Stellen deckungsgleich sein? Heutzutage wird doch auch mit GPS vermessen und durch Postprocessing Genauigkeiten im Millimeterbereich generiert. Und dann kommt es bei der Umrechnung zwischen den Systemen zu Ungenauigkeiten im Bereich von drei Metern (wenn ich mich nicht verrechnet habe)? Wie kommen die Vermessungsämter eigentlich auf ihre GK-Koordinaten? Passiert das schon im Empfänger? Ciao, Miriam ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gauß-Krüger WGS-84
Hallo Markus, ich hatte mal für Regensburg folgende Werte bestimmt: Im Rechtswert (GK) entsprechen 10 Meter 0,49'' (WGS-84) Im Hochwert (GK) entsprechen 10 Meter 0,33'' (WGS-84) Noch war zur Koordinatenverwirrung, da ich gerade mal wieder die DatRi-GRUBIS vor mir liegen habe, die den Datenaustausch der Vermessungsämter regelt: Feld 8: Rechtswert oder y-Wert Der jeweilige Rechtswert oder y-Wert wird in der Maßeinheit Zentimeter dargestellt. Bei GK-Koordinaten erfolgt keine Angabe der Meridiankennziffer. Führende Nullen werden angegeben. Feld 9: Hochwert oder x-Wert Der jeweilige Hochwert oder x-Wert wird in der Maßeinheit Zentimeter dargestellt. Bei GK-Koordinaten erfolgt keine Angabe der 1000 km-Stelle. Führende Nullen werden angegeben. Also bei GK-Koordinaten sollte man immer vom Rechts- bzw. Hochwert sprechen, da die Vermesser X-Achse und Y-Achse anders sehen als die Normaluser! Markus schrieb: Hallo Miriam, das gleiche Ergebnis Ja, das hat mich auch irritiert. Damit ich eine Vorstellung der Differenzen bekomme, habe ich eine Tabelle gemacht, wieviel Nachkommastellen wie genau sind: http://wiki.openstreetmap.org/wiki/DE:Genauigkeit_von_Koordinaten (kann das bitte mal jemand prüfe?) Bei Deinen Beispielen beträgt die max. Abweichung Breite: 3,12m Länge: 4,35m*cos(Breite)=2,8m (wenn ich richtig gerechnet habe) Es würde also bei der dezimalen Koordinaten-Darstellung reichen, wenn man 5 Nachkommastellen angibt (der Rest gaukelt eine nicht vorhandene Genauigkeit vor). Und das gilt natürlich auch nur, wenn die ursprünglichen Messergebnisse vor der Umwandlung so genau waren. (in diesem Falle hat man mir 1 dm genannt) Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gauß-Krüger WGS-84
Das ist zwar im Prinzip richtig, aber in der Praxis werden oft gekürzte GK-Koordinaten verwendet, d.h. die erste Stelle in Rechts- und Hochwert werden weggelassen! Das hat auch einen ganz praktischen (historischen) Grund: Die Vermessungsämter arbeiten ja nur in ihrem Bereich und wissen daher, welchen Meridianstreifen sie benutzen und wie weit es zum Äquator ist. Die alten Rechnersysteme taten sich mit so großen Zahlen schwer, selbst frühere Versionen von AutoCad konnte nicht vernünftig mit den ungekürzten Koordinaten arbeiten. Man muss also vor den Hochwert (=Y) eine 5 schreiben und vo den Rechtswert die Nummer des Meridianstreifens, auf den sich die Koordinaten beziehen! Hier ist noch eine Online-Umrechnung http://www.orchids.de/florkart/skripte/GeoTrans.htm Gruß, Stefan Marco Lechner schrieb: Hallo Markus, die von Dir angegebenen Koordinaten sind so keine Gauß-Krüger-Koordinsten, da diese immer siebenstellig sind. Also entweder fehlt vorne was, was beim Rechtswert durchaus sein könnte, da Gauß-Krüger in Meridianstreifen aufgeteilt ist. Manchmal wird die erste Ordnungszahl weggelassen, die ist aber zur großräumigen Einordnung notwendig. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gauß-Krüger WGS-84
Mit Geotrans (link s. unten) und den GK-Koordinaten (auf ganze Meter gerundet) erhalte ich: GK: R=4452306 H=5495775 WGS-84: 11.3387955°E 49.5968617°N Gruß, Stefan Marco Lechner schrieb: das ist mir schon klar - nur leider hat Markus nicht angegeben wo er sich denn ungefähr befindet = im Bereich 6° Ost: GK: 2452305.9 5495774.9 latlon/WGS84: 5d20'22.957E 49d35'48.46N im Bereich 9° Ost: GK: 3452305.9 5495774.9 latlon/WGS84: 8d20'21.382E 49d35'48.524N im Bereich 12° Ost: GK: 4452305.9 5495774.9 latlon/WGS84: 11d20'19.815E 49d35'48.628N jeweils mit proj gerechnet (wie im Wiki angegeben): $ cs2cs -E +init=epsg:31466 +to +init=epsg:4326 EOF 2452305.9 5495774.9 EOF für Meridianstreifen 3 bzw. 4 eben mit epsg:31467 bzw. epsg:31468 und einem Rechtswert (Input) von 3452305.9 bzw. 4452305.9 Marco P.S. Hoffentlich waren in den Ursprungskoordintaen Rechts- und Hochwert nicht vertauscht ;-) Stefan Dettenhofer (StefanDausR) schrieb: Das ist zwar im Prinzip richtig, aber in der Praxis werden oft gekürzte GK-Koordinaten verwendet, d.h. die erste Stelle in Rechts- und Hochwert werden weggelassen! Das hat auch einen ganz praktischen (historischen) Grund: Die Vermessungsämter arbeiten ja nur in ihrem Bereich und wissen daher, welchen Meridianstreifen sie benutzen und wie weit es zum Äquator ist. Die alten Rechnersysteme taten sich mit so großen Zahlen schwer, selbst frühere Versionen von AutoCad konnte nicht vernünftig mit den ungekürzten Koordinaten arbeiten. Man muss also vor den Hochwert (=Y) eine 5 schreiben und vo den Rechtswert die Nummer des Meridianstreifens, auf den sich die Koordinaten beziehen! Hier ist noch eine Online-Umrechnung http://www.orchids.de/florkart/skripte/GeoTrans.htm Gruß, Stefan Marco Lechner schrieb: Hallo Markus, die von Dir angegebenen Koordinaten sind so keine Gauß-Krüger-Koordinsten, da diese immer siebenstellig sind. Also entweder fehlt vorne was, was beim Rechtswert durchaus sein könnte, da Gauß-Krüger in Meridianstreifen aufgeteilt ist. Manchmal wird die erste Ordnungszahl weggelassen, die ist aber zur großräumigen Einordnung notwendig. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gauß-Krüger WGS-84
Hallo Marco, danke für die Berechnung! leider hat Markus nicht angegeben wo er sich denn ungefähr befindet Das habe ich ja auch erst heute Nachmittag herausgefunden: dass GK siebenstellig ist und ich den 6-stelligen Zahlen der Vermessungsämter noch 400 rechts und 500 hoch hinzuzählen muss Bayern: im Bereich 12° Ost: GK: 4452305.9 5495774.9 latlon/WGS84: 11d20'19.815E 49d35'48.628N Nun hätte ich gern eine Website, auf der ich ganz simpel: GK eingeben -- WGS-84 herausbekommen kann. Damit ich es für die nächste Transformation selbst hinbekomme. (das mit dem proj4 ist für Nicht-Geometer schon viel zu kompliziert) Ah - die Seite vom BKG funktioniert wieder: Ergebnis: 11.33879752 E = 11°20'19,67 E 49.59685383 N = 49°35'48,67 N Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gauß-Krüger WGS-84
Markus schrieb: Nun hätte ich gern eine Website, auf der ich ganz simpel: GK eingeben -- WGS-84 herausbekommen kann. Markus, diese Transformation ist _nicht_ trivial und sie ist nicht gerade wenig fehlerbehaftet. Ich würde entweder Proj.4 nutzen oder etwas Eigenes schreiben. Dabei würde ich von den amtlichen Transformationsdaten ausgehen, einfach aus dem Grund, dass man die belegen kann. Damit ich es für die nächste Transformation selbst hinbekomme. (das mit dem proj4 ist für Nicht-Geometer schon viel zu kompliziert) Was genau ist kompliziert? Kommandozeile oder Texteditor? Vielleicht kann Dir jemand eine GUI schreiben ... ich kann leider nur PHP und neuerdings Perl und etwas Python. Ah - die Seite vom BKG funktioniert wieder: Ergebnis: 11.33879752 E = 11°20'19,67 E 49.59685383 N = 49°35'48,67 N Ja, die bauen gerade die Website um. Grüße Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gauß-Krüger WGS-84
Hallo Tobias, Nun hätte ich gern eine Website, auf der ich ganz simpel: GK eingeben -- WGS-84 herausbekommen kann. Markus, diese Transformation ist _nicht_ trivial und sie ist nicht gerade wenig fehlerbehaftet. Ja, das habe ich verstanden. Es geht auch nicht um ein persönliches Anliegen, sondern darum, dass der normale OSM-Nutzer, wenn er denn eine GK-Koordinate bekommt, diese in OSM nutzen kann. Dazu braucht es eine BlackBox: vorne GK rein, hinten das was OSM braucht raus. Wie das mit der Kartoffeligkeit der Welt und den Gittern, Projektionen, Geo- und Ellipsoiden ist braucht der Normal-Anwender erst mal nicht verstehen. (sogar meinem Geometer hier beim Vermessungsamt fällt es eher schwer, diese Zusammenhänge zu erklären). Ich schreibe immer alles was ich zu verstehen glaube ins Wiki. Und würde mich freuen, wenn das die Profis entsprecdhend berichtigen. Damit Dritte ebenfalls davon profitieren. Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
