CRS of layers is not correctly read on 3.16.13 on Windows/Standalone

[coefficient1900]

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.)

Versions

<style type="text/css"> p, li { white-space: pre-wrap; } </style>

QGIS version	3.16.13-Hannover	QGIS code revision	a8618a9
Compiled against Qt	5.15.2	Running against Qt	5.15.2
Compiled against GDAL/OGR	3.3.3	Running against GDAL/OGR	3.3.3
Compiled against GEOS	3.10.0-CAPI-1.16.0	Running against GEOS	3.10.0-CAPI-1.16.0
Compiled against SQLite	3.35.2	Running against SQLite	3.35.2
PostgreSQL Client Version	13.0	SpatiaLite Version	5.0.1
QWT Version	6.1.3	QScintilla2 Version	2.11.5
Compiled against PROJ	8.2.0	Running against PROJ	Rel. 8.2.0, November 1st, 2021
OS Version	Windows 10 Version 2009
Active python plugins	db_manager; MetaSearch; processing

Supported QGIS version

• I'm running a supported QGIS version according to the roadmap.

New profile

• I tried with a new QGIS profile

Additional context

No response

[gioman]

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)

@coefficient1900 can't confirm here, same QGIS and OS version.

[agiudiceandrea]

I cannot confirm using the OSGeo4W v2 Network Installer on Windows 10

[coefficient1900]

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

[coefficient1900]

@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.

[gioman]

@coefficient1900 @agiudiceandrea confirmed on the standalone installer, but not the osgeo4w. Very worrying issue.

[pathmapper]

