In today's SWG meeting, we approved this request because there is no clear benefit to this requirement, the potential interoperability risk is slight, and it is desirable to support CDB directly.

@jerstlouis please propose alternate text for the first paragraph of http://www.geopackage.org/spec121/index.html#zoom_levels in light of this change.

Are we making GeoPackage zoom levels equal to CDB LODs? They are not the same in the respective specs and we should consider carefully implications of conflating the two.

In a GeoPackage, zoom levels are integers in sequence that identify tile matrices in a tile matrix set that contain tiles of progressively finer spatial resolution. Adjacent zoom levels immediately precede or follow each other and differ by a value of 1.

• "from 0 to n " removed
• Change "tile matrix layers" to "tile matrices" (layers is confusing here)
• "decreasing spatial extent and " removed because that is not necessarily true (negative zoom levels in CDB have all the same extent, but different pixel width & height, and the extent only change from level 1+)

Also later in that paragraph it says:

Other "zoom other intervals" conventions use different factors

Is that second other there superfluous?

@tabinfl The idea is to allow encoding content from multiple CDB LODs in a GeoPackage.
This is possible with the new TileMatrixSet extension ( https://gitlab.com/imagemattersllc/ogc-vtp2/-/blob/master/extensions/14-tile-matrix-set.adoc ) which supports varying width tile matrices, which can represent both the CDB zones and CDB LODs ( as described here: http://maps.ecere.com/geoapi/tileMatrixSets/CDBGlobalGrid ).

Since this change is not sufficient by itself to completely satisfy the CDB LOD requirement, the SWG decided to defer this change until after 1.3. One possibility is rolling it into a new extension as described in #504.