Opened 14 years ago
Closed 14 years ago
#3261 closed defect (fixed)
Error in gcs.csv: build_pcs.py doesn't check unit of rotation angles in 7-param datum shift
Reported by: | mikrit | Owned by: | warmerdam |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | OGR_SRS | Version: | unspecified |
Severity: | minor | Keywords: | datum shift gcs.csv |
Cc: |
Description
The file build_pcs.py, at http://svn.osgeo.org/metacrs/geotiff/trunk/libgeotiff/csv, extracts 3- and 7-parameter datum shifts from EPSG, and stores them in gcs.csv, which is used by GDAL/OGR. In gcs.csv, it is assumed that the rotations of a 7-parameter datum shift is given in arc seconds. However, a few rotations from EPSG come in a different unit, like microradians or radians, and build_pcs.py fails to convert the angles.
Currently, this causes only one error in gcs.csv, namely the transform for CRS epsg:4660, "Helle 1954 to WGS 84(1)". Since Helle 1954 is a datum for Jan Mayen Island, population 25, it is not so important. But unusual angle units occur also in some Dutch and Canadian datum shifts, although these don't make it to gcs.csv (due to the existence of alternative datum shifts for these datums).
(In theory, the geocentric translations DX, DY, DZ don't need to be in meters in EPSG, although I think they are always in meters in practice.)
Change History (5)
comment:1 by , 14 years ago
Priority: | low → normal |
---|
comment:2 by , 14 years ago
Status: | new → assigned |
---|
I have added logic in build_pcs.py to address this problem. I would appreciate it if you could confirm that the results for Helle 1954 (or Amersfoort and ED1987) are not reasonable. The change in libgeotiff is:
I'll leave the ticket open until the changes make it into GDAL.
comment:4 by , 14 years ago
Yes, the conversion from micro-radians seems to work. The new rotations for Helle 1954 and for ED1987 agree with the rotations I had computed (although I don't have test points for these datum shifts).
I haven't checked the conversions from radians and centesimal seconds.
Good point. This will need to be fixed upstream in libgeotiff, and I'm not sure when I will get to it. But it is excellent to have a clear analysis of the problem ready for when the problem is addressed.