Gauss-Krüger or not EPSG EPSG: That is the question!
Oracle10g Release 2 has been supporting the Oracle database system for the EPSG coordinate system. The projection Tuesday, September 21, 2010
Brzydula Odcinki Onbline
Gauss-Kruger zone 3 is thus equal to twice 
ready:
ready: as "traditional" Oracle SRID 82 027
- the EPSG-code standard as 31 467
- SQL> select srid, cs_name from cs_srs where srid in (31 467, 82 027) ---------- ------------------------------ SRID CS_NAME ---------- 31 467 DHDN / Gauss-Kruger zone 3 82 027 GK Zone 3 (DHDN) One might get the idea that there is now no matter what code you use. But it is not, unfortunately. Between the standard system to EPSG
31 467 and the "Oracle Version", there are differences ... and I want to work in this blog posting.
First, I suppose the coordinate of Oracle in Munich (with the Oracle Geocoder, of course) and counting after the EPSG: at 31467th select sdo_cs.transform (SDO_GEOMETRY (2001, 8307, sdo_point_type (11.536734, 48.1800773, null), null, null), 31 467) transformed from dual; TRANSFORMED ---------------- -------------------------------------------------- ------------------ SDO_GEOMETRY (2001, 31 467, SDO_POINT_TYPE (3688714.69, 5341125.2, NULL), NULL, NULL)
This is absolutely the correct coordinates in the coordinate system EPSG: 31467th But one might get the idea, save it with the ID 82 027
in the database ... if it's the same coordinate system, that would matter ...
So we expect the returns to WGS84 coordinates and once with the SRID 31 467 and once with 82027th select sdo_cs.transform (SDO_GEOMETRY (2001, 31 467
, 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, 82 027
, SDO_POINT_TYPE (3688714.69, 5341125.2, NULL), NULL, NULL), 8307) from dual ; TRANSFORMED ------------------------------------------------ ------------------------------------ SDO_GEOMETRY (2001, 8307, SDO_POINT_TYPE (11.5391267, 48, 180 154, NULL), NULL, NULL) And you see that it is not the same. If one compares the Well Known Text , can be noted that there are some differences in the parameters. The difference lies in the range of about 100 to 200 meters.
select sdo_geom.sdo_distance (sdo_cs.transform (SDO_GEOMETRY (2001, 31 467, SDO_POINT_TYPE (3688714.69, 5341125.2, NULL), NULL, NULL), 8307), sdo_cs.transform (SDO_GEOMETRY (2001, 82 027, SDO_POINT_TYPE (3688714.69, 5341125.2, NULL ), NULL, NULL), 8307), 1) distance from dual; DISTANCE ------------- 178.128988
And what does this mean? Zuerstmal no problem! It has to be when you GK3 coordinates loads (for example, from shape files) into the database, note only. If one looking at the data discrepancies in the clear from the 100 to 200 meters, you should try the other GK3-SRID. In most cases, is one with the newer EPSG number31 467
correctly. But I've also seen cases in which 82 027 had to be taken. Extrapolating to a geometry of 82 027 31 467
to come (consistently) out and not have the same coordinates. SQL> select sdo_cs.transform (2 SDO_GEOMETRY (2001, 82 027, SDO_POINT_TYPE (3688714.69, 5341125.2, NULL), NULL, NULL), 3 31 467 4) TRANSFORMED from dual; TRANSFORMED ----------- -------------------------------------------------- ---------------------- SDO_GEOMETRY (2001, 31 467, SDO_POINT_TYPE (3688892.31, 5341139.61, NULL); NULL, NULL) For the other common in Germany, Gauss-Krüger projection is the same way.
SQL> select srid, cs_name from cs_srs where srid in (31 466, 82 015); CS_NAME SRID ---------- ------------------- --------------------- 31 466 DHDN / Gauss-Kruger zone 2 82 015 GK Zone 2 (DHDN) SQL> select srid, cs_name from cs_srs where srid in (31 468, 82 032), SRID CS_NAME ---------- ----------------------------------- 31 468 ----- DHDN / Gauss-Kruger zone 4 82 032 GK Zone 4 (DHDN)
Subscribe to:
Post Comments (Atom)
0 comments:
Post a Comment