Geographic Information Systems Asked by Henry Rodman on January 22, 2021
I recently noticed that all vector and raster files with CRS EPSG:2163 (US National Atlas Equal Area) are being automatically reinterpreted as EPSG:9311. When I load the layers into QGIS initially they are not properly projected, so I must manually update the CRS to EPSG:2163 in QGIS and everything is fine. This is a huge pain so I would like to understand if there are any solutions that don’t involve manually setting the projection in QGIS!
Running projinfo suggests that EPSG:9311 is somehow a preferred option to EPSG:2163:
>projinfo "EPSG:2163"
Warning: object is deprecated
Alternative non-deprecated CRS:
EPSG:9311
PROJ.4 string:
+proj=laea +lat_0=45 +lon_0=-100 +x_0=0 +y_0=0 +ellps=sphere +units=m +no_defs +type=crs
WKT2:2019 string:
PROJCRS["US National Atlas Equal Area",
BASEGEOGCRS["Unspecified datum based upon the Clarke 1866 Authalic Sphere",
DATUM["Not specified (based on Clarke 1866 Authalic Sphere)",
ELLIPSOID["Clarke 1866 Authalic Sphere",6370997,0,
LENGTHUNIT["metre",1]]],
PRIMEM["Greenwich",0,
ANGLEUNIT["degree",0.0174532925199433]],
ID["EPSG",4052]],
CONVERSION["US National Atlas Equal Area",
METHOD["Lambert Azimuthal Equal Area (Spherical)",
ID["EPSG",1027]],
PARAMETER["Latitude of natural origin",45,
ANGLEUNIT["degree",0.0174532925199433],
ID["EPSG",8801]],
PARAMETER["Longitude of natural origin",-100,
ANGLEUNIT["degree",0.0174532925199433],
ID["EPSG",8802]],
PARAMETER["False easting",0,
LENGTHUNIT["metre",1],
ID["EPSG",8806]],
PARAMETER["False northing",0,
LENGTHUNIT["metre",1],
ID["EPSG",8807]]],
CS[Cartesian,2],
AXIS["easting (X)",east,
ORDER[1],
LENGTHUNIT["metre",1]],
AXIS["northing (Y)",north,
ORDER[2],
LENGTHUNIT["metre",1]],
USAGE[
SCOPE["unknown"],
AREA["USA"],
BBOX[15.56,167.65,74.71,-65.69]],
ID["EPSG",2163]]
I am running QGIS 3.14.16-Pi with GDAL 3.1.3 and PROJ 7.1.1 on Ubuntu 20.04
When I run gdalinfo on one of my rasters I get this output that suggests GDAL is interpreting the CRS as EPSG:9311
Coordinate System is:
PROJCRS["NAD27 / US National Atlas Equal Area",
BASEGEOGCRS["NAD27",
DATUM["North American Datum 1927",
ELLIPSOID["Clarke 1866",6378206.4,294.978698213898,
LENGTHUNIT["metre",1]]],
PRIMEM["Greenwich",0,
ANGLEUNIT["degree",0.0174532925199433]],
ID["EPSG",4267]],
CONVERSION["US National Atlas Equal Area",
METHOD["Lambert Azimuthal Equal Area (Spherical)",
ID["EPSG",1027]],
PARAMETER["Latitude of natural origin",45,
ANGLEUNIT["degree",0.0174532925199433],
ID["EPSG",8801]],
PARAMETER["Longitude of natural origin",-100,
ANGLEUNIT["degree",0.0174532925199433],
ID["EPSG",8802]],
PARAMETER["False easting",0,
LENGTHUNIT["metre",1],
ID["EPSG",8806]],
PARAMETER["False northing",0,
LENGTHUNIT["metre",1],
ID["EPSG",8807]]],
CS[Cartesian,2],
AXIS["easting (X)",east,
ORDER[1],
LENGTHUNIT["metre",1]],
AXIS["northing (Y)",north,
ORDER[2],
LENGTHUNIT["metre",1]],
USAGE[
SCOPE["unknown"],
AREA["USA"],
BBOX[15.56,167.65,74.71,-65.69]],
ID["EPSG",9311]]
Is the automatic re-assignment from a deprecated EPSG code expected behavior?
When I run gdalinfo on the same file but in a different environment with older versions of GDAL (3.0.4) and PROJ (7.0.0), I get the expected result:
Coordinate System is:
PROJCRS["US National Atlas Equal Area",
BASEGEOGCRS["Unspecified datum based upon the Clarke 1866 Authalic Sphere",
DATUM["Not specified (based on Clarke 1866 Authalic Sphere)",
ELLIPSOID["Clarke 1866 Authalic Sphere",6370997,0,
LENGTHUNIT["metre",1]]],
PRIMEM["Greenwich",0,
ANGLEUNIT["degree",0.0174532925199433]],
ID["EPSG",4052]],
CONVERSION["US National Atlas Equal Area",
METHOD["Lambert Azimuthal Equal Area (Spherical)",
ID["EPSG",1027]],
PARAMETER["Latitude of natural origin",45,
ANGLEUNIT["degree",0.0174532925199433],
ID["EPSG",8801]],
PARAMETER["Longitude of natural origin",-100,
ANGLEUNIT["degree",0.0174532925199433],
ID["EPSG",8802]],
PARAMETER["False easting",0,
LENGTHUNIT["metre",1],
ID["EPSG",8806]],
PARAMETER["False northing",0,
LENGTHUNIT["metre",1],
ID["EPSG",8807]]],
CS[Cartesian,2],
AXIS["easting (X)",east,
ORDER[1],
LENGTHUNIT["metre",1]],
AXIS["northing (Y)",north,
ORDER[2],
LENGTHUNIT["metre",1]],
USAGE[
SCOPE["unknown"],
AREA["USA"],
BBOX[15.56,167.65,74.71,-65.69]],
ID["EPSG",2163]]
As far as I can tell the only difference between the two CRS’ is the datum:
Does anyone know what GDAL and PROJ do with the deprecated CRS warning? Or why the files would be automatically re-interpreted with a different CRS?
While it appears that there are deeper problems lurking with EPSG:2163, it is possible to prevent the automatic re-assignment of the CRS by setting the environment variable OSR_USE_NON_DEPRECATED
to NO
in the startup script:
add this line to ~/.bashrc:
export OSR_USE_NON_DEPRECATED=NO
GDAL (and therefore QGIS) will respect this setting and allow you to load layers projected in a deprecated CRS!
Full response from Even Rouault on the PROJ user mailing list on November 5, 2020:
"As far as I remember regarding the deprecation of EPSG:2163, I noticed in a recent EPSG release that the underlying datum of EPSG:2163 which is EPSG:4052 "Unspecified datum based upon the Clarke 1866 Authalic Sphere" was now deprecated, but EPSG:2163 was still non-deprecated, which isn't very logical. IOGP conclusion was that EPSG:2163 had to be deprecated, and they created EPSG:9311 as the future proof CRS.
The automated substitution is done by GDAL OGRSpatialReference::ImportFromEPSG() method. I admit this may be a bit surprising. If I remember well, this was to emulate a past GDAL behaviour where some deprecated Italian CRS had an override in the .csv files GDAL handled to "fix" it to have an equivalent definition of the non-deprecated newer CRS. The cleanest way with the now PROJ mechanism was to identify the non-deprecated version of a deprecated CRS instead, but I can see this is not always desirable.
You can opt out for that automatic substituion by setting the OSR_USE_NON_DEPRECATED environment variable to NO"
Correct answer by Henry Rodman on January 22, 2021
Get help from others!
Recent Answers
Recent Questions
© 2024 TransWikia.com. All rights reserved. Sites we Love: PCI Database, UKBizDB, Menu Kuliner, Sharing RPP