Opened 16 years ago
Closed 14 years ago
#1987 closed defect (fixed)
EPSG:28992 - Lacking datum parameters for Amersfoort
Reported by: | johantenbreteler | Owned by: | warmerdam |
---|---|---|---|
Priority: | normal | Milestone: | 1.8.0 |
Component: | OGR_SRS | Version: | svn-trunk |
Severity: | normal | Keywords: | datum shift |
Cc: | Mateusz Łoskot, vincentschut |
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 (7)
comment:1 by , 16 years ago
Component: | default → OGR_SRS |
---|---|
Keywords: | datum shift added |
Summary: | Conversion error from shp files to kml format → EPSG:28992 - Lacking datum parameters for Amersfoort |
Version: | unspecified → svn-trunk |
comment:2 by , 16 years ago
Cc: | added |
---|
comment:3 by , 16 years ago
According to http://spatialreference.org/ref/epsg/28992/ there seems to be only one datum which does not appear in the PROJ4 EPSG file.
comment:4 by , 14 years ago
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...
comment:5 by , 14 years ago
Status: | new → assigned |
---|
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.
comment:6 by , 14 years ago
Cc: | added |
---|
comment:7 by , 14 years ago
Milestone: | → 1.8.0 |
---|---|
Resolution: | → fixed |
Status: | assigned → closed |
GDAL csv files updated in trunk (r18978).
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.
I'm going to leave this open as a reminder to review the datum shift selection rules when OGRSpatialReference expands EPSG definitions.