Dienstag, 21. September 2010

Gauss-Krüger: EPSG oder nicht EPSG: Das ist hier die Frage!

Seit Oracle10g Release 2 unterstützt die Oracle-Datenbank die EPSG-Systematik für Koordinatensysteme. Die Projektion Gauss-Krüger Zone 3 steht damit gleich zweimal bereit:
  • als "klassische" Oracle-SRID 82027
  • im EPSG-Standard als Code 31467
SQL> select srid,cs_name from cs_srs where srid in (31467, 82027)

      SRID CS_NAME
---------- ----------------------------------------
     31467 DHDN / Gauss-Kruger zone 3
     82027 GK Zone 3 (DHDN)
Man könnte auf den Gedanken kommen, dass es nun egal ist, welchen Code man verwendet. Aber das ist es leider nicht. Zwischen dem nach EPSG standardisierten System 31467 und der "Oracle-Version" gibt es Unterschiede ... und die möchte ich in diesem Blog Posting herausarbeiten.
Zunächst nehme ich die Koordinate von Oracle in München (mit dem Oracle-Geocoder, versteht sich) und rechne die nach EPSG:31467 um.
select sdo_cs.transform(
  sdo_geometry(2001, 8307, sdo_point_type(11.536734, 48.1800773, null), null, null), 
  31467
) transformed from dual;

TRANSFORMED
------------------------------------------------------------------------------------
SDO_GEOMETRY(2001, 31467, SDO_POINT_TYPE(3688714,69, 5341125,2, NULL), NULL, NULL)
Dies ist die absolut korrekte Koordinate im Koordinatensystem EPSG:31467. Man könnte aber auf den Gedanken kommen, diese mit der ID 82027 in die Datenbank zu speichern ... wenn's das gleiche Koordinatensystem ist, wäre das ja egal ...
Also rechnen wir die Koordinate wieder in WGS84 zurück und zwar einmal mit der SRID 31467 und einmal mit 82027.
select sdo_cs.transform(
  SDO_GEOMETRY(2001, 31467, SDO_POINT_TYPE(3688714.69, 5341125.2, NULL), NULL, NULL ),
  8307
) transformed from dual;

TRANSFORMED
------------------------------------------------------------------------------------
SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(11,5367341, 48,1800773, NULL), NULL, NULL)

select sdo_cs.transform(
  SDO_GEOMETRY(2001, 82027, SDO_POINT_TYPE(3688714.69, 5341125.2, NULL), NULL, NULL ),
  8307
) from dual;

TRANSFORMED
------------------------------------------------------------------------------------
SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(11,5391267, 48,180154, NULL), NULL, NULL)
Und man sieht, dass es nicht das gleiche ist. Wenn man die Well Known Texts vergleicht, lässt sich auch feststellen, dass es in den Parametern ein paar Unterschiede gibt. Die Abweichung liegt meist im Bereich von ca. 100 bis 200 Metern.
select sdo_geom.sdo_distance(
 sdo_cs.transform(
  SDO_GEOMETRY(2001, 31467, SDO_POINT_TYPE(3688714.69, 5341125.2, NULL), NULL, NULL ),
  8307
 ),
 sdo_cs.transform(
  SDO_GEOMETRY(2001, 82027, SDO_POINT_TYPE(3688714.69, 5341125.2, NULL), NULL, NULL ),
  8307
 ),
 1
) distanz from dual;

DISTANZ
-------------
   178,128988
Und was bedeutet das? Zuerstmal alles kein Problem! Man muss es, wenn man GK3-Koordinaten (bspw. aus Shapefiles) in die Datenbank lädt, nur beachten. Stellt man beim Betrachten der Daten Abweichungen im Bereich von 100 bis 200 Metern fest, sollte man die andere GK3-SRID versuchen. Meistens liegt man mit der neueren EPSG-Nummer 31467 richtig. Aber ich habe auch schon Fälle erlebt, in denen die 82027 genommen werden musste.
Rechnet man eine Geometrie von 82027 nach 31467 um, kommen (folgerichtig) auch nicht die gleichen Koordinaten heraus.
SQL> select sdo_cs.transform(
  2    SDO_GEOMETRY(2001, 82027, SDO_POINT_TYPE(3688714.69, 5341125.2, NULL), NULL, NULL ),
  3    31467
  4  ) TRANSFORMED from dual;

TRANSFORMED
-----------------------------------------------------------------------------------
SDO_GEOMETRY(2001, 31467, SDO_POINT_TYPE(3688892,31, 5341139,61, NULL), NULL, NULL)
Für die anderen in Deutschland gebräuchlichen Gauss-Krüger Projektionen gilt das analog.
SQL> select srid,cs_name from cs_srs where srid in (31466, 82015);

      SRID CS_NAME
---------- ----------------------------------------
     31466 DHDN / Gauss-Kruger zone 2
     82015 GK Zone 2 (DHDN)

SQL> select srid,cs_name from cs_srs where srid in (31468, 82032);

      SRID CS_NAME
