[Bug]: Bing Satellite added with QMS plugin do not show as baselayer

[gioman]

What is the bug?

Adding "Bing Satellite" with Quick Map Services plugin does work as a normal layers, but does not show if added in the Baselayers group.

I had already observed something similar here

#4030 (comment)

and now it is partially solved.

Steps to reproduce the issue

See above.

Versions, safeguards, check summary etc

LMWC 3.7.3 and QGIS Desktop/Server 3.28.15 LM Plugin 4.2.0

Check Lizmap plugin

• 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 22.04

Browsers

Firefox, Chrome

Browsers version

Latest updates

Relevant log output

Nothing relevant.

[Gustry]

When using Bing on a website, you need to set your API key in the "Map options" panel. Did you set it ?

[gioman]

Did you set a API key ?

@Gustry I have, but anyway this question is baffling me. That layer (and as well Google Satellite) do not need any API key to show in QGIS when added with QMS. And in fact Google Satellite works well in LMWC as normal layer and as baselayer. Bing does not work only as baselayer. What am I missing?

[Gustry]

Can you check your HTTP requests status for Bing tiles ?

[aeduard]

With the newest version of the lizmap plugin (4.2.0) Google Hybrid does not work with the API key set. Strangely Google Satellite works. I don't have bing maps api key to test.

[gioman]

Can you check your HTTP requests status for Bing tiles ?

@Gustry This is what I'm observing:

• layers added with QMS (i.e. Google/Bing Satellite) outside the baselayers group, are always requested as WMS via QGIS Server (as expected), regardless if the "Gets Images Directly from WMS Server" checkbox is enabled (less expected, as it happens also with WMS layers for remote services that are not provided by QMS but rather a standard WMS connection)

• when some layers are moved into de "baselayers" group (definitely Google/Bing Satellite added with QMS) these are automatically requested from the original tile servers. i.e.

https://ecn.t3.tiles.virtualearth.net/tiles/a%7Bq%7D.jpeg?g=0&dir=dir_n%27

This works ok for Google Satellite even without specifying an API key in LM plugin. On the other hand Bing Satellite fails to load with the following message in FF dev console

A resource is blocked by OpaqueResponseBlocking

that do not seems to be related with the lack of API key but rather seems something related with CORS (which maybe could be solved on a specific server instance, but a a google search didn't returned much).

Not sure if all the above helps me answer some of the questions I had placed here #4030 or not.

[gioman]

• when some layers are moved into de "baselayers" group (definitely Google/Bing Satellite added with QMS) these are automatically requested from the original tile servers. i.e.

forgot to ask: I guess this is on purpose... but why? I mean, not that is bad, but why requesting the same layer in two different ways depending on where it sits in the project tree?

[Gustry]

Google Hybrid does not work with the API key set.

Google is not officially supported by OpenLayers (and therefore by Lizmap). There is an open PR for that in OpenLayers repository and also a ticket opened. This is a an issue for everyone using the OpenLayers library.

Thanks @gioman for debugging these layers.

A resource is blocked by OpaqueResponseBlocking

Does the image works works if you open it in new tab ?
I guess you need to check your CORS settings indeed and/or the API key.

All Bing services must use a API key. Same for Google.

I'm don't know how Bing/Google don't detect QGIS Desktop/Server when distributing tiles. It seems in OpenLayers/webbrowsers, there are more checks about API key, CORS, referer etc. I don't know this area.

why requesting the same layer in two different ways depending on where it sits in the project tree?

I will let my colleagues. The idea is to rely as maximum on the QGIS project, and to not use these legacy "checkbox" for baselayers in the plugin. Lizmap was managing these URL in the background and was limited to provider in core LWC. By using the QGIS project, we let more freedom to users (except if there is some hacks with API keys for now). I'm not sure why it depends of location in the tree. I think it was more when it was developed with the idea of the baselayers group.

With these legacy checkboxes, it was using requesting tiles straight to the tile provider, so Lizmap tries to keep the same behavior, which is better to not overload QGIS server requesting tiles etc.

[gioman]

Thanks @gioman for debugging these layers.

A resource is blocked by OpaqueResponseBlocking

Does the image works works if you open it in new tab ? I guess you need to check your CORS settings indeed and/or the API key.

All Bing services must use a API key. Same for Google.

I'm don't know how Bing/Google don't detect QGIS Desktop/Server when distributing tiles. It seems in OpenLayers/webbrowsers, there are more checks about API key, CORS, referer etc. I don't know this area.

why requesting the same layer in two different ways depending on where it sits in the project tree?

I will let my colleagues. The idea is to rely as maximum on the QGIS project, and to not use these legacy "checkbox" for baselayers in the plugin. Lizmap was managing these URL in the background and was limited to provider in core LWC. By using the QGIS project, we let more freedom to users (except if there is some hacks with API keys for now). I'm not sure why it depends of location in the tree. I think it was more when it was developed with the idea of the baselayers group.

With these legacy checkboxes, it was using requesting tiles straight to the tile provider, so Lizmap tries to keep the same behavior, which is better to not overload QGIS server requesting tiles etc.

@Gustry I feel I may have not explained myself in a very clear way.

The observations that led to this ticket are not at all related to adding bing/google with the "legacy checkboxes", in first place because they are legacy, but also because now those legacy layers cannot be added

What I made was to add those layers with QMS, this way there is no need of any API key in QGIS Desktop or Server. But then "strange" things happen in LMWC:

• when added outside the "baselayers" group the layers are requested via QGIS Server, as expected, and they work OK.

• the "get images directly from WMS server" does nothing (meaning that the images are still requested via QGIS Server), and this is unexpected

• even more unexpected is that if those layers are added/dragged into the "baselayers" group then they are requested in a completely different way which I think could really need an API key, but unclear why Google Satellite still works, and unclear why Bing does not as the error do not seems to be related to a missing API key. But the most important question is why those layers are requested in a different way when inside the "baselayers" group, as this is not coherent with the new (correct) logic of having everything based on the QGIS project content.

[gioman]

@Gustry I guess that the answer to my question is this?

#4150

But then more questions:

why it works this way also for the Google Satellite layer added with QMS (and then retrieved as a tile layer when added into the baselayers group)

if the API KEY is needed when moving such layers into the baselayers group, shouldn't this issue a warning in the plugin GUI?