Custom layers are disabled beyond zoom 18

[pbb72]

Regardless of what zoom levels they support, all custom layers are available up to level 18, and disabled beyond that.

The Customize Layers window should allow to indicate a minimum and maximum zoom level, or (the easy solution) custom layers should just always be loaded, resulting in an empty map when the zoom level isn't supported.

[tstreibl]

Great idea! At the moment planning a route along camping places (or other accomodations) is very tedious, since they don't show up any more when you zoom out for an overview.

[quaelnix]

custom layers should just always be loaded, resulting in an empty map when the zoom level isn't supported.

The fact that you can zoom beyond the maximum zoom level of custom layers and then end up on a gray background image is one of the most annoying bugs in brouter-web right now.

[momentmal]

you can zoom beyond the maximum zoom level of custom layers and then end up on a gray background image

or, to formulate positively: please allow custom layers to be scaled up instead of hidden when zooming in beyond supported/provided zoom levels.

[rkflx]

The Customize Layers window should allow to indicate a minimum and maximum zoom level

allow custom layers to be scaled up instead of hidden when zooming in beyond supported/provided zoom levels.

Setting minimum, maximum and overzoom/up-scaling zoom levels already somewhat works when configured via the config files in the layers directory, i.e. the functionality is already largely present in Leaflet. I use this to mitigate CyclOSM slowness for high zoom levels by up-scaling as well as auto-switching to another base map, and to auto-switch to satellite view when zoomed in even more (quite a game changer for my workflow, makes running your own instance totally worth it).

What is needed here is to hook up all three config values into the layers dialog UI and to fix some bugs in Leaflet regarding zoom level configs (e.g. leading to duplicate fetching of hidden tiles).

If we want to get fancy, we could automatically check for 404 tiles in the current region for different zoom levels upon adding the layer and auto-configure zoom limits based on results. Customizing levels could then be done by users afterwards, no extra "auto-configure" button would be needed.

We might also want to provide a way to copy the tile URL / query string of existing (non-custom) layers, so users could replace them with their own zoom-customized versions by hiding the original layer and adding a clone via the custom layers dialog.

The fact that you can zoom beyond the maximum zoom level of custom layers and then end up on a gray background image is one of the most annoying bugs in brouter-web right now.

