EPSG:28992 - Lacking datum parameters for Amersfoort

[johantenbreteler]

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 .

[warmerdam]

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.

[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.

[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...

[warmerdam]

I have done a major upgrade to the EPSG processing logic in libgeotiff and now a datum shift is selected for Amersfoort. The proj.4 string will be:

+proj=sterea +lat_0=52.15616055555555 +lon_0=5.38763888888889 +k=0.9999079 +x_0=155000 
  +y_0=463000 +ellps=bessel +towgs84=565.04,49.91,465.84,-1.9848,1.7439,-9.0587,4.0772 
  +units=m +no_defs

There appears to be four possible shifts in the EPSG database, but this seems like the preferred one. Let me know if you feel otherwise. I'll leave this ticket open until I have committed an updated csv files in GDAL.

[warmerdam]

GDAL csv files updated in trunk (r18978).