[GRASS-dev] Re: [GRASS GIS] #1452: wx location wizard doesn't ask for datum transform options because proj4 4.7.1's epsg file is broken

[GRASS GIS]

#1452: wx location wizard doesn't ask for datum transform options because proj4
4.7.1's epsg file is broken
-------------------------------------+--------------------------------------
 Reporter:  hamish                   |       Owner:  grass-dev@…              
     Type:  defect                   |      Status:  new                      
 Priority:  critical                 |   Milestone:  6.4.2                    
Component:  Projections/Datums       |     Version:  svn-releasebranch64      
 Keywords:  location wizard, g.proj  |    Platform:  All                      
      Cpu:  All                      |  
-------------------------------------+--------------------------------------

Comment(by rouault):

 I've discussed this issue with FrankW recently, and our conclusion was
 that, ideally, GRASS shouldn't rely on proj4 to determine whether it
 should offer a choice of alternative datum shift transforms to the user.

 Some historical background : the choice of including or not +datum in the
 proj4 string when TOWGS84 is available in EPSG database was last changed
 in http://trac.osgeo.org/gdal/ticket/3450. The idea was that the hard-
 coded transform in proj4' pj_datums.c could lag behind the
 suggested/preferred +towgs84 of EPSG, hence using +towgs84 from latest
 EPSG update was preferable.

 But, even if that changeset never existed and +datum was still there, I'd
 note that proj4 only knows just a handful of datum names, which is far
 from being comprehensive.

 A better starting point for GRASS would be to start with the EPSG code
 itself and then examine the gcs.csv and datum_shift.csv files you can find
 in gdal/data (and libgeotiff AFAIR).

 Practical case : let's take the case of EPSG:4617.

 "gdalsrsinfo EPSG:4617" output (as of GDAL 1.9.0) is :

 {{{
 PROJ.4 : '+proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs '

 OGC WKT :
 GEOGCS["NAD83(CSRS)",
     DATUM["NAD83_Canadian_Spatial_Reference_System",
         SPHEROID["GRS 1980",6378137,298.257222101,
             AUTHORITY["EPSG","7019"]],
         TOWGS84[0,0,0,0,0,0,0],
         AUTHORITY["EPSG","6140"]],
     PRIMEM["Greenwich",0,
         AUTHORITY["EPSG","8901"]],
     UNIT["degree",0.0174532925199433,
         AUTHORITY["EPSG","9122"]],
     AUTHORITY["EPSG","4617"]]
 }}}

 The 'NAD83_Canadian_Spatial_Reference_System' datum isn't know by
 GDAL/proj4, so I'm pretty sure than even in old versions of the proj4
 'epsg' file, you have never had any +datum in the expansion of EPSG:4617

 But now let's have a look at datum_shift.csv (from GDAL 1.9.0) :

 {{{
 "SEQ_KEY","COORD_OP_CODE","SOURCE_CRS_CODE","TARGET_CRS_CODE","REMARKS","COORD_OP_SCOPE","AREA_OF_USE_CODE","AREA_SOUTH_BOUND_LAT","AREA_NORTH_BOUND_LAT","AREA_WEST_BOUND_LON","AREA_EAST_BOUND_LON","SHOW_OPERATION","DEPRECATED","COORD_OP_METHOD_CODE","DX","DY","DZ","RX","RY","RZ","DS","PREFERRED"
 11,1842,4617,4326,"For many purposes NAD83(CSRS) can be considered to be
 coincident with WGS 84.","Approximation at the +/- 1m level assuming that
 NAD83(CSRS) is equivalent to WGS
 84.",1061,40.04,86.45,-141,-47.74,1,0,9603,0,0,0,,,,,1
 12,1946,4617,4326,"Jointly derived by US NGS and Geodetic Survey of Canada
 - see also code 1901. Strictly between NAD83(CSRS) and
 ITRF96(1997.0).",Geodesy.,1061,40.04,86.45,-141,-47.74,1,0,9607,-0.991,1.9072,0.5129,-0.0257899075194932,-0.0096500989602704,-0.0116599432323421,0,0
 }}}

 Bingo, we can see that there are 2 possible transformations. The scripts
 regenerating GDAL/libgeotiff data files picked up the first one ( the line
 such that PREFERRED = 1), but there's another one available...

 (I'd note that in the case of EPSG:4230 (ED50), there seems to have no
 advertized preferred shift. And apparently the script pick up the one of
 the first line with SOURCE_CRS_CODE=4230)

 Ideally, there should be an API (in GDAL's OSR probably ?) to suggest
 alternative towgs84 transforms given a GCS code. But that's perhaps
 something that could also be done by GRASS itself by parsing
 datum_shift.csv ?

 My summary of this whole issue could be : proj4 strings don't contain as
 much information as in a EPSG code and/or its WKT expansion, and should
 not be used for any other purpose than using proj4 to do coordinate
 transforms.

-- 
Ticket URL: <https://trac.osgeo.org/grass/ticket/1452#comment:13>
GRASS GIS <http://grass.osgeo.org>