Opened 12 years ago
Closed 11 years ago
#4597 closed defect (fixed)
[PATCH - to upstream in libgeotiff] Consider better OSGB 1936 Default Datum Shift
Reported by: | warmerdam | Owned by: | warmerdam |
---|---|---|---|
Priority: | normal | Milestone: | 1.10.0 |
Component: | OGR_SRS | Version: | svn-trunk |
Severity: | normal | Keywords: | OSGB36 datum shift |
Cc: |
Description
currently OSGB 1936 (GCS 4277) is using this datum shift by default:
490,1195,4277,4326,Derived at 38 stations.,"For military purposes only. Accuracy 10m, 10m and 15m in X, Y and Z axes.",1264,49.96,60.84,-7.56,1.78,1,0,9603,375,-111,431,1
But some uses feel the following would be more appropriate. Review and consider.
495,1314,4277,4326,"For a more accurate transformation see OSGB 1936 / British National Grid to ETRS89 (2) (code 1039): contact the Ordnance Survey of Great Britain (http://www.gps.gov.uk/gpssurveying.asp) for details.",Oil exploration. Accuracy better than 4m and generally better than 2m.,1264,49.96,60.84,-7.56,1.78,1,0,9606,446.448,-125.157,542.06,0.15,0.247,0.842,-20.489,0
Attachments (1)
Change History (5)
comment:1 by , 11 years ago
comment:2 by , 11 years ago
Version: | unspecified → svn-trunk |
---|
I would favour that. The second values are identical with the +datum values used until GDAL 1.7.3.
There are many complaints since the abandonning of the +datum, leading to a regression in accuracy for OSGB1936. See http://gis.stackexchange.com/questions/40461/raster-incorrectly-reprojected-to-osgb27700 and the linked references.
comment:3 by , 11 years ago
Summary: | Consider better OSGB 1936 Default Datum Shift → [PATCH - to upstream in libgeotiff] Consider better OSGB 1936 Default Datum Shift |
---|
I've attached a patch that should fix it by overriding the definition of EPSG:4277 by selecting the EPSG:1314 datum shift. However this should be applied in libgeotiff first.
comment:4 by , 11 years ago
Keywords: | OSGB36 datum shift added |
---|---|
Milestone: | → 1.10.0 |
Resolution: | → fixed |
Status: | new → closed |
I have applied a variation on this patch in libgeotiff - adding the preferred shift in the datum_shift_prefs.csv - and regenerated files in libgeotiff.
http://trac.osgeo.org/geotiff/changeset/2312
Pulled changes down into GDAL (r25589).
I checked and there is no need to refresh PROJ.4 since it uses +datum=OSGB36 which already expands to the right values.
The GDAL changes will be part of 1.10.
Aye.