[Proj] Update of EPSG database to v8.4

[Mikael Rittri]

Even wrote: 

-----Original Message-----
From: Even Rouault [mailto:even.rouault at mines-paris.org] 
Sent: Thursday, May 15, 2014 7:48 PM
To: Mikael Rittri
Cc: PROJ.4 and general Projections Discussions
Subject: Re: [Proj] Update of EPSG database to v8.4

Le jeudi 15 mai 2014 15:13:17, Mikael Rittri a écrit :
> Dear Even,
> 
> Thanks for your e-mail and your efforts. A gdal_datum.csv for the latest
> EPSG version is very useful to me. So I downloaded it from the GDAL trunk,
> but I found an issue.
> 
> Line 46 is:
> 
> 1067,Peru96,geodetic,"ITRF94 at epoch 1995.4.  Densification of SIRGAS95
> network in Peru, consisting of 47 passive geodetic stations and 3
> continuous recording GPS stations.",1996,7019,8901,1189,Geodetic
> survey.,"Densification of SIRGAS 1995 within Peru. Replaces PSAD56 (datum
> code 6248) in Peru.","Details taken from national realizations page of
> WWW.SIRGAS.ORG, confirmed by reports from IGN
> Peru.",OGP,"2011/03/20",2011.018,0,"D_SIRGAS-Chile"
> 
> Where the last entry, "D_SIRGAS-Chile", seems to be wrong. On the page
> 
> http://resources.arcgis.com/en/help/arcgis-rest-api/index.html#//02r3000001
> 05000000
> 
> I found the entry
> 
> 5373
> GCS_Peru96
> GEOGCS["GCS_Peru96",DATUM["D_Peru96",SPHEROID["GRS_1980",6378137.0,298.2572
> 22101]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]]
> 
> and I interpret this as saying that the ESRI name for the datum of
> EPSG:5373 is "D_Peru96", not "D_SIRGAS-Chile".
> 
> (A check with www.epsg-registry.org confirms that the GeogCRS with code
> EPSG:5373 is named Peru96 and has a datum with code 1067 that is also
> named Peru96.)
> 
> Maybe the new version of add_esri_column.py can be blamed for this? I
> haven't checked whether the error occurs in previous versions of
> gdal_datum.csv.

Michael,

I found this weirdness too with a round-tripping check in GDAL. But this 
value, as all others, come from the database embedded within the ESRI FileGDB 
SDK. Basically, for each GCS, I create a FileGDB layer with a fake WKT that 
has just the EPSG code, and the FileGDB SDK replaces it with its ESRIfied 
version of WKT, that I fetch back to get the ESRI DATUM name. So the error, if 
it is an error, would be in the FileGDB SDK.

Should we add an override to correct it to D_Peru96 ?

Even

-- 
Geospatial professional services
http://even.rouault.free.fr/services.html

-----End Original Message-----


Was this the only weirdness you found with your round-tripping check?

> Should we add an override to correct it to D_Peru96 ?

I am not sure; maybe Melita Kennedy should answer that.
I suppose one could argue that to be ESRI-compatible,
the entry should stay as it is. 

But I reason like this: in your current gdal_datum.csv,
you have the lines 

    1064,SIRGAS-Chile, ...,D_SIRGAS-Chile
    ...
    1067,Peru96, ...,D_SIRGAS-Chile

I could be wrong, but I think that if GDAL/OGR has
to interpret an ESRI WKT definition containing the
datum name D_SIRGAS-Chile, it would search the 
ESRI_DATUM_NAME column from top to bottom, and 
find the 

    1064,SIRGAS-Chile,... 

line first, so the 

    1067,Peru96,... 

line would never be found. So I don't see that there 
would be any advantage in keeping the error. So if I
were you, I would correct it, anticipating that the
FileGDB SDK will be corrected sooner or later.

Mikael Rittri
Carmenta
Sweden
http://www.carmenta.com