Unify default max_zoom for custom layers and global maximum zoom

[rkflx]

Historically, many tile services have been providing tiles up to zoom level 18, with some later enabling zoom levels of 19 and beyond. BRouter-Web's current global limit is 19, which is used by some layers setting max_zoom in /layers/*.geojson. Tiles added via the custom layers dialog or configured in /config.js default to a maximum zoom of 18 due to this being a Leaflet default.

With a custom layer showing and zooming to 19, that layer will be disabled in the layers list. This has two effects:

• No attempts to fetch any tiles for that level are made, so 404 errors for missing tiles are avoided both for the client and the server.
• For overlays, the overlay will be hidden. For base layers, gray tiles will be shown to users.

When not disabling custom layers for zoom level 19, it would work like this:

• Tiles are always fetched, either successfully or with a 404 error.
• Tiles will be shown to the user if available, and replaced with a gray tile otherwise.

Essentially there is a tradeoff between trying to avoid unsuccessful tile fetches and impacting the user experience. By making the tradeoff less conservative, tiles will be shown to users in more cases, at the expense of more 404 errors (but luckily no change in user experience) for servers not supporting level 19. Note that we already cause 404 errors for services not even supporting 18, as the limit of 18 is a best guess only anyway.

Given those considerations and the trend for more and more services to provide level 19 tiles, here we unify the global limit of 19 and the limit for custom layers (more precisely: any layer not having explicitly specified another max_zoom). This prioritizes user experience over overly cautious tile fetches.

This change can be considered a temporary measure. In the future, the global default in Leaflet could be increased, and in BRouter-Web custom zoom limits, auto-detection and up-scaling could be hooked up.

Fixes #726.

Test Plan:

• Add a map supporting only level 18 tiles via "More" and via "Custom layers", e.g. "OpenStreetMap (Belgian Style)".
• Add a map also supporting level 19 tiles via "More" and via "Custom layers", e.g. "OpenStreetMap".
• For each map, zoom to level 19.
• There will still be gray tiles (and some additional 404 errors in the browser console) for the custom "OpenStreetMap (Belgian Style)" map.
• The pre-configured "OpenStreetMap (Belgian Style)" map still up-scales.
• Now the custom "OpenStreetMap" map will show without gray tiles, while before only the pre-configured map worked.
• Test that not only layers added via the custom layers dialog show the new behaviour, but those configured in /config.js (both base layers and overlays) and those from /layers/*.geojson without an explicit max_zoom as well.
• Check that the global zoom limit of 19 still applies.

[rkflx]

This seemingly simple topic can become quite mind-boggling:

If 404 errors for tile services not providing level 19 tiles are too controversial, we could additionally set maxNativeZoom=18. It would result in the following changes at zoom level 19:

• There would be no 404 errors for layers supporting only 18 (technical advantage over current state of PR).
• Custom layers would show up-scaled when not supporting 19 (advantage in UX over current state of PR).
• Custom layers supporting 19 would show up-scaled regardless (clear disadvantage over current state of PR).

IOW, this is another trade-off to decide on: Either we will never (this time for real) show gray tiles and always have blurry tiles at 19, or we will allow to show sharp tiles at 19 at the expense of sometimes displaying gray tiles.

I'll leave the PR as-is for now as I'd like to imagine most custom layers are actually supporting 19 and it is less confusing for users, but I'm open to be convinced otherwise. We could also differentiate, e.g. only (always) up-scale overlays and show sharp (sometimes gray) base layers. On the other hand, hiding an overlay is not as bad either. Also note that this won't help for the Strava heatmap, as it only supports 16 so the up-scaling would take effect too late. Opinions?

The ideal solution would of course be to make this configurable or auto-detect it, but that's out of scope for now.

[rkflx]

(Made this a bit more generic, no changes in behaviour.)

[quaelnix]

Opinions?

I think this pull request will satisfy the majority of users.

[divulgacheur]

I agree, this MR solve the issue effectively.