Michael Barton wrote:
Thanks for the information Paul,
This is directly a g.proj problem rather than a proj4 problem per se--although
I don't know how g.proj uses proj4. So it may be indirectly something to do
with proj4 too.
g.proj does not use PROJ.4 for importing projection definitions at all.
All the PROJ.4 and WKT string parsing is done by calls to GDAL functions.
I do know that this USED to work fine. That is, eur50 (and all other datums
recognized by GRASSS) was recognized by g.proj and spawned a datum transforms
list. The datums list and datum transforms list files that g.proj uses (or used
to use) are the ones maintained by the GRASS project, not the official ones of
proj4.
Hmmm, I really can't see any way it can have ever worked. It certainly
isn't how it was supposed to work when it was originally written,
although I'm not sure if anybody has changed anything in the meantime.
The way g.proj knows which datum transformations to include in the list
that it spawns is by checking the official EPSG name of the datum. This
is included as the second field in the GRASS datum.table, and is matched
up against the EPSG name passed back from GDAL if a co-ordinate system
is specified using a WKT description, georeferenced file or an EPSG code.
But when specifying a co-ordinate system using a GRASS-style datum name
in a PROJ.4 string the official EPSG name for the datum is not
available, since GDAL (which g.proj uses to parse the PROJ.4 string)
knows nothing of the GRASS datum names.
> As I said, this is causing incorrect location projections and is thus
quite serious.
Where are the incorrect PROJ.4 strings with GRASS datum names in them
being generated? I think that is worth sorting out, since as I said it's
not a good idea to be circulating PROJ.4 strings with non-standard datum
names that won't work with other GIS.
So there has been some kind of change in the way g.proj, proj4, and the various
GRASS projection files interact.
If you can come up with a combination of GRASS and GDAL versions that
result in this behaviour (i.e. g.proj accepts GRASS datum names for the
+datum option in a PROJ.4 string) then I promise to look into it and debug.
Paul
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
