LMWC 3.7.0: background layer added with QuickMapServices do not show

[gioman]

What is the bug?

As far as I understand, tell me if I'm wrong, there baselayers we used to add within the baselayers tab in LM plugin (that are not printable and not re-projectable) are not supported anymore, right?

Instead anything in the "baselayers" group become a baselayer and it seems to me that in the LM plugin is suggested to use QuickMapservices, right?

I tried to add a base layer (Bing satellite) there with QMS and it is not showing in the project when loaded.

This new paradigm for baselayers make sense in a way, but leave me with a few questions:

• the legacy un-printable and un-reprojectable base layers where much faster to load compared to the ones loaded with QMS or other remote services (WMS et al), in a scenario where printing was not an issue they were very useful.

• when using the latest version of the LM plugin the layer properties for anything inside the "baselayers" group is completely disabled, why? How is controlled how those layers are shown (i.e. title, rendering)

Steps to reproduce the issue

Test project here:

dorset.zip

Versions

LMWC 3.7.0

On Ubuntu 22.04 with QGIS Server 3.28.12, Project saved on QGIS 3.28.12 ans LM plugin 4.1.1

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

No response

[gioman]

Also:

how is controlled which is the default baselayer

if the control we used for is not not populated?

Changing the order in the group makes no difference.

[Gustry]

when using the latest version of the LM plugin

LM plugin 3.18.1

We are at version 4.1.1, not latest in your case.
https://plugins.qgis.org/plugins/lizmap/#plugin-versions

unclear of tho choose the default baselayer

Upgrade your plugin, it's written how the default one is set

the legacy un-printable and un-reprojectable base layers where much faster to load compared to the ones loaded with QMS or other remote services (WMS et al), in a scenario where printing was not an issue they were very useful.

Did you check the requests in your webbrowser ?

[gioman]

@Gustry I'm sorry I wrote the wrong version of the plugin, I'm indeed using 4.1.1. I will edit the tickets description where I reported the wrong version.

[Gustry]

@Gustry I'm sorry I wrote the wrong version of the plugin, I'm indeed using 4.1.1.

In your provided zip dorset.zip : "lizmap_plugin_version_str": "3.18.1", :/
You could follow the step in the plugin, it doing all versions for you.

[gioman]

In your provided zip dorset.zip : "lizmap_plugin_version_str": "3.18.1", :/
You could follow the step in the plugin, it doing all versions for you.

I tested with the updated version of the plugin before posting, but forgot to update the project in the zip file.

[Gustry]

Sorry, but I still don't get your question about first bullet point.

Or what do you mean by " legacy un-printable" ? They were printable https://docs.lizmap.com/3.7/en/publish/configuration/print.html#allow-printing-of-external-baselayers It's now "Deprecated" in the doc, because this section has been there for years.

For second one, yes, we are aware.

Changing the order in the group makes no difference.

It's written in the plugin. Was your CFG file up to date ?

[gioman]

Sorry, but I still don't get your question about first bullet point.

Or what do you mean by " legacy un-printable" ? They were printable https://docs.lizmap.com/3.7/en/publish/configuration/print.html#allow-printing-of-external-baselayers It's now "Deprecated" in the doc, because this section has been there for years.

@Gustry what I mean is the difference between adding (example) the Google Satellite layer from the baselayers tab (with the appropriate key) and adding it in the project with the QMS plugin and then making it a base layer. The loading speed difference at any scale is very large I guess because the data source are different (one also caused the project to change to 3857 and work at predefined scale levels, the other not). By "un-printable" I mean that without the trick https://docs.lizmap.com/3.7/en/publish/configuration/print.html#allow-printing-of-external-baselayers those layers added directly within the plugin were not printable, and I just referred that just to make a point that the sources of those layers are not same as the ones added with QMS and to underline the difference in speed loading, that is one of the points I raised.

Doing more tests on LMWC 3.7.0 and LM plugin 4.1.1:

• adding with QMS the google satellite layer in the baselayers group, the layer is visible but does not print. On previous versions of LMWC it does print.

• adding the same layer but as normal layer outside the baselayers group and making it a base layer with

makes it a visible base layer but still does not print

• adding the same layer as normal layer do not show on the map (and of course does not print)

• adding Bing satellite with QMS it does not ever show, nor as a base layer nor as normal layer

[gioman]

It's written in the plugin. Was your CFG file up to date ?

