search

Leaflet / Leaflet

🍃 JavaScript library for mobile-friendly interactive maps 🇺🇦
https://leafletjs.com
BSD 2-Clause "Simplified" License
40.28k stars 5.76k forks source link

maxNativeZoom and maxZoom not autoscaling #6316

Open arthur-clifford opened 5 years ago

arthur-clifford commented 5 years ago

Note: This issue being reported was originally seen in a combination of VectorGrid, MapQuest,js (standalone) and Leaflet.js. I've factored out MapQuest.js and saw the same behavior. Because the objective is to use the protobuf tiles I have left

The sample images provided include mapquest basemap tiles, but that was only to give a spatial reference in order to show problem behavior.

How to reproduce

  1. Create a map.
  2. Add a layer using VectorGrid's protobuf function.
  3. Set the maxNativeZoom relatively low (but supported by tile set, I was using 8) and set maxZoom to a higher level (I was using 25.)

What behaviour I'm expecting and which behaviour I'm seeing

As I zoomed in I expect the layer to zoom past the maxNativeZoom and fill the map.

Minimal example reproducing the issue

The data properly centered in the map:

ks_shot1

The data has been zoomed to where it fits the screen:

ks_shot2

The data is shoved into upper left corner and clipped:

ks_shot3

The data is further clipped and not really zoomed:

ks_shot4

There are a variety of issues that are reported regarding overzooming and proposals for different things that are now closed. And most stuff is from 2015. There's an older note on the VectorGrid issue tracker saying its not a VectorGrid issue its a Leaflet issue. Again, from the 2015 time frame. There's a google hit that talks about a similar problem wtih Mapbox.

However the fix is implemented the resulting renderings should not look like the images above.

There was someone asking what may be this same issue but was asking about it for more raster based tiles and there was a question as to why one would do that.

I can answer that. In Kansas, OpenStreetMap or other roads tiles only are useful in urban areas. in rural areas they are useless at higher zoom levels on say the prairie. Available aerial imagery may only go to level 25 ish (or not higher than 18) but the zoom level required for the kind of stuff my clients would like to do would need to go higher than 25. A blurry image of something identifiable as a field is better than empty imagery that causes the user to lose spatial context. For instance MapQuest tiles simply disappear after level 25 and if I could over zoom them that would be better than disappearing tiles.

For the vector data in the imagery above the max zoom level calculated by tippecanoe was level 8, but I want it to be able to go up to to at least what the MapQuest tiles are capable (level 25). without having to generate a bazillion tiles for a relative handful of polygons.

I'm using the latest releases of Leaflet (v1.3.4) and VectorGrid (and MapQuest too). The data I have isn't something I can put out for use in a fiddle. I don't know if you or the VectorGrid folks have a protobuf data set for testing with.

Or, can anybody confirm this is a problem with other vector tile data and/or raster data? Can we rule out Leaflet as the culprit, or do I/we need to point the VectorGrid folks to this issue.

IvanSanchez commented 5 years ago

There's an older note on the VectorGrid issue tracker saying its not a VectorGrid issue its a Leaflet issue.

Links, please.

Also, can you publish a fiddle/codepen/plunkr that displays this behaviour?

arthur-clifford commented 5 years ago

Older VectorGrid issue: (2017) https://github.com/Leaflet/Leaflet.VectorGrid/issues/87

arthur-clifford commented 5 years ago

Other vaguely related issues:

Sorry I didn't cross reference things earlier.

arthur-clifford commented 5 years ago

Accidentally closed.

arthur-clifford commented 5 years ago

Also: https://github.com/Leaflet/Leaflet/issues/5316 Less directly related, but maxNativeZoom related: https://github.com/digidem/leaflet-bing-layer/issues/8

arthur-clifford commented 5 years ago

I will look at making a sample data set as protobuf tiles that I can put in a public place. It will be this afternoon/evening sometime.

arthur-clifford commented 5 years ago

Sorry for the delay in getting you a plunkr: http://next.plnkr.co/edit/zKXH8DMo9dPP5YNK

I figured out what is causing the issue.

When I initially created the plunkr with the data I was loading, it worked as expected. So I compared to what I had in my site.

You'll note in the plunkr url that the script is disabling 3D with:

If you set that to false things work fine, otherwise they behave as illustrated and described above.

Thanks for asking me to do the plunkr, I had to get the tiles setup at a server I could serve from publicly and it took a bit to get everything happy, but in diagnosing the problem for you I also found the workaround for me is to stop disabling 3d which I don't think is a problem at this time in my project(s).

arthur-clifford commented 5 years ago

Addendum, if you try the plunkr url, you'll need to zoom into Kansas, i didn't setup the map extent.

IvanSanchez commented 5 years ago

OK, so then this seems like a problem with CSS scaling.

By any change does this happen in different browsers? I wonder if the bug starts appearing when the scaled elements reach a certain size.

arthur-clifford commented 5 years ago

I tried in Edge, Chrome, and FireFox and the issue is consistent in all three.

agromanager commented 1 year ago

HI Is this issue fixed? We have the same problem with the L_DISABLE_3D = true. But the performance increase makes met want to disable to 3D but then the scaling is not working.

Greetings Agromanager

TheNumenorean commented 4 weeks ago

I am also seeing this problem; any chance it has been looked into?