WFS Layer is not rendered when requested CRS is not matching project CRS and "Only request features overlapping the view extent" option is set

[pathmapper]

Describe the bug
WFS Layer from QGIS server is not rendered when requested CRS is not matching project CRS.

How to Reproduce (updated 2021-07-22)

1. From the QGIS top menu: Settings -> Options -> CRS -> use EPSG:25832 as default CRS

2. From the QGIS top menu: Layer -> Add Layer -> Add WFS Layer... -> make sure the checkbox for Only request features overlapping the view extent is checked

3. Restart QGIS
4. Add WFS connection: https://geo.kreis-viersen.de/ows/abk-material-nrw
5. QGIS Browser: Add layer: test_layer_epsg_4326 or use the Add WFS Layer... dialog with CRS EPSG:4326
6. See error: test_layer_epsg_4326 is not rendered but attribute table and feature count are available.
7. After switching the project CRS to EPSG:4326, the data is rendered on the canvas.

QGIS and OS versions

QGIS version	3.21.0-Master	QGIS code revision	f0dc0d9
Qt version	5.12.8
Python version	3.8.10
GDAL/OGR version	3.0.4
PROJ version	6.3.1
EPSG Registry database version	v9.8.6 (2020-01-22)
Compiled against GEOS	3.8.0-CAPI-1.13.1	Running against GEOS	3.8.0-CAPI-1.13.1
SQLite version	3.31.1
PostgreSQL client version	12.7 (Ubuntu 12.7-0ubuntu0.20.04.1)
SpatiaLite version	4.3.0a
QWT version	6.1.4
QScintilla2 version	2.11.2
OS version	Ubuntu 20.04.2 LTS
Active Python plugins	sagaprovidergrassproviderMetaSearchprocessingdb_manager

Additional context

• Sometimes the data is rendered without switching the project CRS, e.g. after panning the map or waiting some time.
• Why is the data requested in EPSG:4326? The server offers also EPSG:25832 as CRS.

[gioman]

@pathmapper works fine here, QGIS master on Ubuntu 20.04

[pathmapper]

@gioman sometimes it's working, often not. I can reproduce it often, did you have a look at the GIF?

[gioman]

did you have a look at the GIF?

@pathmapper I did, seems to work all the time here.

[pathmapper]

It's also worth to mention, that this is reproducible on 4 different machines and different networks. If the datasource for the WFS server is set to EPSG:25832 (so that it matches the project CRS) there are no issues.

Maybe the issue has to do with the on-the-fly reprojection?

@gioman any idea

Why is the data requested in EPSG:4326? The server offers also EPSG:25832 as CRS.

If the project CRS is set to EPSG:25832 shouldn't QGIS request the WFS in EPSG:25832 to avoid on-the-fly reprojection?

[github-actions]

The QGIS project highly values your report and would love to see it addressed. However, this issue has been left in feedback mode for the last 14 days and is being automatically marked as "stale".
If you would like to continue with this issue, please provide any missing information or answer any open questions. If you could resolve the issue yourself meanwhile, please leave a note for future readers with the same problem and close the issue.
In case you should have any uncertainty, please leave a comment and we will be happy to help you proceed with this issue.
If there is no further activity on this issue, it will be closed in a week.

[pathmapper]

This is still reproducible with a new profile and master da03027 on Ubuntu 20.04.2:

Please have a look at the following GIF which shows another way to reproduce the issue:

The first added layer Kindergärten_2019_09_02 is in EPSG:25832, so it is matching the project CRS and is rendered.

The layer test_layer_epsg_4326 is in EPSG:4326, not matching the project CRS and is not rendered after adding it, but it shows the feature count. After executing Zoom to layer(s), the layer is rendered on the canvas.

[gioman]

@pathmapper here:

[pathmapper]

@gioman thanks for checking again. Could this be hardware dependent?

Would be good if someone else could try to reproduce like in #44095 where you couldn't reproduce but @NyakudyaA was able to do so...

Just also reproduced on Windows 10 with master 117b4394 and

this is reproducible on 4 different machines and different networks

Is there anything I can do to help debugging?

[gioman]

Is there anything I can do to help debugging?

@pathmapper

uncheck this option, restart QGIS, try again.

[pathmapper]

uncheck this option, restart QGIS, try again.

@gioman that's it, thank you so much! 🎉

I've updated the How to Reproduce part of the issue description, now you are able to reproduce, right?

Regarding the issue itself:

• It's kind of unexpected that a setting from the "add WFS layer" dialog has an effect (only after restart!) for adding a WFS Layer via QGIS browser.
• The GetFeature request including the BBOX parameter for the layer which is not rendered looks good. Also the data is available (attribute table shows the features).

So it looks like the issue is that for some reason the WFS layer with a different CRS compared to the project CRS is not rendered on the canvas despite the GetFeature request was successful.

[gioman]

* It's kind of unexpected that a setting from the "add WFS layer" dialog has an effect (only after restart!) for adding a WFS Layer via QGIS browser.

@pathmapper not totally unexpected, probably the browser used a cached network request. Just an idea.

[pathmapper]

@gioman the issue isn't limited to WFS layers added via QGIS Browser.

The layer is also not rendered if it is added via the Add WFS layer... dialog if a CRS different compared to the project CRS is set:

(The first via QGIS Browser added layer Kindergärten_2019_09_02 is in EPSG:25832, so it is matching the project CRS and is rendered.)

[rouault]

The issue here is on the WFS server. One can see in https://geo.kreis-viersen.de/ows/abk-material-nrw?SERVICE=WFS&REQUEST=GetFeature&VERSION=1.1.0&TYPENAME=test_layer_epsg_4326 that it uses a longitude, latitude order for coordinates, but in WFS 1.1.0, it should respect the EPSG axis order of EPSG:4326 which is latitude, longitude.
The workaround is to check the "Ignore axis orientation (WFS 1.1/2.0)" checkbox when setting the server.
In #45044, I've added a hint to the user

[pathmapper]

Thanks for looking into this and implementing the hint @rouault !

The issue here is on the WFS server.

The WFS Server in question is a QGIS Server.

in WFS 1.1.0, it should respect the EPSG axis order of EPSG:4326 which is latitude, longitude.

According to the description of @elpaso's PR #41242, QGIS Server is following the convention used by GeoServer which is longitude/latitude for the representation EPSG:4326 and the

The bottom line is that 1.0.0 and 1.1.1 with this patch are behaving the same way.

I understood this whole WFS axis order topic is a whole mess, but currently we are needing a workaround for QGIS Desktop using a WFS provided by QGIS Server which feels bit awkward.

Looks like there are now three options:

1. Do nothing and use the workaround for QGIS Server WFS.
2. Change the QGIS Server axis order for WFS 1.1.1 for EPSG:4326 to latitude/longitude.
3. Change QGIS Desktop to handle longitude/latitude order for coordinates for WFS 1.1.1 and EPSG:4326 without workaround.

[rouault]

It would be much less ambiguous if QGIS server would use srsName=urn:ogc:def:crs:EPSG::4326 and latitude/longitude order