[Proj] Update of EPSG database to v8.4
even.rouault at mines-paris.org
Fri May 16 06:15:50 EST 2014
> Was this the only weirdness you found with your round-tripping check?
Yes, it was the only one.
> > Should we add an override to correct it to D_Peru96 ?
> I am not sure; maybe Melita Kennedy should answer that.
Is she someone at ESRI ?
> 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
> 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.
Actually, I had to implement a hack in the GDAL morphFromESRI() so that if the
GCS/PCS name contains "Peru96", the line with SIRGAS-Chile is skipped when
resolving the DATUM name...
Anyway, I agree it's likely an error in the FileGDB SDK, and it is better that
we had an override in the generation script to fix gdal_datum.csv to report
> Mikael Rittri
More information about the Proj