It was just not working (re-ordering the content of the BL group). But now after removing/re-adding a few times the baselayers group and its content this has "fixed" itself.

[gioman]

Did you check the requests in your webbrowser ?

comparing between (example) Google Satellite added with

and

requests seems different to me and the latter is much faster but not available anymore

if I got the changes in 3.7.0 right.

My first point was just a way to try to understand better this change and its implications.

[Gustry]

Sorry, it's difficult to follow, there are many questions/notes in a single ticket :)

It was just not working (re-ordering the content of the BL group). But now after removing/re-adding a few times the baselayers group and its content this has "fixed" itself.

The CFG file is also storing the QGIS layer tree (since the beginning of LWC), so when you change the QGIS layer tree, users must always reopen and close the Lizmap dialog to resave the Lizmap layer tree. Otherwise, there two different layer tree, incompatible each other.

The loading speed difference at any scale is very large I guess because the data source are different (one also caused the project to change to 3857 and work at predefined scale levels, the other not).

LWC uses project projection everywhere now (main map and print). Scales are defined in the second tab of the plugin, or you can tick the checkbox to use "native" 3857 scales.

Related to these legacy checkbox, yes, we do not want to maintain these checkbox and only these specific layers. We only want to rely on the QGIS project, and let the users set his API keys in the QGIS project itself.

If I'm not wrong, using Google tiles in OpenLayers is not supported by their TOS outiside of their library. It has been an issue in OpenLayers when they were providing a wrapper for Google tiles. The wrapper has been removed from OL library. https://support.google.com/maps/thread/47787744/integrating-google-maps-with-openlayer?hl=en

[Gustry]

when using the latest version of the LM plugin the layer properties for anything inside the "baselayers" group is completely disabled, why? How is controlled how those layers are shown (i.e. title, rendering)

The idea was to use the maximum of informations from the QGIS project itself. That's why the whole panel has been disabled in case of the layer is contained in the baselayers group, and then to reactivate specific widgets only according to what is possible when the CFG is read by LWC. This needs some insights from @rldhont or @nboisteault which config can be overridden by CFG file.

[gioman]

Sorry, it's difficult to follow, there are many questions/notes in a single ticket :)

comment #4030 (comment) has now to be ignored. order control was not working in my test project, then it started to work after removing and re-adding the baselayers group.

The main question/problem raised here is that now the way to go is to add baselayers from QMS, but:

• not all layers added with QMS are showing, the example reported being Bing Satellite

• even when adding a layer with QMS in the baselayer group results in a visible layer in LMWC, then the layer is a now show in print layouts

Then while troubleshooting the above I also noticed that

• QMS layers added as normal layers (outside the baselayers group) are a no show in LMWC 3.7

• Making one of those layer a baselayer (with the "baselayer" checkbox) makes them show in LMWC, sometimes, but this does not solve the printing problem

On top of this I wanted to understand, as a normal discussion (because when raising questions on the ML they often go unanswered), if the choice the get rid of the "baselayers" panel in the LM plugin has taken into account the fact that the (base)layers added there are much faster to load compared to the same layers added with QMS (because the source are different). The choice to delegate as much to the QGIS project make sense, but also makes sense to have options to make everything as fast as possible is important, considering also that seeding of QMS layers is not working, see #3696

[Gustry]

That's why the whole panel has been disabled in case of the layer is contained in the baselayers group, and then to reactivate specific widgets only according to what is possible when the CFG is read by LWC.

Some improvements on this part in the latest version of the plugin 3liz/lizmap-plugin#548

[Gustry]

#4150 has been merged, can we close this ticket ?
A new version of LWC will be released today.

[gioman]

#4150 has been merged, can we close this ticket ?

@Gustry I still do not understand fully the implications of that commit regarding the observations I made in this ticket, but I'll test and let you know. Thanks!

[Gustry]

To be honest, that are many PR merged since 3.7.0, not only #4150 see https://github.com/3liz/lizmap-web-client/pulls?q=is%3Apr+is%3Aclosed+milestone%3A3.7.3
And this ticket is a kind of a "meta ticket" now, it would be easier to have a single ticket tracking a single issue.

So I'm closing this one. Thanks

[gioman]

racking a single issue.

@Gustry I know well what are the best pratices when filing a ticket, here #4030 (comment) I clearly stated that this was more a way to look for a discussion/exchange because is not unusual for such questions go unanswered on the mailing list.