[Proj] Update of EPSG database to v8.4
Mikael.Rittri at carmenta.com
Fri May 16 02:32:52 EST 2014
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
> Where the last entry, "D_SIRGAS-Chile", seems to be wrong. On the page
> I found the entry
> 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
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 ?
Geospatial professional services
-----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
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
line first, so the
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.
More information about the Proj