You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
You only generate ocean tiles up to z10, and then MapLibre overzooms when rendering the map, so the map appears visually correct (if a bit rough around the edges, due to overzooming a simplified geometry).
But when you merge, we have to pick a single maxzoom for the merged pmtiles. We pick the highest one, i.e. z14. But now your z10 ocean layer is no longer eligible for overzooming.
Should we do anything special here? For now, I think leave it as a footgun, and expect users to do whatever makes sense for their case. Hopefully real world use will inform what the policy, if any, should be.
The text was updated successfully, but these errors were encountered:
cldellow
added a commit
to hikeratlas/basemap
that referenced
this issue
Jan 13, 2024
when developing, it can be handy to have an expensive slice configured with a lower maxzoom than the rest of your map.
For example, if you had two slices:
You only generate ocean tiles up to z10, and then MapLibre overzooms when rendering the map, so the map appears visually correct (if a bit rough around the edges, due to overzooming a simplified geometry).
But when you merge, we have to pick a single maxzoom for the merged pmtiles. We pick the highest one, i.e. z14. But now your z10 ocean layer is no longer eligible for overzooming.
Should we do anything special here? For now, I think leave it as a footgun, and expect users to do whatever makes sense for their case. Hopefully real world use will inform what the policy, if any, should be.
The text was updated successfully, but these errors were encountered: