Powers-of-Two Scale Sets

When we built the GeoPackage standard, there was a big push to limit tile sets to powers-of-two zoom levels. This is how most tile-based web maps (Google Maps, OpenStreetMap, etc.) work and there is a certain wisdom to it from a simplicity standpoint. However, I pushed back on this limitation for three reasons:

1. Existing cartographic products are based on a fixed scale which is some round number. When a cartographer designs a map to look right at 1:100,000 or 1:25,000 or whatever, it does not make sense to rescale it to 1:136,495 or 1:34,124[1] or some other arbitrary rational number.
2. Image products require a lossy transformation process to convert the raw (or base) image to a scale that matches the tile set. This transformation reduces image quality. When someone goes through the effort of collecting imagery at 0.5m (or better), it is a shame for that content to be degraded unnecessarily before reaching the end user.
3. When people look at imagery, they are not interested in looking at the second-highest zoom level. It just doesn't happen - they either zoom out enough to get their bearings or they zoom in as far as they can. If your tile set is based on powers-of-two, your second-highest zoom level adds about 25% of waste.

It doesn't have to be this way. "Because it is easier for the developer" is not a good justification for reducing quality or wasting space. Besides, It is not that hard for an application to look up a tile set and provide an appropriate set of zoom levels. 

Alas, we compromised by relegating support for non-powers-of-two zoom levels to an extension. I will be interested to see what happens as organizations commit to distributing raster products (especially imagery products) via GeoPackage and the ramifications of the powers-of-two approach become more apparent.

---

[1] These values are for the equator; the values at ±30° latitude are about 3.5% lower.