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
It uses the original file size to number of tiles ratio to find the minzoom. Is this the best heuristic, since formats which compress worse (geojson vs shp) will have a higher minzoom for the exact same data.
Is this the best heuristic, since formats which compress worse (geojson vs shp) will have a higher minzoom for the exact same data.
Also, datasets with varying density have issues (see #140). This is definitely not the best heuristic, but it is also incredibly efficient compared to other algorithms that we've tried out -- like trying to get a sense of vertex density or rendering tiles optimistically until you hit a threshold. Definitely open to other ideas for other ways to assess this though!
I'm trying to understand the minzoom calculation logic at
mapnik-omnivore/lib/utils.js
Line 6 in 805d115
It uses the original file size to number of tiles ratio to find the minzoom. Is this the best heuristic, since formats which compress worse (geojson vs shp) will have a higher minzoom for the exact same data.
Secondly the automated minzoom I'm seeing is too high. Here is a sample file to demonstrate, if that link doesn't work, it's the last file here
As a SHP file the minzoom is set as 5, the exact same data as a GEOJSON file the minzoom is set as 6.
In practice, that sample file needs to show up at least at minzoom 3 but ideally all the way out to minzoom 0.
I ran tile-live-copy with minzoom=1 and the tile created for zoom 1 is only 1.4KB so it's not that huge is it?
EDIT: I assume this code is what's being used when I upload a new Tileset in Mapbox Studio, as that's where I'm running into this issue.
The text was updated successfully, but these errors were encountered: