-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CRS of layers is not correctly read on 3.16.13 on Windows/Standalone #45939
Comments
@coefficient1900 can't confirm here, same QGIS and OS version. |
I tested it on a complete different windows machine which has never seen any QGIS before and used the standalone .msi installer for that. It occured the same issue. When loading a shape layer the CRS is not detected correctly. Here the result when I export the example layer from above with the version 3.16.13. When you look at the .prj you see that for wgs84 (EPSG: 4326) it is not set correctly. export.zip |
@gioman, @agiudiceandrea thanks for your replies. I tested it also on a virtual ubuntu machine and the layer loading behaves as expected, but the GDAL and PROJ version is not the same as on windows either. |
@coefficient1900 @agiudiceandrea confirmed on the standalone installer, but not the osgeo4w. Very worrying issue. |
Confirmed on Windows 10 with standalone installer (https://qgis.org/downloads/QGIS-OSGeo4W-3.16.13-1.msi). |
Same issue here with gpkg layers : default project CRS is assigned to layer, wether it is loaded by drag'n drop or through datasource manager. |
I have the same issue. QGIS 3.16.13 msi installer (proj 8.2.0) has the problem. There's strange thing. CRS code(? I don't know what its called) is different between QGIS 3.16.13 and 3.16.10. Here's QGIS 3.16.13(proj 8.2.0)'s EPSG 5174 code, which causes wrong projection. You'll see lots of "unknown".
Here's QGIS 3.16.10 (proj 8.1.0)'s EPSG 5174 code which is ok. There's no "unknown".
|
I have software which generates shapefiles and some of my users are reporting issues loading the shapefiles in QGIS too. For all of my CRS functionality I use proj6.1 and output my WKT in 2018 WKT2 format (PJ_WKT_TYPE::PJ_WKT2_2018); however QGIS does not seem to load the prj file. Using the ne_10m_populated_places_simple.shp uploaded in this issue I have tried using the WKT generated by proj6 using all formats (PJ_WKT1_ESRI, PJ_WKT1_GDAL, PJ_WKT2_2015, PJ_WKT2_2018) in the prj file, however none of these formats are loaded by QGIS. I am not sure how QGIS is loading the prj WKT, but in my own software all of these formats are identified by proj6 as WGS84 EPSG4326 with 100% confidence. My apologies for the following code not being C++, however I think it shows the proj6 API functions being called. First the CRS is created from the WKT and then a call is made to identify the CRS
I have tested this using proj6.1, proj7.2, proj8.0 and proj8.1 using the QGIS 3.16.13 proj.db and all of these correctly identify the WKT as WGS84 EPSG4326 with 100% confidence. Another test I have conducted is explicitly setting the ne_10m_populated_places_simple.shp CRS to WGS84 EPSG4326 after loading in QGIS and then exporting the shapefile features to a new shapefile. The new shapefile prj WKT is reported as : This WKT is only identified by proj6.1/proj7.2/proj8.0/proj8.1 as WGS84 EPSG4326 with 70% confidence. It should be noted that although this shapefile loads in QGIS, it is identified as an Unknown CRS |
@wfletcher made them downgrade to 3.16.11 standalone or install 3.16.13 with the network installer until this is not sorted out. |
I've confirmed this on my end too, it's a rather dramatically bad regression here. We likely need to remove 3.16.3 from qgis.org until we figure this one out. |
@nirvn this has been raised on both the developers and psc lists, with not much feedback (other than Nyall asking someone to tackle this) I'm afraid. |
Maybe postpone 3.16.14, which is scheduled next Friday (2021-11-19) if this issue is not resolved. Otherwise we would have three LTR releases in a row for the msi standalone installer which are having a concerning regression. As this issues appears only with QGIS 3.16.13 msi standalone installer and not with network installer, what are the possible causes for this regression?
|
At time on which the QGIS-OSGeo4W-3.16.13-1.msi was made available (05 Nov), the OSGeo4W v2 repository also shipped (via the Network Installer) the same GDAL 3.3.3 (3.3.3-2) package along with QGIS 3.16.13 (3.16.13-1). I'm using such version which doesn't suffers of the reported issue. |
Fixed according to https://trac.osgeo.org/osgeo4w/ticket/703 |
What is the bug or the crash?
When loading a shape layer (also valid for Geopackage) by drag-and-drop to the canvas of QGIS 3.16.13 the CRS of this layer is not recognized correctly and therefore canvas CRS is not adapted to the layer CRS.
Also the export results in 3.16.13 have incorrect CRS.
(tested with windows machines and new profiles)
Steps to reproduce the issue
Load any shape layer with a correct assigned CRS to the canvas.
(this is a shape example with CRS: EPSG 4326, which shows the mentioned behaviour (pictures are with another shape EPSG 25832):
ne_10m_populated_places_simple.zip
The project CRS will not change to layer CRS and the layer properties are empty for the CRS.
You also will not get a layer with a valid CRS when exporting something.
(The following picture shows 3.16.12 with the intended behaviour when loading a layer.)
![31612](https://user-images.githubusercontent.com/86417466/140758560-ff9edd6c-e9ed-46ee-809a-0fd1b7bf3689.PNG)
Versions
<style type="text/css"> p, li { white-space: pre-wrap; } </style>Supported QGIS version
New profile
Additional context
No response
The text was updated successfully, but these errors were encountered: