Re: [gdal-dev] Inconsistencies in WKT CRS representations

https://crs-explorer.proj.org/ is using pyproj to generate all the information, based on the last version of PROJ In particular, your CRS is here: https://crs-explorer.proj.org/?searchText=102022&ignoreWorld=false&allowDeprecated=false&authorities=EPSG,ESRI&activeTypes=PROJECTED_CRS You have link

Re: [gdal-dev] Inconsistencies in WKT CRS representations

Jennifer, Note that the projection parameters are all the same (but with slightly different naming conventions), but the CRS AUTHORITY line does not exist in the GDAL version, is EPSG 102022 in the spatialreference.org version, and is ESRI 102022 in the epsg.io version. you must use an outda

Re: [gdal-dev] Inconsistencies in WKT CRS representations

> On Aug 16, 2023, at 10:59 AM, Small, Jennifer L. (GSFC-618.0)[SCIENCE SYSTEMS > AND APPLICATIONS INC] via gdal-dev wrote: > > Is it best to represent the CRS with WKT rather than importing using > SetFromUserInput with EPSG:code or ESRI:code? If so, what source has the > definitive WKT, s

[gdal-dev] Inconsistencies in WKT CRS representations

I’m noticing subtle differences between the WKT representations for a given projection when consulting spatialreference.org, epsg.io, and the output from gdalinfo on an orthorectified raster. For example, for Africa Albers (ESRI code 102022): 1) gdalinfo output for a raster, CRS set with “SetFr