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

[Even Rouault]

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>
> *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>, "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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20240110/7e4bb288/attachment.htm>