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

Fri Jan 12 08:52:00 PST 2024

In the DK registry we used descriptive names, rather than numbers to refer
to the transformations taking legacy systems to ETRS89. Essentially these
transformations amounted to CRS definitions. Is it safe to assume a
"crs_code" is strictly numeric?

Den ons. 10. jan. 2024 kl. 20.46 skrev Meyer, Jesse R. (GSFC-618.0)[SCIENCE
SYSTEMS AND APPLICATIONS INC] via gdal-dev <gdal-dev at lists.osgeo.org>:

> To be clear, I wasn’t advocating for less functionality.  I wanted more!
> We know what our constraints are, and we’ve had significant issues in the
> past with slightly different projection related strings producing
> surprisingly different outputs.  Keying off a single value simplifies a
> tremendous amount for us, with a slight loss in generality and increase in
> error modes.
>
>
>
> For now, the logic resembles:
>
> Crs_string = “EPSG:{crs_code}”
>
> If crs_code > 32767:
>
>     Crs_string = “ESRI:{crs_code}”
>
>
>
> SetFromUserInput(crs_string)
>
>
>
> The lack of such a function implied that there were overloaded values
> between the authorities (and perhaps, there were more than 2).
>
>
>
> Jesse
>
>
>
> *From: *Javier Jimenez Shaw <j1 at jimenezshaw.com>
> *Date: *Wednesday, January 10, 2024 at 1:55 PM
> *To: *Even Rouault <even.rouault at spatialys.com>
> *Cc: *"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: *Re: [gdal-dev] [EXTERNAL] Re: 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.
>
>
>
> 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
>
> _______________________________________________
> 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/20240112/ab6e019a/attachment.htm>