Opened 11 years ago

Closed 5 years ago

#5085 closed enhancement (wontfix)

Setting GDAL/cs2cs/proj to use additional NTv2 grid shift file when using EPSG codes

Reported by: tcgeophysics Owned by: warmerdam
Priority: normal Milestone: closed_because_of_github_migration
Component: default Version: unspecified
Severity: normal Keywords:
Cc:

Description

Hi,

I am using the GDAL API in Python for a script that takes only EPSG codes for inputs to specify source and target coordinate systems.

While the cs2cs command seems to handle quite well transformation between NAD27 (EPSG:4267) and NAD83 (EPSG:4326) coordinates in North America, I would like to have similar capabilities for AGD66 (EPSG:4202) to GDA94 (EPSG:4283) and AGD84 (EPSG:4203) to GDA94 (EPSG:4283) in Australia.

When using the -v option with cs2cs to look at the proj string being used, I get the following:

cs2cs -v +init=epsg:4267 # ---- From Coordinate System ---- #Lat/long (Geodetic alias) # # +init=epsg:4267 +proj=longlat +datum=NAD27 +no_defs +ellps=clrk66 # +nadgrids=@conus,@alaska,@ntv2_0.gsb,@ntv1_can.dat # ---- To Coordinate System ---- #Lat/long (Geodetic alias) # # +proj=latlong +datum=NAD27 +ellps=clrk66 # +nadgrids=@conus,@alaska,@ntv2_0.gsb,@ntv1_can.dat

The nadgrids parameters tells cs2cs to use the best fitting datum grid shift file from conus, alaska, ntv2_0.gsb, and ntv1_can.dat.

For AGD66 (EPSG:4202) cs2cs returns:

cs2cs -v +init=epsg:4202 # ---- From Coordinate System ---- #Lat/long (Geodetic alias) # # +init=epsg:4202 +proj=longlat +ellps=aust_SA # +towgs84=-117.808,-51.536,137.784,0.303,0.446,0.234,-0.29 +no_defs # ---- To Coordinate System ---- #Lat/long (Geodetic alias) # # +proj=latlong +ellps=aust_SA # +towgs84=-117.808,-51.536,137.784,0.303,0.446,0.234,-0.29

There is no nadgrids parameter but a towgs84 instead. A grid shift file from the ICSM; "A66 National (13.09.01).gsb" contains the shift between AGD66 and GDA94.

How can GDAL/cs2cs/proj identify this file when using only EPSG codes?

As NTv2 file are being more commonly used by various countries to handle datum shifts this could be a useful update to the GDAL tools.

Change History (4)

comment:1 by tcgeophysics, 11 years ago

A reply from Frank Warmerdam on a separate email was the following:

Thomas,

Have you by any chanced asked this on the gdal-dev or related mailing lists? I did a quick scan but didn't see anything from you there though it would likely be best to discuss this in a broader forum.

I skimmed the code and you can use the "nadgrids" extension node in WKT CRS descriptions to encode grid shift files to use. But that doesn't help if you want to use EPSG codes. I skimmed gdal/ogr/ogr_fromepsg.cpp and I don't see any support for grid shift files except for the special case for google mercator (which forces the use of the "null" grid shift file). I'm not sure if there is another mechanism I've built and forgotten or not.

I think that the way forward would be to support using grid shift files in addition to 3/7 parameter transformations in the gdal/data/datum_shift.csv and gdal/data/gcs.csv files. In fact it would be nice if there was a way of provide direct override WKT in these files (and their override versions - gcs.override.csv and pcs.override.csv). This is not a trivial change, and likely one that deserves a bit of broader discussion.

If you just need something you can hack in quickly, changing the gdal/ogr/ogr_fromepsg.cpp code to handle some EPSG codes specially would be a start but of course you would need to rebuild GDAL/OGR rather than using the stock binaries in OSGeo4W.

Feel free to quote my above text in any forum if you want to take the issue to the list(s).

Best regards, Frank

comment:2 by Jukka Rahkonen, 9 years ago

MapServer is using a user friendly system. It is reading the +Proj4 projection strings from a text file "epsg" and for changing +towgs84 parameters or pointing to use a grid shift file it is enough to edit the epsg file with a text editor.

comment:3 by Even Rouault, 9 years ago

Priority: highnormal

All those tickets have more than one year and nobody has acted on it, so the priority is not so high

comment:4 by Even Rouault, 5 years ago

Milestone: closed_because_of_github_migration
Resolution: wontfix
Status: newclosed

This ticket has been automatically closed because Trac is no longer used for GDAL bug tracking, since the project has migrated to GitHub. If you believe this ticket is still valid, you may file it to https://github.com/OSGeo/gdal/issues if it is not already reported there.

Note: See TracTickets for help on using tickets.