Opened 12 years ago

Last modified 7 years ago

#52 reopened defect

Incorrect datum shift for EPSG:3844 ("Pulkovo 1942(58) / Stereo70" Romania)

Reported by: rouault Owned by: warmerdam
Priority: normal Milestone: 1.4.3
Component: libgeotiff Version:
Keywords: Cc:

Description

This is a ticket to match https://trac.osgeo.org/postgis/ticket/1851 that is directly linked to the libgeotiff/gdal chain :

""" The transformation parameters between S42 and WGS84 datums wihch are listed inside the EPSG:3844 definition (TOWGS84[33.4,-146.6,-76.3,-0.359,-0.053,0.844,-0.84]) are valid for Poland, not for Romania. You can see this in the EPSG database: Coordinate Transformation with code 1645: Area of use = Poland - onshore.

The correct parameters for datum transformation in the case of EPSG:3844 are listed in the EPSG database with coordinate transformation code = 15995. These are: 2.329,-147.042,-92.08,0.309,-0.325,-0.497,5.69 """

My quick analysis (I haven't explored how the python scripts in libgeotiff/csv work) : Indeed epsg-registry.org shows that the area of validity for EPSG:3844 is Romania, but the underlying GEOGCS (EPSG:4179) has a broader area of validity ("Europe - onshore - eastern - S-42(58)" which covers Albania, Bulgaria, Czech Republic, Germany (former DDR), Hungary, Poland, Romania and Slovakia.). Poland is likely the largest country in that area, hence the selected datum shift which is relevant for EPSG:4179, but not for EPSG:3844 built on it.

Change History (8)

comment:1 by warmerdam, 10 years ago

Resolution: fixed
Status: newclosed

Requested change applied in trunk (r2516).

comment:2 by rouault, 10 years ago

Frank,

the change breaks osr_epsg_3 in GDAL. I'm wondering if r2516 is correct. The suggested TOWGS84 is only for Romania (EPSG:3844), but probably not for other SRS using Pulkovo 42.

comment:3 by rouault, 10 years ago

Resolution: fixed
Status: closedreopened

comment:4 by robe, 10 years ago

Failing GDAL trunk failing on PostGIS debbie bot.

http://debbie.postgis.net:8080/job/GDAL_Regress/1753/consoleFull since gdal 27668 comit

 ------------ Failures ------------
Script: osr/osr_epsg.py
  TEST: osr_epsg_3 ... fail
    line 90: For EPSG:3120. Wrong TOWGS84, override missed?
 ----------------------------------

comment:5 by warmerdam, 10 years ago

On review, I concur that this is not an appropriate change. Reverted (r2546).

I'm not sure what we can do for this ticket. There isn't a good global selection for this datum, and we don't at this time have a practical way of overriding the datum selection for specific projected coordinate systems based on the datum.

comment:6 by tudorbarascu, 9 years ago

In Postgis the +wgs84 parameters are wrong, and by following https://trac.osgeo.org/postgis/ticket/1851 I arrived here as it seems this is the upstream for the parameters.

The coordinate transformation parameters given by the Romanian National Agency for Cadastre and Land Registration ( http://www.ancpi.ro ) are given for the Coordinate Frame Rotation method (https://epsg.io/9607-method) As proj4 uses the https://epsg.io/9606-method (Position Vector transformation) the sign of the rotation parameters needs to change so that it works in proj4 as referenced at http://proj.maptools.org/gen_parms.html

This is clear from the EPSG database.

SELECT c.coord_op_name, c.coord_op_method_code, a.parameter_value, b.parameter_name
 FROM epsg_coordoperationparamvalue a LEFT JOIN epsg_coordoperationparam b ON a.parameter_code = b.parameter_code
 LEFT JOIN epsg_coordoperation c on a.coord_op_code = c.coord_op_code
 WHERE a.coord_op_code = 15994;
         coord_op_name          | coord_op_method_code | parameter_value |   parameter_name   
--------------------------------+----------------------+-----------------+--------------------
 Pulkovo 1942(58) to ETRS89 (4) |                 9607 |          2.3287 | X-axis translation
 Pulkovo 1942(58) to ETRS89 (4) |                 9607 |       -147.0425 | Y-axis translation
 Pulkovo 1942(58) to ETRS89 (4) |                 9607 |        -92.0802 | Z-axis translation
 Pulkovo 1942(58) to ETRS89 (4) |                 9607 |       0.3092483 | X-axis rotation
 Pulkovo 1942(58) to ETRS89 (4) |                 9607 |     -0.32482185 | Y-axis rotation
 Pulkovo 1942(58) to ETRS89 (4) |                 9607 |     -0.49729934 | Z-axis rotation
 Pulkovo 1942(58) to ETRS89 (4) |                 9607 |      5.68906266 | 

So, the correct parameters should be:

+towgs84=2.3287,-147.0425,-92.0802,-0.3092483,0.32482185,0.49729934,5.68906266

and not as it's now in Postgis - with incorrect rotation parameters

+towgs84=2.329,-147.042,-92.08,0.309,-0.325,-0.497,5.69

As I am not at all familiar with SVN, maybe someone with commit rights can make the appropriate changes. Thanks a lot!

Version 0, edited 9 years ago by tudorbarascu (next)

comment:7 by rouault, 8 years ago

Milestone: 1.4.3
Resolution: fixed
Status: reopenedclosed

r2747 "add mechanism to define TOWGS84 parameters per PCS (instead of only relying on the TOWGS84 parameters of the underlying GCS). Add override for EPSG:3844 ('Pulkovo 1942(58) / Stereo70' Romania). Fixes https://trac.osgeo.org/geotiff/ticket/52"

GDAL https://trac.osgeo.org/gdal/changeset/37080

Updated files will be available per the EPSG v9.0 upgrade: ​https://trac.osgeo.org/geotiff/ticket/83

comment:8 by danielurda, 7 years ago

Resolution: fixed
Status: closedreopened

There is still the issue of the rotation sign. The codes that get into gcs.csv and use 9607 have the sign changed downstream by GDAL, but this is not the case for the overrides in pcs.csv. In order to get overrides right, the rotation should be fixed here (in build_pcs.py probably), or the method id should also be passed in the CSV and afterwards have GDAL updated to take it into account.

Note: See TracTickets for help on using tickets.