[Proj] Update of EPSG database to v8.4

[Even Rouault]

> 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
>
>     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.

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
D_Peru96.

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