---------- ----------------------------------------
     31468 DHDN / Gauss-Kruger zone 4
     82032 GK Zone 4 (DHDN)

5 Kommentare:

  1. Habe den gleichen Fehler bei der Transformation von 82032 bzw. EPSG 31468 nach 83032


    FID NEU_EAST SOLL_UTM_EAST DELTA_RECHTS NEU_NORD SOLL_UTM_NORD DELTA_NORD
    ---------- ------------- ------------- ------------ ----------- ------------- ----------
    40 625120.56 624948 172.56 5642353.87 5642340 13.87
    42 625103.30 624931 172.30 5642366.10 5642352 14.10
    44 625108.47 624936 172.47 5642603.72 5642590 13.72
    46 625460.19 625287 173.19 5643159.41 5643146 13.41
    48 607717.04 607544 173.04 5644040.41 5644027 13.41
    74 619172.47 619000 172.47 5645431.71 5645418 13.71
    10 607667.52 607495 172.52 5644056.69 5644043 13.69
    12 606017.98 605845 172.98 5640622.97 5640610 12.97
    52 615923.71 615751 172.71 5639293.28 5639280 13.28


    Was macht man nun um richtige Ergebnisse zu bekommen ?

    Alle Varianten der Zielkoordinatensysteme

    -- 25832 : ETRS89 Zone 32
    -- 32432 :
    -- 82344 UTM Zone 32, Northern Hemisphere (WGS 84)

    bringen gleichen Fehler !


    MfG
    M.Edelhof

    AntwortenLöschen
  2. Habe den gleichen Fehler bei der Transformation von 82032 bzw. EPSG 31468 nach 83032


    FID NEU_EAST SOLL_UTM_EAST DELTA_RECHTS NEU_NORD SOLL_UTM_NORD DELTA_NORD
    ---------- ------------- ------------- ------------ ----------- ------------- ----------
    40 625120.56 624948 172.56 5642353.87 5642340 13.87
    42 625103.30 624931 172.30 5642366.10 5642352 14.10
    44 625108.47 624936 172.47 5642603.72 5642590 13.72
    46 625460.19 625287 173.19 5643159.41 5643146 13.41
    48 607717.04 607544 173.04 5644040.41 5644027 13.41
    74 619172.47 619000 172.47 5645431.71 5645418 13.71
    10 607667.52 607495 172.52 5644056.69 5644043 13.69
    12 606017.98 605845 172.98 5640622.97 5640610 12.97
    52 615923.71 615751 172.71 5639293.28 5639280 13.28


    Was macht man nun um richtige Ergebnisse zu bekommen ?

    Alle Varianten der Zielkoordinatensysteme

    -- 25832 : ETRS89 Zone 32
    -- 32432 :
    -- 82344 UTM Zone 32, Northern Hemisphere (WGS 84)

    bringen gleichen Fehler !


    MfG
    M.Edelhof

    AntwortenLöschen
  3. Diese Fragestellung ist auch gerade bei einem Landratsamt akut gewesen. Dort wurden Daten mit der Oracle SRID für GK Zone 4 (82032) geladen. Das ergab bei der Transformation nach ETRS89, UTM Zone 32 sowohl bei SRID=25832 (EPSG) als auch bei SRID=83032 (Oracle) Abweichungen im Bereich von ca. 173 m.
    Die Lösung hier war also, die Daten bereits mit den EPSG SRID 31468 für GK Zone 4 zu laden. Damit paßte das Ganze dann.

    AntwortenLöschen
  4. Habe auch einen Fehler im Bereich 100 - 200 Meter.
    Bei der Abgrage müsste annähernd jeweils 0 rauskommen.
    select 248613.937765721-ZX XABWEICHUNG, 5975266.744106329-ZY YABWEICHUNG from (
    select
    SDO_CS.TRANSFORM(
    MDSYS.SDO_GEOMETRY(2001
    ,G.QSRID
    ,MDSYS.SDO_POINT_TYPE(
    G.QX
    ,G.QY
    , NULL)
    , NULL
    , NULL), G.ZSRID).SDO_POINT.X ZX
    , SDO_CS.TRANSFORM(
    MDSYS.SDO_GEOMETRY(2001
    ,G.QSRID
    ,MDSYS.SDO_POINT_TYPE(
    G.QX
    ,G.QY
    , NULL)
    , NULL
    , NULL), G.ZSRID).SDO_POINT.Y ZY
    from ( select 2398 QSRID
    , 25833 ZSRID
    , 4445947.524281586 QX
    , 5971339.151383175 QY
    from dual ) G
    );

    AntwortenLöschen
  5. Hallo,

    ich vermute sehr stark, dass die SRID 2398 für Ihre Daten die falsche ist - könnten Sie mal den WKTEXT des Koordinatensystems posten, mit dem Sie die Referenzwerte gerechnet haben ... u.U. muss ein eigenes Koordinatensystem in Oracle generiert werden ...

    Beste Grüße

    Carsten Czarski

    AntwortenLöschen