Indeed, but not only that: It would also be nice to make the maximum zoom level of BRouter-Web itself dynamically depend on the largest maximum zoom level of all currently active (base) layers, so zooming in could be done with less care to not overshoot (applying Fitt's law to zooming).

---

At the moment planning a route along camping places (or other accomodations) is very tedious, since they don't show up any more when you zoom out for an overview.

That's a bit unrelated, because limiting zoom levels for pre-configured Overpass queries is needed for performance (overloading the server and wait time on the client) as well as UI (too many results to display) reasons. This might be less than what is supported by a server on paper. What could be done is to be a bit smarter than we currently are, e.g. if there are only few results allow to zoom out more, or to group results with a Leaflet plugin (there might still be server-side performance issues, though).

As a workaround you can copy Overpass POIs to custom POIs, which are displayed for every zoom level. Currently this needs to be done manually, so something like a "star" button would be nice to have. Another workaround is to export an external Overpass query to GeoJSON and import that in BRouter-Web.

[nrenner]

Not sure what my preferred solution would be. I was also thinking about auto-detecting by 404 error responses and setting `maxNativeZoom' based on that. Not sure about adding more UI input fields.

Ideally tile servers would provide a TileJSON file with metadata. Then an URL to that could be entered instead of a tile URL, so we could read the layer config from that. But I guess nobody does that besides Mapbox? Maybe if we supported TileJSON, people could start asking tile server providers to add it?

[quaelnix]

There is already some sort of automatic detection because when you zoom in to level 19, all layers that do not support level 19 are grayed out:	Zoom level: 18	Zoom level: 19

---

The situation is even worse. If you add a custom base layer with a server which supports zoom level 19 (like: https://tile.openstreetmap.org/{z}/{x}/{y}.png) you still end up with gray tiles if you zoom in beyond level 18. :disappointed:

[pbb72]

@nrenner JOSM lets the user enter a maximum zoom value when adding a new layer. I think this works fine, though I can imagine there might be tiles that have different maximum zoom for different regions.

As for the handling of zooms beyond the maximum zoom, I'd prefer to see enlarging of the last tiles.

[rkflx]

Not sure about adding more UI input fields.

IMO we should not add more options to the sidebar, but catering for advanced use cases (see my previous comment) in the "Custom layers" dialog could still be valuable.

TileJSON file with metadata

Thanks for the link, definitely something to keep in mind. Since tile servers (i.e. the actual server software, which should provide better leverage to introduce such features compared to having to talk to each tile service provider) often require configuring zoom and bounds anyway, it might be possible to re-use that information to (partly?) auto-generate TileJSON files.

I guess the first step would be to simply ask in the respective repos (e.g. mod_tile, go_tile etc.) if there is interest.

As for the client side, there is already a Leaflet plugin (leaflet-tilejson), which should be a nice incentive and also easy for us to include.

There is already some sort of automatic detection

True, but this only applies to the layer list, not to BRouter-Web itself (i.e. its global Leaflet zoom handling), which is exactly why you can end up with gray tiles when zooming in too far. This is not only an issue with custom layers: Try the pre-configured mtbmap.cz on bikerouter.de (disabled at 19, thus shows gray tiles – compare to MtbMap from "More", which is the same map but not disabled and thus up-scales tiles at 19). In addition, even if the layer's geojson config allowed to zoom in to 20, the static limit would stop zooming at 19 already.

IIRC I needed some patching for base layers and overlay layers to allow zooming beyond 19, which was hard-capped otherwise, and this also got rid of the gray tiles. Obviously this only works when supported by the tile provider, so that's probably why there is a more sane yet unfortunate default. Also I would not be surprised if there were still more oddities lurking somewhere in the stack (each layer's config, defaults for incomplete configs or layers without config, Leaflet, our code).

gray tiles if you zoom in beyond level 18.

TLDR:

• Good news: Not if you patched it locally.
• Bad news: My quick hack will probably break other stuff, so not PR-worthy yet.

handling of zooms beyond the maximum zoom

It is not either or, both options have their uses:

• Up-scale, to allow enlarging and to avoid the layer getting hidden – often a good option for overlays, but useful for base layers too.
• Hide, to allow other layers to take over – e.g. check satellite view when zoomed in and regular OSM Carto before that.

[quaelnix]

Replacing maxZoom: 18 with maxZoom: 19 in the leaflet library does "fix" the issue:

[rkflx]

After pondering some more and exploring what the actually negative effects of my quick hack would entail, I realized we might have maneuvered ourselves in a "Perfect is the enemy of good" situation. While there are many improvements which could be done to the custom layers dialog, perhaps a simpler change could at least somewhat improve our user experience in the meantime.

Essentially, the trade-off is like this: Either we accept a large number of 404 errors for services not providing level 19 tiles, or we preemptively set the limit to 18 at the expense of gray tiles for those services actually supporting 19.

Note that we already cause 404 errors for services not even supporting 18, and we intentionally allow 19 instead of globally limiting to 18 because of some tiles in our layers directory actually being configured for 19 (some even for 22, sadly we are ignoring that). Personally I'm using 20 for satellite views, but that discussion is for another time. By allowing the global limit to differ from the default limit for custom layers and config.js layers, we are letting our users down.

IOW, as those limits currently are more of a best guess only anyway, we might as well unify them both to 19, i.e. make the trade-off a bit less conservative. I'll send a PR to that effect. Either it will be accepted as a temporary workaround until some of the other ideas mentioned above have been implemented, or it can at least be cherry-picked by interested third parties.

[twitwi]

It is not either or, both options have their uses:

* Up-scale, to allow enlarging and to avoid the layer getting hidden – often a good option for overlays, but useful for base layers too.

* Hide, to allow other layers to take over – e.g. check satellite view when zoomed in and regular OSM Carto before that.

Just to support that statement. I personally follow this issue as I'd like to be able to zoom (to high detail base layer) and have the overlays (most often the logged-in/detailed strava heatmap) scale when I zoom too much, instead of disappearing.

Thanks for the project.

[rkflx]

I personally follow this issue scale when I zoom too much, instead of disappearing

My PR is set to close this issue as fixed. I'd suggest to open separate issues for being able to auto-detect and manually configure limits in the custom layers dialog, including a switch for choosing between hiding and up-scaling. Feel free to add a link back to here.

If you want to enjoy up-scaling right now, run your own instance and configure your heatmap via a .geojson file in layers. I know it should work, because I'm using it that way.

logged-in

If you are willing to share your tile requests with a proxy, there is no need to log in via this URL.

[divulgacheur]

@nrenner Any news about the PR proposed by @rkflx ? It seems like a solid interim fix by tweaking the maxZoom. It's clear that it's not the ultimate solution, and we might see some 404s, but it does offer immediate improvements for custom layers that go beyond zoom 18.