[GRASS-dev] datums not recognized by g.proj?

[Michael Barton]

Paul,

See below.

Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity 
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University

voice: 	480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax:          480-965-7671 (SHESC),  480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu



On Sep 30, 2012, at 11:29 AM, Paul Kelly <paul-grass at stjohnspoint.co.uk>
 wrote:

> 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 the only way to *find* the second field in datum.table is by searching on the first field. So either there is something wrong with the search (e.g., it won't search on "eur50" for some reason) or the 2nd field is wrong (e.g., "European_Datum_1950"). 

Moreover, the corresponding entries in datum_transform.table match the first field in datum.table. That is, there are entries in datum_transform.table with a first field of "eur50", the same as the entry in datum.table. So again, I don't see how the correct datum transforms can even be found if "eur50" is not recognized by g.proj. 


> 
> 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.

So what is the purpose of datum.table and datum_transform.table?

> 
> > 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.

The only way to generate a proj4 string interactively is to pick the appropriate values from a table. When g.proj was still an interactive terminal module, running it would bring up the lists from these tables to generate a proper projection. If all the data tables in ../etc/proj are wrong and are not used for anything anymore, we need to get rid of them and replace them with something that works. A nice, clean set of 4 csv files that includes all relevant data (projections, datums, datum transforms, ellipsoids) would be much easier to parse. The stuff currently in ../etc/proj is currently a real mishmash and difficult to parse.

> 
>> 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.

The problem is that it no longer works this way, apparently making it impossible to generate a correct projection based on the information that comes with GRASS.

Michael

> 
> Paul