Update ESRI extras

[don-vip]

Hello,
We reuse the esri extra projection codes from proj.4 and found out D48_Slovenia_TM (102060) is missing.
It is defined in GDAL:
https://github.com/OSGeo/gdal/blob/master/gdal/data/esri_extra.wkt
And comes from this repository:
https://github.com/Esri/projection-engine-db-doc/blob/master/proj4/esri

[kbevers]

So what do you propose exactly? That we update nad/esri with the file from Esri you've linked to? Or do you want to replace nad/esri.extra?

[don-vip]

Hi Kristian,
I'm not sure exactly, my knowledge of proj.4 is limited.
What exactly is the difference between esri and esri.extra? I guess my ticket is misleading and in fact I would like an update of the main esri file (this is the one we use in reality, sorry for the mistake).
Is there some documentation about how you update these files? I would be happy to submit a PR.
Vincent

[kbevers]

Is there some documentation about how you update these files?

No. It's not like we do this every other day. Ideally the Esri guys would start by updating their file to include the <metadata> similar to what's in the epsg file. That would make it a lot easier to keep the files in PROJ aligned with the upstream files at Esri.

[don-vip]

OK thanks. When I look at the first entry in proj.4 nad/esri file, I don't understand. The code 2000 (Anguilla 1957) is defined in EPSG 9.2 (I can find it in both online registry and PostgreSQL downloadable dataset. I can't find it in ESRI database.
Yet it is defined here both in nad/esri and nad/epsg, do you know why?

[kbevers]

No, I don't. It was added long before I started working on PROJ. You might get better answers on the mailing list.

Note that the esri file hasn't been updated in ages.

[don-vip]

OK, thanks (sorry for all these questions!). I found out through GDAL and GeoTiff how the nad/espg file is built, I'm going to play a little bit with the script to understand what needs to be done.

[don-vip]

From what I understand, the esri file contains a lot of duplicate entries (2484 to be exact) with the standard EPSG database. But as only EPSG file has been maintained in the last 10 years, some of these duplicate entries have diverged. We can assume the correct ones are those maintained in the EPSG file.

The ESRI file had a long-standing licensing issue described here.
ESRI has since released its database in Apache 2.0 license and releases them in various formats. I guess we can simply replace nad/esri and nad/esri.extra by this file, like GDAL did a few weeks ago.

Would you accept such a PR?

[kbevers]

@rouault You probably know more about this stuff than I. Are there any problems in removing nad/esri.extra?

Would you accept such a PR?

Granted @rouault doesn't have a problem with this, yes. And especially if you add the <metadata> information to the top of the file so we can better keep track of the changes.

[rouault]

I'm not clear how the nad/esri and nad/esri.extra files have been generated. Perhaps by running some modified scripts of GDAL's epsg_tr.py
One thing I can see in the new ESRI files is that they have nadgrids= parameters, so this mean that users will have to have the pointed grids available.

[kbevers]

One thing I can see in the new ESRI files is that they have nadgrids= parameters, so this mean that users will have to have the pointed grids available.

Good point. And there is a lot of different grids mentioned, several which are not covered by our datumgrid packages. Perhaps it is better remove the Esri files here and instead include the updated esri file in an updated version of proj-datumgrid and clearly document in the README that some additional grids may be required for certain transformations?

It would also be a nice step in the right direction with regards to separating resource files from the code.

[kbevers]

We have removed esri and esri.extra in favour of the new database. Closing this as the issue isn't valid anymore.