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@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.roua...@spatialys.com> > <even.roua...@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.me...@nasa.gov> <jesse.r.me...@nasa.gov>, > "gdal-dev@lists.osgeo.org" <gdal-dev@lists.osgeo.org> > <gdal-dev@lists.osgeo.org> <gdal-dev@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@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@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev >
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev