unit "m" not handled in custom WKT string

[caprieldeluca]

Describe the bug

When loading the attached shapefile to QGIS 3.10.2 (tested with 3.10.2-2, also with master branch release), the layer has Unknown CRS.
QGIS 3.4.15 assigns EPSG:31287 CRS to the same shapefile when loaded.

The .prj file has a WKT1 string (I don't know if WKT1-ESRI or WKT1(-OGC/-GDAL)), describing the EPSG:31287 projected CRS, but with the MGI to WGS 84 (8) - EPSG:1194 transformation for its datum (not the same as the default preferred one).

If the user has defined the "Use CRS from first layer added" setting, the project remains with an unknown CRS without a warning.
As can see in https://gis.stackexchange.com/questions/349304/qgis-3-10-2-ltr-projection-problem, this causes an erroneous definition of the scale and an erroneous behavior of the distance measurement tool in planimetric mode.
It is striking that the measurement tool in ellipsoidal mode works well.

How to Reproduce

1. Tick on the "Use CRS from first layer added" setting.
2. Create a new project.
3. Load the attached shapefile.
4. The Layer Properties CRS says Unknown CRS. The Project Properties CRS has not a CRS defined. The scale of the canvas is allways 0:1. Define (if not already) an ellipsoid for the project and measure an ellipsoidal distance, it seems to show a right value. Measure a planimetric distance, the value seems to be right in the units of measure of the layer, but those units are not known (all units in the tool returns the same value).

QGIS and OS versions

QGIS version
3.10.2-A Coruña
QGIS code revision
e28feaf
Compiled against Qt
5.11.2
Running against Qt
5.11.2
Compiled against GDAL/OGR
3.1.0dev
Running against GDAL/OGR
3.1.0dev
Compiled against GEOS
3.8.0-CAPI-1.13.1
Running against GEOS
3.8.0-CAPI-1.13.1
Compiled against SQLite
3.29.0
Running against SQLite
3.29.0
PostgreSQL Client Version
11.5
SpatiaLite Version
4.3.0
QWT Version
6.1.3
QScintilla2 Version
2.10.8
Compiled against PROJ
7.0.0
Running against PROJ
Rel. 7.0.0, March 1st, 2020
OS Version
Windows 10 (10.0)
This copy of QGIS writes debugging output.
Active python plugins
processing

Attached files

shapefile.zip
project.zip

[gioman]

---

When loading the attached shapefile, the layer has Unknown CRS.
The .prj file has a WKT1 string (I don't know if WKT1-ESRI or WKT1(-OGC/-GDAL)).

@gabriel-de-luca if you use the PRJ file from https://spatialreference.org/ref/epsg/31287/ the CRS is recognized as expected, but I guess the real issue here is QGIS not making some assumptions when it does not happens.

[caprieldeluca]

if you use the PRJ file from https://spatialreference.org/ref/epsg/31287/ the CRS is recognized as expected

@gioman , Probably because this definition includes a datum transformation that is not the same as preferred by default for its datum?

I guess the real issue here is QGIS not making some assumptions when it does not happens.

The particular combination of Settings: "CRS for Projects: Use CRS from first layer added", "CRS for Layers : Leave as an unknown CRS (take no action)" and "Default datum transformation: Don't ask for datum transformation if several are available", might produce that behavior?

---

The fact that the ellipsoidal mode in the measurement tool worked, made me think that the CRS was somewhere in between known and unknown.

[gioman]

@gioman , Probably because this definition includes a datum transformation that is not the same as preferred by default for its datum?

The particular combination of Settings: "CRS for Projects: Use CRS from first layer added", "CRS for Layers : Leave as an unknown CRS (take no action)" and "Default datum transformation: Don't ask for datum transformation if several are available", might produce that behavior?

@gabriel-de-luca custom CRSs have always been recognized as such (so QGIS never shown a perfect match to a EPSG code. This may have changed now we use the new proj releases, but not totally sure). What seems wrong to me is that in the past this custom CRSs when applied to a project did not break the scale and the measure tools, but again not 100% sure.

I think the subject and description of this ticket should be changed to something along the lines "Custom CRS breaks project scale"...

[caprieldeluca]

custom CRSs have always been recognized as such

@gioman , I believed that the WKT1 string defined a registered CRS with a custom datum transformation, so I was seeing it as a non-recognition of the registered CRS rather than the recognition of a custom one.

so QGIS never shown a perfect match to a EPSG code.

QGIS 3.4.15 assigns EPSG:31287 CRS to the same shapefile when loaded. (I had not tried to load it to QGIS 3.4 before.)

I think the subject and description of this ticket should be changed to something along the lines "Custom CRS breaks project scale"...

I will edit the description with this new information. I'm still not sure to consider it a custom CRS, but feel free to edit the subject if you think it should be.

[nyalldawson]

Ok, let's dig in here.

1. Using projinfo --identify with the WKT definition from the shapefile's .prj file gives:

Identification match count: 1
BoundCRS of EPSG:31287: 25 %

We use a minimum match confidence of 70% (which is quite tolerant -- from the proj docs: "70% means that CRS are equivalent), but the names do not match at all., 25% means that the CRS are not equivalent, but there is some similarity in the names.).

That explains why QGIS does not identify the shapefile as having EPSG:31287 CRS.

2. Let's dig in further, and check PROJ's definition of 31287, via projinfo -o WKT1:ESRI EPSG:31287

gives:

WKT1:ESRI string:
PROJCS["MGI_Austria_Lambert",GEOGCS["GCS_MGI",DATUM["D_MGI",SPHEROID["Bessel_1841",6377397.155,299.1528128]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Lambert_Conformal_Conic"],PARAMETER["False_Easting",400000.0],PARAMETER["False_Northing",400000.0],PARAMETER["Central_Meridian",13.3333333333333],PARAMETER["Standard_Parallel_1",49.0],PARAMETER["Standard_Parallel_2",46.0],PARAMETER["Latitude_Of_Origin",47.5],UNIT["Meter",1.0]]

The projection part of the WKT definition is completely different:

"PROJECTION["Lambert_Conformal_Conic_2SP", AUTHORITY["EPSG","9802"]], PARAMETER["central_meridian", 13.333333333333336], PARAMETER["latitude_of_origin", 47.5], PARAMETER["standard_parallel_1", 48.99999999999999], PARAMETER["false_easting", 400000.0], PARAMETER["false_northing", 400000.0], PARAMETER["scale_factor", 1.0], PARAMETER["standard_parallel_2", 46.0], UNIT["m", 1.0], AXIS["Easting", EAST], AXIS["Northing", NORTH], AUTHORITY["EPSG","31287"]" (shapefile) vs "PROJECTION["Lambert_Conformal_Conic"],PARAMETER["False_Easting",400000.0],PARAMETER["False_Northing",400000.0],PARAMETER["Central_Meridian",13.3333333333333],PARAMETER["Standard_Parallel_1",49.0],PARAMETER["Standard_Parallel_2",46.0],PARAMETER["Latitude_Of_Origin",47.5],UNIT["Meter",1.0]]" (official)

Conclusion: there's no bug in QGIS or PROJ with the identification -- this shapefile DOES have a custom projection.

3. Looking at the scale issue -- the underlying cause of this issue is that QGIS is reporting the custom CRS has an unknown unit, when it should be detecting that the CRS is in meters (that's specified in the WKT string, but using the non-standard unit string of "m" instead of "meter". A fix is inbound to handle this.

[caprieldeluca]

Thank you very much @gioman and @nyalldawson .