Ticket #1987 (new defect)

Opened 2 years ago

Last modified 5 months ago

EPSG:28992 - Lacking datum parameters for Amersfoort

Reported by: johantenbreteler Assigned to: warmerdam
Priority: normal Milestone:
Component: OGR_SRS Version: svn-trunk
Severity: normal Keywords: datum shift
Cc: mloskot

Description

When I try to do a conversion from shp file to a kml format the result in google earth is not exactly the position which the converted info should be have. It seems that there a kind of offset. I try to convert from EPSG:28992 to WGS84. I found a work around for this problem , but I wondering that it works so. failing method

ogr2ogr -f KML -t_srs WGS84 -s_srs EPGS:28992 <file>.kml <file>.shp

work around

ogr2ogr -f KML -t_srs WGS84 -s_srs "+proj=sterea +lat_0=52.15616055555555 +lon_0=5.38763888888889 +k=0.999908 +x_0=155000 +y_0=463000 +ellps=bessel +towgs84=565.237,50.0087,465.658,-0.406857,0.350733,-1.87035,4.0812 +units=m +no_defs <>" <file>.kml <file>.shp

So if not using the EPGS:28992 mnemonic gives a correct translation to WGS84. I don't known what the reason is that the work around works. I try the conversion with FwTools? pack 1.4.2 .

Change History

11/13/2007 09:43:51 AM changed by warmerdam

  • keywords set to datum shift.
  • version changed from unspecified to svn-trunk.
  • component changed from default to OGR_SRS.
  • summary changed from Conversion error from shp files to kml format to EPSG:28992 - Lacking datum parameters for Amersfoort.

The default expansion of EPSG:28992 is as follows which lacks towgs84 parameters. The issue is (presumably) that EPSG offers conflicting transformations and so OGR ignores them all as expected. 

PROJCS["Amersfoort / RD New",
    GEOGCS["Amersfoort",
        DATUM["Amersfoort",
            SPHEROID["Bessel 1841",6377397.155,299.1528128,
                AUTHORITY["EPSG","7004"]],
            AUTHORITY["EPSG","6289"]],
        PRIMEM["Greenwich",0,
            AUTHORITY["EPSG","8901"]],
        UNIT["degree",0.01745329251994328,
            AUTHORITY["EPSG","9122"]],
        AUTHORITY["EPSG","4289"]],
    UNIT["metre",1,
        AUTHORITY["EPSG","9001"]],
    PROJECTION["Oblique_Stereographic"],
    PARAMETER["latitude_of_origin",52.15616055555555],
    PARAMETER["central_meridian",5.38763888888889],
    PARAMETER["scale_factor",0.9999079],
    PARAMETER["false_easting",155000],
    PARAMETER["false_northing",463000],
    AUTHORITY["EPSG","28992"]]

I'm going to leave this open as a reminder to review the datum shift selection rules when OGRSpatialReference expands EPSG definitions.

11/19/2007 09:52:22 PM changed by mloskot

  • cc set to mloskot.

08/19/2008 06:22:14 AM changed by neteler

According to http://spatialreference.org/ref/epsg/28992/ there seems to be only one datum which does not appear in the PROJ4 EPSG file.

09/23/2009 05:54:55 AM changed by vincentschut

We (SarVision?, NL) have just hit this defect, and luckily found this bugzilla entry with the correct datum shift parameters. IMHO the proj translation for the EPSG entry for Amersfoort RD New (28992) should either containt the correct datum definition (datum: 'Amersfoort', however, I'm not sure proj knows about this datum), or the correct towgs84 parameters. Is this the right place to discuss this, or should this go to some EPSG/proj related issue tracker? It's been a long time since this issue was filed, and I wonder why it has not been resolved as the fix seems trivial to me. Please correct me if I'm wrong...