Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Display layers for zoom levels outside the min-max range. #5436

Open
docentYT opened this issue Jan 31, 2025 · 14 comments
Open

Display layers for zoom levels outside the min-max range. #5436

docentYT opened this issue Jan 31, 2025 · 14 comments
Labels
need more info Further information is requested

Comments

@docentYT
Copy link

User Story

As a developer using maplibre, I would like to display some raster layers for zoom levels outside the min-max range so that I can display them with other layers that support these zooms.

Rationale

Adding such an option would allow the mixing of layers whose source servers do not support all zooms.
In addition, it would avoid changing the tiles in the globe projection when raster tiles are used (simply the map at the poles would be smaller, but the calculated zoom would not affect the displayed tiles). This is the feature I need most at the moment and I think this part can be implemented easily.

Impact

Without such a option, it will not be possible to display several layers when the source servers do not render the tiles for every zoom needed (minzoom and maxzoom causes the layer to disappear outside this range) and the zoom in the globe projection will always affect the resolution of the displayed tiles.

@Zaczero
Copy link

Zaczero commented Jan 31, 2025

Image

We basically want a way to reduce the blurriness of mercator->globe re-projection when looking at north/south pole. One way to that would be to limit clamp the zoom of raster tiles, reducing this effect. So for example layers at zoom 0,1,2 are never loaded and only 3 up -- even if the map is zoomed out more.

ref openstreetmap-ng/openstreetmap-ng#154

@HarelM
Copy link
Collaborator

HarelM commented Feb 2, 2025

There is no limitation to using different sources with different min-max zoom configurations.
I'm not sure I fully understand this issue.
Also, please create some jsbin for reproduction, otherwise it's hard to understand what the issue is.

@HarelM HarelM added the need more info Further information is requested label Feb 2, 2025
@docentYT
Copy link
Author

docentYT commented Feb 2, 2025

There is no limitation to using different sources with different min-max zoom configurations.

Sure but for that you'll need a tile server that renders them at a higher resolution for smaller zooms.
If, for example, you only have https://tile.openstreetmap.org/{z}/{x}/{y}.png available, what do you do to make the density of tiles for zoom 0, 1, 2 the same as for zoom 3 (and to display the same tiles as for zoom 3, just smaller)?

An example of where it would be useful:

example.mp4

@HarelM
Copy link
Collaborator

HarelM commented Feb 2, 2025

Due to how mercator works (which is the basis of the tiles) when looking at the pole a different zoom level is used.
If you want to see the same data when looking at the poles you'll need to have that data drawn into the tiles at the relevant zoom levels.
This is a limitation of the globe as we didn't want to zoom in when looking at the poles.
But I'm still not clear about the ask here...

@docentYT
Copy link
Author

docentYT commented Feb 2, 2025

you'll need to have that data drawn into the tiles at the relevant zoom levels

And this is the issue. Another real-life case: If you have a source A serving tiles at zoom 3-12 and a source B at zoom 0-10, it is not possible to display both sources at zoom 11, 12 (by scaling up source B) and at zoom 0, 1, 2 (by scaling down source A).

@HarelM
Copy link
Collaborator

HarelM commented Feb 2, 2025

I don't think that's correct. Can you please share a jsbin with this issue?

@docentYT
Copy link
Author

docentYT commented Feb 2, 2025

Globe problem: https://jsbin.com/qulujuleki/edit?html,js,output
Different sources' minzoom problem: https://jsbin.com/hemonuzubu/edit?html,js,output

@zerda-ocm
Copy link

I guess these are two unrelated problems (please correct me if I’m wrong)?

So, regarding blurriness:

The current implementation works as follows: When tilting the globe from the equator to the pole, the zoom level changes while keeping the globe the same size, resulting in different tile sets (for zoom 0...3).

What you want is: Display the tile set for zoom level 3, regardless of whether you are looking at the equator or the pole?

Demo: https://jsbin.com/gatoyoj/edit?html,js,output

@docentYT
Copy link
Author

docentYT commented Feb 2, 2025

What you want is: Display the tile set for zoom level 3, regardless of whether you are looking at the equator or the pole?

Demo: https://jsbin.com/gatoyoj/edit?html,js,output

Yes, that's what it was all about!
I see correctly that you modified the maplibre library code?

I see that when the projection changes from a globe to a flat surface you can see the zoom jump, which is expected. This could be smoothed out somehow to gradually change the zoom to the correct one.

@zerda-ocm
Copy link

I see correctly that you modified the maplibre library code?

Yes, the relevant change is in src/geo/projection/globe_utils.ts
https://github.com/zerda-ocm/maplibre-gl-js/tree/constant_zoom

I see that when the projection changes from a globe to a flat surface you can see the zoom jump, which is expected. This could be smoothed out somehow to gradually change the zoom to the correct one.

There are other issues as well, for example markers are at the wrong position between zoom 11 and 12. In other words: Just a prove of concept for now, but not ready for production.

@Zaczero
Copy link

Zaczero commented Feb 2, 2025

What you want is: Display the tile set for zoom level 3, regardless of whether you are looking at the equator or the pole?

An option to configure min zoom for a source, that will keep rendering it even if we zoom out further (currently it just disappears). This way, if zoomed out further (which also occurs at the poles automatically), it will force displaying of more, higher zoom tiles and reduce the blurriness effect.

This is just an idea and perhaps there's a better way to approach this problem. I think the general issue here is that raster source is currently visually unappealing at the globe projection (at low zoom, at poles, where the projection error is the highest). That's obviously a projection limitation but by clamping down the zoom (or other solutions) this will be less noticeable and better for the end-users :-).

@HarelM
Copy link
Collaborator

HarelM commented Feb 2, 2025

While overzooming is easy as you simply take a tile and increase its size (which this library already does), underzoom is very expensive as you need to fetch a lot of tiles in order to build the view port, which in most cases is not what you would like to achieve, a better approach would be to provide the relevant tiles at the lower zoom levels, those are usually easier to create in the server side when creating the more detailed tiles...

@docentYT
Copy link
Author

docentYT commented Feb 2, 2025

In globe view it probably doesn't make much difference, since looking from the equatorial side you can see half the globe at a higher zoom than looking from the polar side.

@Zaczero
Copy link

Zaczero commented Feb 2, 2025

@HarelM I understand this is an important consideration. However, this should be on us and not MapLibre contributors :-). The example of limiting zoom to level 3 is just for illustration and doesn't represent the final configuration, which may have a minZoom of 1 or 2. Also, the load impact on low-zoom tiles won't be as high since they are frequently accessed and often cached -- they are also less detailed and smaller in file size. By further restricting the map's minZoom, we gain more control over worst-case data loads. For example, using mapMinZoom:2 with sourceMinZoom:3 in globe projection will be fairly lightweight.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
need more info Further information is requested
Projects
None yet
Development

No branches or pull requests

4 participants