Ergebnis 1 bis 6 von 6

Thema: ST_Transform von EPSG: 31468 nach EPSG: 4326 nicht eineindeutig?

  1. #1
    saitenheini ist offline Neuer Benutzer
    Registriert seit
    04.11.2011
    Beiträge
    5

    Frage ST_Transform von EPSG: 31468 nach EPSG: 4326 nicht eineindeutig?

    Hallo liebes Forum,

    ich habe folgendes Problem:

    Ich habe ein Tabelle mit Polygonen (EPSG: 4326). Die Eingangsdaten liegen in unterschiedlichen Koordinatensystemen vor.
    D.h. wenn ich Polygone aus EPSG-Code 31468 ins 4326 transformiere und dann in meine Tabelle importiere, erwarte ich, dass
    ich bei der Rücktransformation der Daten aus meiner Tabelle in EPSG-Code 31468 die Polygone ohne Verschiebung zurückbekomme.

    Aber:
    Bei Daten, die im EPSG-Code 31468 vorliegen bekomme ich eine Abweichung bei der Rücktransformation.
    Bei EPSG-Code 3397 nicht. Woran könnte das liegen?


    Code:
    SELECT ST_AsText (ST_Transform(ST_Transform(the_geom,4326),31468)) FROM test_polygon_31468;
    SELECT ST_AsText (ST_Transform(ST_Transform(the_geom,4326),3397)) FROM test_polygon_3397;
    EPSG: 31468 nach ST_Transform über 4326 Deviation
    4492539,64197082 4492539,64193947 0,00003135
    5621068,30964302 5621068,30960137 0,00004165
    4492539,48593203 4492539,48590068 0,00003135
    5621079,07631938 5621079,07627772 0,00004166
    4492555,16783021 4492555,16779884 0,00003137
    5621080,94878483 5621080,94874317 0,00004166
    4492539,64197082 4492539,64193947 0,00003135
    5621068,30964302 5621068,30960137 0,00004165
    EPSG: 3397 nach ST_Transform über 4326 Deviation
    4492539,64197082 4492539,64197082 0,00000000
    5621068,30964302 5621068,30964302 0,00000000
    4492539,48593203 4492539,48593203 0,00000000
    5621079,07631938 5621079,07631938 0,00000000
    4492555,16783021 4492555,16783021 0,00000000
    5621080,94878483 5621080,94878483 0,00000000
    4492539,64197082 4492539,64197082 0,00000000
    5621068,30964302 5621068,30964302 0,00000000

  2. #2
    Gisman ist offline Erfahrener Benutzer
    Registriert seit
    20.01.2006
    Ort
    Pfalz
    Beiträge
    794

    Standard

    Naja, Die Abweichung liegt im Bereich von 1/100 mm, wer behauptet seine Koordinaten sind so genau soll mir das zeigen . Ich denke das kann man ertragen, Bei Esri ist/war die Abweichung wesentlich deutlicher (>mm, also durchaus im messbaren Bereich).
    Das kann bei der Transformation schon mal passieren, kommt vermutlich an wie da gerundet wird. Warum es bei einer Transformation passiert un bei einer andern nicht, kann ich dir auch nicht sagen, wie gesagt, vermutlich Rundung oder so.

    Gruß Uwe
    Have a lot of fun!

  3. #3
    saitenheini ist offline Neuer Benutzer
    Registriert seit
    04.11.2011
    Beiträge
    5

    Standard

    Hallo Uwe,

    vielen Dank für Deine Rückmeldung. Du hast natürlich Recht: Die Abweichung ist gering. Ich kann mir nur nicht erklären, warum es bei Lagestatus 100 eine Abweichung gibt und bei Lagestatus 120 keine.

    Ich habe eigentlich auch ein anderes Problem und habe deshalb Nachforschungen angestellt.
    Ich stelle meine Daten in QuantumGIS bzw. AutoCAD Civil 3D dar und dort habe ich sogar eine Abweichung von ca. 2 Metern, wenn ich die Daten aus EPSG 4326 in EPSG 31468 darstelle. Wenn ich die Daten aus EPSG 4326 in EPSG 3397 darstelle funktioniert es (zumindest keine visuelle Abweichung).

    Hast Du einen Tip woran das liegen könnte?

    Viele Grüße,
    Max.
    Geändert von saitenheini (07.11.2011 um 09:31 Uhr)

  4. #4
    saitenheini ist offline Neuer Benutzer
    Registriert seit
    04.11.2011
    Beiträge
    5

    Standard

    Hallo,

    ich denke, dass ich den Fehler gefunden habe. Es liegt scheinbar nicht an PostGIS sondern an der Bibliothek PROJ.4.

    siehe hier Genaue proj4 Definition EPSG 31466 (Gauß Krüger) (Page 1) / users: Germany / OpenStreetMap Forum

    allerdings sehen auch meine QGIS (Version 1.7.1) Paramter anders aus:
    +proj=tmerc +lat_0=0 +lon_0=12 +k=1 +x_0=4500000 +y_0=0 +ellps=bessel +towgs84=582,105,414,1.04,0.35,-3.08,8.3 +units=m +no_defs


    Viele Grüße.
    Geändert von saitenheini (07.11.2011 um 11:23 Uhr)

  5. #5
    Gisman ist offline Erfahrener Benutzer
    Registriert seit
    20.01.2006
    Ort
    Pfalz
    Beiträge
    794

    Standard

    Sieht gut aus. Ich dachte mir schon irgendwie, das es mit irgendwelchen 'Ungenauigkeiten' im Algorithmus zu tun hat. Danke für den Link, hilft mir auch sehr, da ich vermutlich bald einen Nachweis über Transformationsparameter bringen muß.

    Gruß Uwe
    Have a lot of fun!

  6. #6
    saitenheini ist offline Neuer Benutzer
    Registriert seit
    04.11.2011
    Beiträge
    5

    Standard

    Naja, die Abweichung bei Rücktransformation bleibt bestehen bzw. wird sie sogar noch "größer".

    PROJ.4-Parametersatz:
    Code:
    +proj=tmerc +lat_0=0 +lon_0=12 +k=1 +x_0=4500000 +y_0=0 +ellps=bessel +towgs84=598.1,73.7,418.2,0.202,0.045,-2.455,6.7 +units=m +no_defs
    
    SQL:
    Code:
    SELECT ST_AsText (ST_Transform(ST_Transform(the_geom,4326),31468)) FROM test_polygon_31468;
    Ergebnis:
    EPSG: 31468 nach ST_Transform über 4326 abs(Deviation)
    4492539,64197082 4492539,64234360 0,00037278
    5621068,30964302 5621068,31017088 0,00052786


    Hier dieser Link ist auch ganz interessant zu diesem Thema:
    [Mapserver-DE] BETA2007 Transformation

Ähnliche Themen

  1. Fehler bei st_transform für Multipolygon
    Von lars im Forum PostGIS
    Antworten: 2
    Letzter Beitrag: 13.01.2011, 14:27
  2. Problem Sortieren nach Zeit klappt nicht
    Von kajota im Forum SQL
    Antworten: 1
    Letzter Beitrag: 30.06.2010, 22:05
  3. aus esri .prj auf epsg-code schliessen
    Von rajanski im Forum PostGIS
    Antworten: 2
    Letzter Beitrag: 21.10.2009, 12:59
  4. PG Startet nach erfolgreicher Inst. nicht
    Von Sy- im Forum Installation von PostgreSQL
    Antworten: 3
    Letzter Beitrag: 07.09.2006, 12:16
  5. PG Startet nach kopeiren der Data nicht
    Von Sy- im Forum Migration
    Antworten: 2
    Letzter Beitrag: 18.04.2006, 15:53

Stichworte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

Links: Tobias Bauer - IT- und Funkdienstleistungen   -   Bilderrahmen-kaufen.de - Der Onlineshop für Bilderrahmen & Fotorahmen   -   Funkforum