[Bug]: Problems using XYZ tiles depending on project reference system in Lizmap 3.7

[RobiFag]

What is the bug? (in English)

Adding XYZ tiles layers (EPSG:3857) from QGIS Data Source Manager, Plugin Quick Map Service and Plugin Lizmap returns different errors depending on the project reference system.:

• Project with RS EPSG:3003 - XYZ tiles are visible but shifted
• Project with RS EPSG:4326 - XYZ tiles are not visible (request not sent)
• Project with RS EPSG:3857 - XYZ tiles are correctly visible

project_3003.zip project_3857.zip project_4326.zip

I made the same test with Lizmap 3.6.10 and the results are the same for the three project regardless of the project reference system:

• xyz layers added from data source manager are not visible (request status 200 but the response is empty)
• xyz layers added from QMS plugin are correctly visible
• xyz layers added from Lizmap plugin are correctly visible

Steps to reproduce the issue

1. Create a project with a reference system different from EPSG:3857
2. add a layer with the same reference system of the project (to have a reference point)
3. add an xyz tiles layer from data source manager and/or Lizmap plugin and/or Quick Map Service plugin (added by default in 3857)

Versions, safeguards, check summary etc

Versions :

• Lizmap Web Client : 3.7.6
• Lizmap plugin : 4.3.5
• QGIS Desktop : 3.34.4
• QGIS Server : 3.34.4
• Py-QGIS-Server : 1.8.8
• QGIS Server plugin atlasprint : 3.3.2
• QGIS Server plugin lizmap_server : 2.8.6
• QGIS Server plugin wfsOutputExtension : 1.8.0

List of safeguards :

* Mode : normal * Allow parent folder : no * Prevent other drive : yes * Prevent PG service : yes * Prevent PG Auth DB : yes * Force PG user&pass : yes * Prevent ECW : yes

Check Lizmap plugin

• [X] I have done the step just before in the Lizmap QGIS desktop plugin before opening this ticket. Otherwise, my ticket is not considered valid and might get closed.

Operating system

Ubuntu 20.04.6 LTS

Browsers

Firefox, Chrome, Microsoft Edge

Browsers version

Firefox Versione 124.0.2, Chrome Versione 123.0.6312.106, Microsoft Edge Versione 123.0.2420.81

Relevant log output

No response

[pizzuga]

I can confirm. I was opening the same bug with our data. The same layers (e.g. OSM, Google Hybrid etc.) in the TOC of layer are reprojected correctly. In the following images OSM as base layer (with shift) and as layer in the TOC of layers

[RobiFag]

The problem actually seems to be the definition as baselayers (baselayers group), if the XYZ are loaded as overlay layers there are no issues depending on the reference system of the project:

• Project with RS EPSG:3003 and NO baselayers - XYZ are correctly visible without shift
• Project with RS EPSG:4326 and NO baselayers - the request is sent and XYZ are correctly visible

[timbo-barnes]

The problem actually seems to be the definition as baselayers (baselayers group), if the XYZ are loaded as overlay layers there are no issues depending on the reference system of the project:

• Project with RS EPSG:3003 and NO baselayers - XYZ are correctly visible without shift
• Project with RS EPSG:4326 and NO baselayers - the request is sent and XYZ are correctly visible

This is consistent with what I've found- I think the new 'baselayers' needs a bit more work. (in my case too, I can't print when I have my layers all in EPSG:2193 which used to work before 'baselayers' group was introduced. I now have to use a EPSG: 3857 basemap and map CRS...which means the server is having to reproject all my other vector layers on the fly and everything is very slow