#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>
I can successfully reproject data