1

1) Whether I run a processing algorithm or just try to export to another CRS the layer is being output as a different CRS, eg. EPSG:102003 returns USER:100026. EPSG:102005 returns USER:100030

It is creating problems with the processing modeler and it's annoying to have to check every layer to see if the CRS has been maintained or changed.

the next issues are probably related to the first

2) Layers with the same CRS do not line up.

3) 102005 is projected sideways

enter image description here

enter image description here

All my data is in North America. I updated from 3.2 because of a bug in the raster calculator that caused it to fail in the processing modeler. I didn't have any CRS issues in 3.2.

  • What are your settings for the CRS of new layers? What version of QGIS were you using before? – csk Jan 28 at 20:33
  • I have a default setting 102003. I was using 3.2 – brink Jan 28 at 21:50
  • 2
    cs2cs -v +init=epsg:102003 returns Invalid projection system, but cs2cs -v +init=esri:102003 works fine. So, for proj that's an esri code, not an epsg code. – Gabriel De Luca Jan 29 at 3:57
  • 1
    There is no EPSG code 102003, I used epsg-registry.org to double check – nmtoken Jan 29 at 16:03
  • 1
    GDAL and PROJ handle the ESRI codes differently. While PROJ expects the esri: prefix, GDAL has them in the epsg: namespace. I don't know why. – AndreJ Jan 29 at 18:55
3

QGIS is not recognizing the AUTHORITY ["Esri", part of the .qpj file.

This is the content of the qpj file:

PROJCS["USA_Contiguous_Albers_Equal_Area_Conic",
    GEOGCS["GCS_North_American_1983",
        DATUM["North_American_Datum_1983",
        SPHEROID["GRS_1980",6378137.0,298.257222101]],
        PRIMEM["Greenwich",0.0],
        UNIT["Degree",0.0174532925199433]], 
    PROJECTION["Albers_Conic_Equal_Area"],
    PARAMETER["False_Easting",0.0],
    PARAMETER["False_Northing",0.0],
    PARAMETER["longitude_of_center",-96.0],
    PARAMETER["Standard_Parallel_1",29.5],
    PARAMETER["Standard_Parallel_2",45.5],
    PARAMETER["latitude_of_center",37.5],
    UNIT["Meter",1.0],
    AUTHORITY["Esri","102003"]]

I'm not sure if the mistake is made by writing it or reading it.
It may be well written and QGIS should read it like that.
But if it is changed by AUTHORITY["EPSG", QGIS reads it correctly and assigns the corresponding CRS to that layer.

Consequently, the projection is considered invalid (it would act in the same way if the qpj file did not exist) and creates a custom CRS by extracting the parameters from the prj file, and applies the custom CRS to the layer. I understand that this is the expected behavior for the projections provided by Esri.

If the layer was saved in a geopackage file, QGIS does not recognize the projection either, but acts according to the Settings > Options > CRS.

These behaviors were tested in OSGeo4W installations of qgis-3.4.4-2 and qgis-dev-3.5.0-76 packages.

A bug report was opened: https://issues.qgis.org/issues/21122

  • Well, damn. Do you know of a work around for this until it can get resolved? It's slowing down two of my projects right now – brink Jan 29 at 17:55
  • No. I do not think it was an update of QGIS that caused the inconvenience, but rather an update of GDAL/OGR that started writing the .qpj files in this way and QGIS is not yet adequate. The fault is also seen in QGIS 2.18. Do you have any layer of the ones produced previously to know how the .qpj file was written? – Gabriel De Luca Jan 29 at 18:11
  • Yes, several. How do I check the .qpj file? – brink Jan 29 at 18:17
  • It is in the same folder and with the same name that the .shp file. Open it with a text editor. – Gabriel De Luca Jan 29 at 18:21
  • Ha, I did not see it there. So on 2.18 it was coded as AUTHORITY["EPSG","102003"], 3.4.3 it's codes as AUTHORITY["Esri","102003"] I can't find any examples from 3.2. – brink Jan 29 at 18:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.