[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 trac at osgeo.org
Tue Jan 24 18:49:44 EST 2012

#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 '

         SPHEROID["GRS 1980",6378137,298.257222101,

 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) :

 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
 12,1946,4617,4326,"Jointly derived by US NGS and Geodetic Survey of Canada
 - see also code 1901. Strictly between NAD83(CSRS) and

 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

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

More information about the grass-dev mailing list