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

[Michael Barton]

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.

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. 

So there has been some kind of change in the way g.proj, proj4, and the various GRASS projection files interact.

As I said, this is causing incorrect location projections and is thus quite serious.

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 6:19 AM, Paul Kelly <paul-grass at stjohnspoint.co.uk>
 wrote:

> Hello all,
> Markus has prompted me to try and give some insight into what is going on here, which I will gladly try to do:
> 
> Michael Barton wrote:
>> Markus,
>> 
>> It looks like some datums are not being recognized by g.proj. When this
>> happens, datum transform information is not returned. Take a look at this.
>> 
>> wgs84 is recognized by g.proj
>> 
>> GRASS 7.0.svn (newLocation):~ > g.proj -d proj4='+proj=utm +datum=wgs84'
>> GRASS datum code: wgs84
>> WKT Name: WGS_1984
>> Datum transformation parameters (PROJ.4 format):
>> towgs84=0,0,0,0,0,0,0
>> 
>> 
>> but European Datum 1995 (eur50) is not recognized. This datum IS listed
>> in ../etc/proj/datums.table
> 
> As far as I can think, the problem here is that +datum=eur50 is not a PROJ.4-compatible datum name. The only hard-coded datum names supported in PROJ.4 strings are those output by the "proj -ld" command, i.e. WGS84, GGRS87, NAD83, NAD27, potsdam, carthage, hermannskogel, ire65, nzgd49 and OSB36.
> 
> The string used for the proj4= option in g.proj needs to be compatible with any installation of PROJ.4, so it can't include GRASS-specific datum names such as eur50 and the others in the GRASS datum.table file. Internally to g.proj, the string from the proj4= option is actually parsed by GDAL (using its OSRImportFromProj4() function) - and GDAL is not aware of the internal GRASS datum names so this is the result:
> 
>> GRASS 7.0.svn (newLocation):~ > g.proj -d proj4='+proj=utm +datum=eur50'
>> WARNING: Datum <unknown> not recognised by GRASS and no parameters found
>> Datum name not present
>> Datum parameters not present
> 
> I am slightly confused though, as to why +datum=wgs84 works fine - because the GDAL name is WGS84, i.e. in capitals. The GRASS version is wgs84 (i.e. lower case), so this shouldn't work either - but maybe GDAL is doing a case-insensitive comparison somewhere.
> 
> I am very out-of-touch with GRASS development and know very little about the new location wizard, but I wonder if it handles PROJ-4 strings differently and parses them itself, allowing GRASS-specific datum names for the +datum option, and if this is leading to some confusion?
> 
> For compatibility with other applications, I think it's best not to use GRASS-specific datum names in PROJ.4 strings as they won't be valid if the PROJ.4 string is exported for use with another GIS application.
> 
> Hope this sheds some light on things.
> 
> Paul