Add --largest-maximum-zoom-guess option to allow setting an upper bound limit to the guessed max zoom

[MariaSliacka]

Currently, there is only support for the lower bound value when using the -zg option to guess the max zoom:--smallest-maximum-zoom-guess=zoom.

Adding an option to also define an upper bound would prevent tippecanoe from generating milions of tiles on a very detailed data, while also working with huge polygons spanning countries where it wouldnt create unnecessary tiles.

An alternative that would fix our current problem with using -zg flag is be to be able to run a "dry-run" which would tell us what tippecanoe calculated as the expected max zoom and then use that with the usual -z flag for actual generation of tiles.

[e-n-f]

At Felt, we rely on a special case added in #23 to avoid choosing a maxzoom that would cause a large polygon to span more than 2 million tiles, and now also on the --generate-variable-depth-tile-pyramid flag added in #251 to avoid generating polygon fill tiles.

I can add the zoom level cap, but can you share a sample of data that is causing it to guess too high a zoom?

[MariaSliacka]

Thank you for such a quick reply!

We weren't aware of that special case but that's very good to know, we will experiment more with -zg to see what limits we are hitting both in terms of chosen maxzoom and number of tiles generated. Currently we are using a defined zoom of 15 but we want to move away from it and that's why we are looking for new better options. Our main concern was that some data with high coverage polygons could also include high-detailed spots and would cause creation of millions of tiles, but if that's covered already then that's perfect. However, we are worried that the 2 million limit might still be too high for us and we would rather have the option to cap the maxzoom on for example 15, but we will run few experiments to make sure. Also does the 2 million limit apply to every tiling using -zg or only when large polygons are found?

Also we are actually looking into using --generate-variable-depth-tile-pyramid as well, but are unsure of the map server changes required, do you have any suggested resources for implementation? Our worry is how to efficiently search for tiles on every zoom level to find the relevant parent tile in case of missing ones and then overzoom correctly.