Confirmed on Windows 10 with standalone installer (https://qgis.org/downloads/QGIS-OSGeo4W-3.16.13-1.msi).

[agiudiceandrea]

Confirmed on Windows 10 with the latest available OSGeo4W v2 Standalone Installer QGIS-OSGeo4W-3.16.13-1.msi

[sigeal]

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.

[Tom-2]

I have the same issue.

QGIS 3.16.13 msi installer (proj 8.2.0) has the problem.
QGIS 3.16.10 msi installer (proj 8.1.0) doesn't have 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".

Korean 1985 / Modified Central Belt
WKT
PROJCRS["unknown",
BASEGEOGCRS["unknown",
DATUM["Unknown based on Bessel 1841 ellipsoid",
ELLIPSOID["Bessel 1841",6377397.155,299.1528128,
LENGTHUNIT["metre",1,
ID["EPSG",9001]]]],
PRIMEM["Greenwich",0,
ANGLEUNIT["degree",0.0174532925199433],
ID["EPSG",8901]]],
CONVERSION["unknown",
METHOD["Transverse Mercator",
ID["EPSG",9807]],
PARAMETER["Latitude of natural origin",38,
ANGLEUNIT["degree",0.0174532925199433],
ID["EPSG",8801]],
PARAMETER["Longitude of natural origin",127.002890277778,
ANGLEUNIT["degree",0.0174532925199433],
ID["EPSG",8802]],
PARAMETER["Scale factor at natural origin",1,
SCALEUNIT["unity",1],
ID["EPSG",8805]],
PARAMETER["False easting",200000,
LENGTHUNIT["metre",1],
ID["EPSG",8806]],
PARAMETER["False northing",500000,
LENGTHUNIT["metre",1],
ID["EPSG",8807]]],
CS[Cartesian,2],
AXIS["(E)",east,
ORDER[1],
LENGTHUNIT["metre",1,
ID["EPSG",9001]]],
AXIS["(N)",north,
ORDER[2],
LENGTHUNIT["metre",1,
ID["EPSG",9001]]]]
Proj4
+proj=tmerc +lat_0=38 +lon_0=127.002890277778 +k=1 +x_0=200000 +y_0=500000 +ellps=bessel +units=m +no_defs
공간범위
범위를 알 수 없음

Here's QGIS 3.16.10 (proj 8.1.0)'s EPSG 5174 code which is ok.

There's no "unknown".

Korean 1985 / Modified Central Belt
WKT
PROJCRS["Korean 1985 / Modified Central Belt",
BASEGEOGCRS["Korean 1985",
DATUM["Korean Datum 1985",
ELLIPSOID["Bessel 1841",6377397.155,299.1528128,
LENGTHUNIT["metre",1]]],
PRIMEM["Greenwich",0,
ANGLEUNIT["degree",0.0174532925199433]],
ID["EPSG",4162]],
CONVERSION["Korea Modified Central Belt",
METHOD["Transverse Mercator",
ID["EPSG",9807]],
PARAMETER["Latitude of natural origin",38,
ANGLEUNIT["degree",0.0174532925199433],
ID["EPSG",8801]],
PARAMETER["Longitude of natural origin",127.002890277778,
ANGLEUNIT["degree",0.0174532925199433],
ID["EPSG",8802]],
PARAMETER["Scale factor at natural origin",1,
SCALEUNIT["unity",1],
ID["EPSG",8805]],
PARAMETER["False easting",200000,
LENGTHUNIT["metre",1],
ID["EPSG",8806]],
PARAMETER["False northing",500000,
LENGTHUNIT["metre",1],
ID["EPSG",8807]]],
CS[Cartesian,2],
AXIS["northing (X)",north,
ORDER[1],
LENGTHUNIT["metre",1]],
AXIS["easting (Y)",east,
ORDER[2],
LENGTHUNIT["metre",1]],
USAGE[
SCOPE["Cadastre, engineering survey, topographic mapping (large and medium scale)."],
AREA["Republic of Korea (South Korea) - between 126°E and 128°E - mainland and nearshore."],
BBOX[33.96,126,38.33,128]],
ID["EPSG",5174]]
Proj4
+proj=tmerc +lat_0=38 +lon_0=127.002890277778 +k=1 +x_0=200000 +y_0=500000 +ellps=bessel +units=m +no_defs
공간범위
126.00, 33.96, 128.00, 38.33

[wfletcher]

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

public static CRS FromWKT(string wkt, bool identify = false)
{
    lock (Proj6Native._sync)
    {
        //although using proj_context_create will make proj6 thread safe
        //it is expensive (10x). Faster to use .net lock and just use the default context
        IntPtr context = IntPtr.Zero;// Proj6Native.proj_context_create();
        try
        {
            IntPtr p = Proj6Native.proj_create(context, wkt);
            if (p != IntPtr.Zero && identify)
            {
                string name = Proj6Native.GetAuthName(p);
                int confidence = 0;
                IntPtr p2 = Proj6Native.Proj_identify(context, p, name, out confidence);
                if (p2 != IntPtr.Zero && confidence > 85)
                {
                    Proj6Native.proj_destroy(p);
                    p = p2;
                }
                else
                {
                    if (p2 != IntPtr.Zero)
                    {
                        Proj6Native.proj_destroy(p2);
                    }
                }
//more code follows but not relevant

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 :
GEOGCS["GCS_unknown",DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137.0,298.257223563]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]]

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
ne_10m_populated_places_simple-prjformats.zip
.

[gioman]

some of my users are reporting issues loading the shapefiles in QGIS too

@wfletcher made them downgrade to 3.16.11 standalone or install 3.16.13 with the network installer until this is not sorted out.

[nirvn]

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.

[gioman]

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.

[pathmapper]

We likely need to remove 3.16.13 from qgis.org until we figure this one out.

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?

• different dependency versions? (my 3.16.13 network install runs with GDAL/OGR 3.4.0 compared to 3.3.3 for msi standalone 3.16.13)
• packaging/build issues?

QGIS-OSGeo4W-3.16.12-2.msi doesn't have this issue, so it looks like the cause for the regression is related to changes made QGIS-OSGeo4W-3.16.12-2.msi -> QGIS-OSGeo4W-3.16.13-1.msi.

[agiudiceandrea]

• different dependency versions? (my 3.16.13 network install runs with GDAL/OGR 3.4.0 compared to 3.3.3 for msi standalone 3.16.13)

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.
Only three days ago the GDAL package was upgraded to 3.4.0 version.

[pathmapper]

Fixed according to https://trac.osgeo.org/osgeo4w/ticket/703

[agiudiceandrea]

Fixed according to https://trac.osgeo.org/osgeo4w/ticket/703

and to https://github.com/qgis/QGIS-Website/pull/949#issuecomment-971340648 and https://github.com/qgis/QGIS-Website/pull/949#issuecomment-972262558