Preparing for GeoPackage 1.0.2

The GeoPackage Standards Working Group (SWG) has voted to recommend the working version of the GeoPackage specification to the OGC Technical Committee for adoption as version 1.0.2. Because of some substantive changes that affect conformance, we decided to make version 1.0.2 a technical amendment.

I have been asked by OGC to provide release notes for this version. This is in progress and a draft version is available here [1]. For those of you who are not inclined to wade through the boilerplate text and other stuff, here is a summary of the substantive changes. (The hyperlinks at the beginning of each line point to the relevant GitHub Issue).

• 102. Requirement 45 is new and therefore there is no risk to existing implementations. Conforming to the new requirement would improve interoperability between systems.
• 130. Two columns in the Schema Extension were renamed to conform to the rule that all column names are lower case. There are no known uses of this table in the field so the risk of this change is low.
• 132. In the past, information regarding a single extension was scattered in at least four parts of the document. It was likely that a reader would not be able to find all of the relevant information about a particular extension. In addition, if a new extension was subsequently added to the document, it would change the numbering of the other annexes. In response, we decided to move all information regarding extensions into a single annex (Annex F), with one extension per sub-annex.
  While technically an administrative edit because no requirements were actually changed, a number of internal references were updated. References to numbered elements may break. (References to linked elements are unchanged.) Because of the potential impact to users of the standard (in documents, code samples, etc.), this is listed as substantive.
• 137. OGC has adopted 12-063r5, a new standard for describing coordinate reference systems as well-known text. The SWG determined that it would be too disruptive to update the references in the document to the new standard. In order to encourage adoption of the new standard, a new extension was formed. Implementations are new free to adopt the new standard at their own pace by conforming to the extension. Since this is a new extension, there is no risk to existing implementations.
• 147. Reports from the community indicated that the schema and metadata sections (formerly Sections 2.3 and 2.4 respectively) were not being used. Mandating those tables was creating work for implemententers with no tangible benefit. In response, the SWG determined that the best course of action would be to demote them to extensions. This reduces the length of the core of the standard, improving readability. Because of the lack of use, the risk of this change is low. 

The next steps are to create a PDF version of the document and to initiate a vote in the OGC Technical Committee. If I understand correctly, technical amendments can be approved via an electronic vote after an appropriate review period.

[1] Note: this file was updated on January 13. Feedback is welcome!