Clean-up in Section 2

We made a mistake and it is time to clean it up. Two sub-sections in the GeoPackage Specification, Schema and Metadata, have failed to provide any measurable benefit to users. I believe they were added to the specification with the best of intentions. Alas, as far as I can tell GeoPackage providers have been leaving the tables blank and even when they have been populated, they were not being read by clients. In the end all we are doing is making more work for people by making the presence of these tables mandatory.

In response, the Standards Working Group (SWG) voted to relegate the two sections into extensions. We will not remove these sections entirely but they will no longer appear in Section 2. As described separately, we have already agreed to compile all OGC-approved extensions into a single Annex. These changes will shorten the core of the standard and make the whole document more organized. We hope that this will make it more palatable to implementers. I plan to do the reorganization over the course of the next two weeks.

Meanwhile, the SWG's work is not done on this topic. I would like to reach the point that implementers look for opportunities to support extensions like these that do exist. Emerging profiles such as the National System for GeoINT Profile will use them and that is a good start.
To get beyond that, we will need to make a stronger case for the community benefits of providing this information.

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.