Support customizing the tile server for online map

[goodspeed34]

In some countries with Internet censorship, the default OpenStreetMap tile server may not be accessible. This commit adds an option to choose the preferred tile server from a predefined list or customize them as needed.

By default, the online map retains the old behaviour which defaults to the user's system language and it also provides an option to choose the langugage for OSM.

[goodspeed34]

It's my first time hacking around a Qt application, it's great but I didn't find a way to reload a pre-existing online map widget. So currently, it takes a restart to apply the new server to the online map.

[foldynl]

Unfortunately, I cannot accept this PR. There has already been a similar PR here and I have the same comment here:

Since I don’t understand Chinese, I cannot verify whether this change is suitable for an open-source project under GPLv3 license. Specifically, I can't determine if it’s free of restrictions or potential regulatory issues from AutoNavi site.

Your colleague from China said he would find out the details, but unfortunately nothing like that has happened yet (#528)

[goodspeed34]

Hello, thanks for the feedback. Maybe we could work other around, like without providing the autonavi options in the predefined tile server list.

Allowing customizing tile server is a great feature for users imho since it doesn't force the user to use hard-cored OSM with fixed language markings.

[goodspeed34]

OK, I have amened the commit with the removal of the problematic tile servers. The options currently it have are:

• Default (This refers to the old behavior where it was coded to meet the user's langugae)
• OSM (English)
• OSM (German)
• OSM (French)

And it also allow the user to provide a custom tile server so that they could choose their favorite map source. So this option would be good for those who want to customize or whose tile server blocked by Internet censorship. Maybe it's a good idea to add other map sources but I don't have any ideas on that.

[foldynl]

On the other hand, by providing built-in servers I guarantee that they will work, and if they do not, it is my responsibility to fix it. Unfortunately, I see no reason to let the user change the Tile server. I am not able to test all Tile servers in the world to verify their compatibility with Leaflet or to ensure there are no side effects with using them.

The servers included now I am able to test.

[goodspeed34]

On the other hand, by providing built-in servers I guarantee that they will work, and if they do not, it is my responsibility to fix it. Unfortunately, I see no reason to let the user change the Tile server. I am not able to test all Tile servers in the world to verify their compatibility with Leaflet or to ensure there are no side effects with using them.

The servers included now I am able to test.

Thanks for the reply. I understand your concern, but allowing a custom tile server does not add any responsibility to the project.

It’s similar to how Debian allows users to set their own mirror or even add third-party repositories — Debian maintainers are not responsible for those external sources, and compatibility is entirely up to the user.

Here it is the same: the built-in tile servers remain fully under your control, and only those are “supported”.
The custom server option is just an advanced escape hatch for users who need it, especially in regions where the default server is blocked.

This way existing behaviour stays safe, while users gain flexibility.

[goodspeed34]

Another example is rig control, the maintainers wouldn't have tested all the supported rig but they know hamlib etc. works for those configurations fone by the user. The developers wouldn't be possible to test and guide the user to configure the software for rig foo. We just believe that if user wants to do this and they could get it right with hamlib.

The same thing works here, if user wants to configure QLog for their own maps, we believe they could get it right with leaflet.

It's really not developers' fault when it comes to an OSI layer 8 issue. 🤪

[foldynl]

Please understand that the examples you are giving are not comparable at all.

A quick investigation shows that there is also a problem with the coordinate systems. China is required to use the GCJ-02 coordinate system, while the rest of the world uses WGS-84. This alone creates a significant technical issue to recalculate the coordinates.

I cannot prevent you from creating a fork as long as it fully complies with the GPLv3 license. In that case, it would be entirely up to you what “improvements” you add specifically for China, including providing user support for those changes. I personally do not want to introduce a configurable Tile server option, because it would lead to many unexpected issues—not from a programming perspective, but from a user-support perspective.

As you mentioned Hamlib. Believe me, I already have enough trouble with hamlib. I have even considered rewriting the whole library myself, which might actually be faster. However, it looks like hamlib has been “revived” recently, so hopefully the situation with that library will improve.

[goodspeed34]

Thank you for your feedback and for all your work on this project. I understand the concerns regarding user support and coordinate systems. I will go ahead and create a soft fork to implement the configurable tile server feature for my use case. I really appreciate your contributions and guidance.