[Proj] Update of EPSG database to v8.4
even.rouault at mines-paris.org
Thu May 15 12:47:57 EST 2014
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
More information about the Proj