[gdal-dev] [EXTERNAL] Re: Lack of srs importFromESRI integer function

[Javier Jimenez Shaw]

This is the discussion I have with my colleagues every time (but with
EPSG). The wanted to use an integer, and I ask them again and again to use
a better notation like "EPSG:{code}". The method that Even mentions,
SetFromUserInput, works with "EPSG:code", with "ESRI:code", with a WKT,
with a PROJJSON, etc. It makes the management of the CRS much easier. When
you need something more complicated than an ESRI code, if your API is only
ready for an integer value... you have a lot of things to refactor (months
of work, I can tell you).

Technically ESRI and EPSG there are overlapping. As you can see in this
link there are some non-deprecated ESRI codes below 33000:
https://crs-explorer.proj.org/?ignoreWorld=false&allowDeprecated=false&authorities=ESRI&activeTypes=PROJECTED_CRS,GEOGRAPHIC_2D_CRS,GEOGRAPHIC_3D_CRS,GEOCENTRIC_CRS,GEODETIC_CRS,VERTICAL_CRS,COMPOUND_CRS&map=osm

And many more if you "Allow deprecated".

On Wed, 10 Jan 2024 at 19:01, Even Rouault via gdal-dev <
gdal-dev at lists.osgeo.org> wrote:

>
> Le 10/01/2024 à 18:52, Meyer, Jesse R. (GSFC-618.0)[SCIENCE SYSTEMS AND
> APPLICATIONS INC] a écrit :
>
> Thanks Even, we’ll try that.
>
>
>
> Are there any known integer values that ESRI and EPSG conflate?  If not,
> it would be convenient to simply pass in an integer to a single API
> function and be done with it.
>
> I believe not. Codes in the [1,32767] range should lead to equivalent
> definitions under both authorities. But when they are really the same, to
> save space and confusion to users, they are not imported under the ESRI
> authority and are only available under the EPSG ones. So codes in the
> [1,32767] under the ESRI authorities are basically for CRS names that are
> slightly different spelled by ESRI (but otherwise with a definition
> compatible of the EPSG one). There are also very ancient deprecated CRS
> that were imported from EPSG, but were deprecated by EPSG so long ago that
> they are not in the EPSG database anymore (like
> https://spatialreference.org/ref/esri/31491/).
>
> But there's no only EPSG and ESRI in life :-) The IAU authority for
> example uses numeric code in the ranges of what could be used by EPSG or
> ESRI.
>
> So it is really the tuple (authority_name,code) that conveys a primary key.
>
>
>
> Jesse
>
>
>
> *From: *Even Rouault <even.rouault at spatialys.com>
> <even.rouault at spatialys.com>
> *Date: *Wednesday, January 10, 2024 at 12:48 PM
> *To: *"Meyer, Jesse R. (GSFC-618.0)[SCIENCE SYSTEMS AND APPLICATIONS
> INC]" <jesse.r.meyer at nasa.gov> <jesse.r.meyer at nasa.gov>,
> "gdal-dev at lists.osgeo.org" <gdal-dev at lists.osgeo.org>
> <gdal-dev at lists.osgeo.org> <gdal-dev at lists.osgeo.org>
> *Subject: *[EXTERNAL] Re: [gdal-dev] Lack of srs importFromESRI integer
> function
>
>
>
> *CAUTION:* This email originated from outside of NASA.  Please take care
> when clicking links or opening attachments.  Use the "Report Message"
> button to report suspicious messages to the NASA SOC.
>
>
>
> Jesse,
>
> You can use SetFromUserInput("ESRI:XXXX")  . ImportFromEPSG(code) more or
> less does SetFromUserInput("EPSG:{code}")
>
> Even
>
> Le 10/01/2024 à 18:44, Meyer, Jesse R. (GSFC-618.0)[SCIENCE SYSTEMS AND
> APPLICATIONS INC] via gdal-dev a écrit :
>
> Hi,
>
>
>
> Our team has moved away from providing geographic / projected CRS codes as
> strings and prefer using integers where possible.  However, in the C++ API,
> I only see an integer based importFromEPSG function, which doesn’t appear
> to accept ESRI codes (crs not found error message).  We’re targeting an
> Albers projection which is distinguished by an ESRI integer.
>
>
>
> Curiously, the proj database doesn’t seem to make this distinction – the
> table column is simply ‘code’ and I can find the projection row manually,
> alongside EPSG projections.
>
>
>
> Can such a function be provided by the API (if it doesn’t already exist –
> I couldn’t find it – there are no integer overloads of importFromESRI)?
>
>
>
> Please advise -- thanks,
>
> Jesse
>
>
>
> _______________________________________________
>
> gdal-dev mailing list
>
> gdal-dev at lists.osgeo.org
>
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
> --
>
> http://www.spatialys.com
>
> My software is free, but my time generally not.
>
> -- http://www.spatialys.com
> My software is free, but my time generally not.
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20240110/53952fea/attachment.htm>