We Want Your (Technical) Feedback

Earlier this month, GeoPackage 1.2.1 (a corrigendum release) was approved by the OGC Technical Committee. In this release, we focused on clarifications and consistency. Look for publication and formal announcement soon. Until this occurs, you can review the release notes. 

I thought things would slow down after this but I was wrong. There has been a bunch of testing related to the Geospatial to the Edge Plugfest and this testing has revealed some areas of the standard that need to be refined. Some of these things are quite technical and I would like to get community feedback before we do anything rash. The following items have GitHub issues and corresponding pull requests. Please let us know if you think we are doing something wrong or if we can do better.

1. Support for views. We've said for the beginning that GeoPackage is supposed to support views where appropriate. We clarified this as part of version 1.2.0 and 1.2.1 but we need to do more because of our requirement for primary keys on user defined tables. The concept of primary keys does not exist for views in SQLite so we are now proposing that if there is no primary key column, then the first column must be primary-key-like, containing unique integers.
   Update: a competing approach would add a column to "gpkg_contents" to name the primary key column for a particular set of contents. I like this idea (more easily discoverable) but it may be too late to add even an optional column to that table.
2. Enforcing alignment between the CRSs in gpkg_contents, gpkg_geometry_columns, and gpkg_tile_matrix_set. I do not see how a GeoPackage can possibly be interoperable when the CRSs are not in alignment (how would a client decide which one to pick?) and I don't think anyone is doing this now, but since the question has come up more than once, we are taking the opportunity to tighten things up.
   Update: this issue was resolved.
3. Ensuring that feature geometries fall within the extents in the Well Known Binary (WKB) values. These extents are used as an optimization for spatial querying and indexing. If they are not valid (which is apparently happening on occasion), incorrect results will be returned.
   Update: This is still being discussed.

Since we are introducing new requirements as part of these changes, they are penciled in as part of a possible 1.3.0 release. We have no timeline for when this might occur but figure some time in 2019. As always, remain committed to maintaining reverse compatibility as much as possible. We will continue to avoid introducing requirements that have the potential to break existing GeoPackages unless those GeoPackages couldn't possibly work as designed.