Release Notes for OGC GeoPackage Encoding Standard v1.3.0

Publication Date: 2021-02-04

Approval Date: 2020-11-26

Posted Date: 2020-08-19

Reference number of this document: OGC 18-066r1

Reference URL for this document: http://www.opengis.net/doc/NOTE/18-066r1

Category: Release Notes

Editor: Jeff Yutzler

Title: Release Notes for GeoPackage v1.3.0

Revision Notes

COPYRIGHT

WARNING

This document is not an OGC Standard. It is distributed for review and comment. It is subject to change without notice and may not be referred to as an OGC Standard. Further, any OGC Engineering Report should not be referenced as required or mandatory technology in procurements. However, the discussions in this document could very well lead to the definition of an OGC Standard.

LICENSE AGREEMENT

Permission is hereby granted by the Open Geospatial Consortium, ("Licensor"), free of charge and subject to the terms set forth below, to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property without restriction (except as set forth below), including without limitation the rights to implement, use, copy, modify, merge, publish, distribute, and/or sublicense copies of the Intellectual Property, and to permit persons to whom the Intellectual Property is furnished to do so, provided that all copyright notices on the intellectual property are retained intact and that each person to whom the Intellectual Property is furnished agrees to the terms of this Agreement.

If you modify the Intellectual Property, all copies of the modified Intellectual Property must include, in addition to the above copyright notice, a notice that the Intellectual Property includes modifications that have not been approved or adopted by LICENSOR.

THIS LICENSE IS A COPYRIGHT LICENSE ONLY, AND DOES NOT CONVEY ANY RIGHTS UNDER ANY PATENTS THAT MAY BE IN FORCE ANYWHERE IN THE WORLD. THE INTELLECTUAL PROPERTY IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE DO NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE INTELLECTUAL PROPERTY WILL MEET YOUR REQUIREMENTS OR THAT THE OPERATION OF THE INTELLECTUAL PROPERTY WILL BE UNINTERRUPTED OR ERROR FREE. ANY USE OF THE INTELLECTUAL PROPERTY SHALL BE MADE ENTIRELY AT THE USER’S OWN RISK. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR ANY CONTRIBUTOR OF INTELLECTUAL PROPERTY RIGHTS TO THE INTELLECTUAL PROPERTY BE LIABLE FOR ANY CLAIM, OR ANY DIRECT, SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM ANY ALLEGED INFRINGEMENT OR ANY LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR UNDER ANY OTHER LEGAL THEORY, ARISING OUT OF OR IN CONNECTION WITH THE IMPLEMENTATION, USE, COMMERCIALIZATION OR PERFORMANCE OF THIS INTELLECTUAL PROPERTY.

This license is effective until terminated. You may terminate it at any time by destroying the Intellectual Property together with all copies in any form. The license will also terminate if you fail to comply with any term or condition of this Agreement. Except as provided in the following sentence, no such termination of this license shall require the termination of any third party end-user sublicense to the Intellectual Property which is in force as of the date of notice of such termination. In addition, should the Intellectual Property, or the operation of the Intellectual Property, infringe, or in LICENSOR’s sole opinion be likely to infringe, any patent, copyright, trademark or other right of a third party, you agree that LICENSOR, in its sole discretion, may terminate this license without any compensation or liability to you, your licensees or any other party. You agree upon termination of any kind to destroy or cause to be destroyed the Intellectual Property together with all copies in any form, whether held by you or by any third party.

Except as contained in this notice, the name of LICENSOR or of any other holder of a copyright in all or part of the Intellectual Property shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Intellectual Property without prior written authorization of LICENSOR or such copyright holder. LICENSOR is and shall at all times be the sole entity that may authorize you or any third party to use certification marks, trademarks or other special designations to indicate compliance with any LICENSOR standards or specifications.

This Agreement is governed by the laws of the Commonwealth of Massachusetts. The application to this Agreement of the United Nations Convention on Contracts for the International Sale of Goods is hereby expressly excluded. In the event any provision of this Agreement shall be deemed unenforceable, void or invalid, such provision shall be modified so as to make it valid and enforceable, and as so modified the entire Agreement shall remain in full force and effect. No decision, action or inaction by LICENSOR shall be construed to be a waiver of any rights or remedies available to it.

None of the Intellectual Property or underlying information or technology may be downloaded or otherwise exported or reexported in violation of U.S. export laws and regulations. In addition, you are responsible for complying with any local laws in your jurisdiction which may impact your right to import, export or use the Intellectual Property, and you represent that you have complied with any regulations or registration procedures required by applicable law to make this license enforceable.

Preface

This document provides the set of revision notes for the existing GeoPackage version 1.3.0 (OGC 12-128r17) and does not modify that standard.

This document was approved by the OGC membership on 2020-11-26. As a result of the OGC Standards Working Group (SWG) process, there were a number of edits and enhancements made to this standard. This document provides the details of those edits, deficiency corrections, and enhancements. It also documents those items that have been deprecated. Finally, this document provides implementations details related to issues of backwards compatibility.

Keywords

ogcdoc, geopackage, sqlite, raster, tiles, vector, feature, data, storage, exchange, mobile, smartphone, tablet

1. Introduction

1.1. Scope

GeoPackage is an open, standards-based, platform-independent, portable, self-describing, compact format for transferring geospatial information.

From the period of 2018 to 2020, the GeoPackage Standards Working Group (SWG) made a number of changes to the GeoPackage Encoding Standard Version 1.2.1 (OGC 12-128r15). These changes have been aggregated into version 1.3.0 of the GeoPackage Encoding Standard (12-128r16). This document describes those changes.

GeoPackage 1.3.0 is a minor revision to version 1.2.1. The minor revision designation is being used because of a number of substantive changes that alter conformance requirements. However, all of these changes were carefully considered for impact on existing implementations. Changes that were considered to have a significant impact were rejected or recast in order to limit their impact.

All changes were all managed via the GeoPackage GitHub repository. All substantive issues and most administrative issues were raised in the GitHub Issue Tracker and discussed by the SWG. Once the issue was resolved, a pull request was generated and merged into the repository. Some administrative issues such as typos were corrected directly through a commit on the master branch.

1.2. Document contributor contact points

All questions regarding this document should be directed to the editor or the contributors:

Table 1. Contacts
Name	Organization
Jeff Yutzler	Image Matters

1.3. Future Work

No future work is planned to this document.

1.4. Foreword

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.

2. References

The following normative documents are referenced in this document.

NOTE: Only normative standards are referenced here, e.g. OGC, ISO or other SDO standards. All other references are listed in the bibliography.

OGC 12-128r16, OGC® GeoPackage Encoding Standard, version 1.3.0

3. Terms and definitions

For the purposes of this report, the definitions specified in Clause 4 of the OWS Common Implementation Standard [OGC 06-121r9] and in OGC® Abstract Specification Topic TBD: TBD shall apply. In addition, the following terms and definitions apply.

3.1. administrative change

An administrative change is a change that does not alter the abstract tests for any requirements. It includes typographical errors, changes in wording to improve clarity or consistency, and perfunctory changes like changes in version numbers.

3.2. critical Change

A critical change is a change that alters requirements in a way that is known to cause reverse compatibility issues.

3.3. substantive change

A substantive change is a change that alters requirements in a way that is not deemed to have a high risk for causing reverse compatibility issues.

3.4. Abbreviated terms

CDB Common Database
CITE Compliance, Interoperability, Testing, and Experimentation
CRS Coordinate Reference System
DDL Database Definition Language
GPKG GeoPackage
LOD Levels of Detail
SQL Structured Query Language
SWG Standards Working Group
WKT Well Known Text

4. Change Log

4.1. KEY

Issue#: Issue in GitHub
PR#: Pull Request in GitHub (or commit number if no PR was made)
Type:
- A=Administrative
- S=Substantive
- C=Critical

See Description of Critical Changes for more information on critical changes and Description of Substantive Changes for more information on substantive changes.

Section: Section number in the updated document
Description: Brief text describing the change
Purpose: the reason for the change, such as:
- Clarity
- Consistency
- Interoperability
- Perfunctory
- Readability
- Usability

4.2. Change Table

Table 2. Change Log
Issue#	PR#	Type	Section	Description	Purpose
444	447	S	2.1.5.1.2, 2.2.6.1.2	Enforce alignment of SRS IDs between tables	Consistency
381, 554	479, 560	A	1.1.1.1.2.	Mention new media type	Informational
445	448, 549	A	2.1.6.1.2., A	Eliminate misleading "assignable" language	Clarity
446 and 498	449, 494, and 534	S	2.1.6.1.1, 2.2.8.1.1, 2.4.3.1.1	Clarify use of views in user-defined tables	Consistency
453	454	S	F.9	Relax R104 to allow use with attributes and extensions	Extensibility
455	477	A	multiple	Update table and figure styles	Readability
N/A	463	A	F.8	Fix typo in trigger definition SQL	Correctness
464 and 480	481	A	2.2.8.1.1	Add warning regarding need for indexing on large tiles tables	Performance
N/A	483	A	1.1.1.1.1	Bump version number	Perfunctory
438 and 442	484 and 486	A	F.3	Added note to state intent of bounding indexes since R78 was removed; Remove test for R78;	Correctness
N/A	488	A	F.12	Adding link to Related Tables Extension	Perfunctory
N/A	489	A	2.3.2.1.2	Correcting typo: scope was "write_only" and should be "write-only"	Correctness
495 and 512	496 and 513	S	F.8	Allow metadata scopes to be extended	Extensibility
498	528	A	multiple	Clarify use of AUTOINCREMENT for integer primary keys	Clarity
499	507	A	I, #34	Update normative reference for WKT2	Perfunctory
501, 539	542	A	1	Refine wording on preferred identifier names	Clarity
502	506	S	2.1.3.1.1	Create new R152 to describe empty geometries	Clarity
509	510	A	F.10 ATS	Fix typo in ATS	Correctness
N/A	510	A	Tables 4, 24, 25	Use "UK" or "Jointly Unique" throughout	Consistency
517	515	A	Multiple	Be consistent in table definition SQL for integer primary keys	Consistency
519	528	A	Multiple	Change version numbers to 1.3.0, update references to change log	Perfunctory
524	528	A	2.1.6.1.2	Clarify use of triggers in Annex D	Clarity
525	528	A	2.1.6.1.2	Clarify use of GEOMETRY geometry type name	Clarity
529, 532, and 535	518 and 537	A	F.3	Clarify rounding errors for spatial indexes and update spatial function names for consistency	Clarity, Consistency
531, 541	536, 544	A	Annex I	Update normative references to current state	Perfunctory
533	538	A	1.1.2.1	Clarify role of `srs_id` as different from `organization_coordsys_id` in `gpkg_spatial_ref_sys`	Clarity
540	545	A	2.1.3.1.1	Clarify WKB axis order	Clarity
548	559	A	2.1.3.1.1	Clarify "byte order" flag	Clarity

5. Description of Critical Changes

There are no critical changes in this release.

6. Description of Substantive Changes

6.1. Clarify use of views in user-defined tables (2.1.6.1.1, 2.2.8.1.1, and 2.4.3.1.1)

In previous GeoPackage versions, how to encode a user-defined view was unclear. In response, two changes were made to the requirements for user-defined content. First, Requirements 29, 54, and 119 were rewritten to specifically describe the rules for user defined features, tiles, and attributes tables, respectively. Second, Requirements 150, 153, and 151 were added to specifically describe the rules for user defined features, tiles, and attributes views, respectively.

There is no substantive difference to how user-defined tables are encoded, but the revised wording does clarify that such tables SHALL have primary key columns of type INTEGER and that the column SHALL act as a ROWID alias. However, the concept of primary keys does not exist in SQLite for views. In lieu of primary keys, user-defined views SHALL have an INTEGER "primary-key-like" (i.e., with unique values) column as their first column.

In addition, notes were added to the sample table definitions to clarify the use of the AUTOINCREMENT keyword and the fact that the "Null" flag is ignored by SQLite for primary key columns that are backed by a ROWID.

There are few interoperability risks to this change. These new requirements establish a new option for GeoPackage producers. Read-only GeoPackage clients will be able to use views in the same way they used tables. Read-write GeoPackage clients should be aware of the possibility that a GeoPackage contains user-defined views and react accordingly.

Note	While it is theoretically possible to implement an updateable view in SQLite through a series of triggers, the process for doing so is outside of the scope of GeoPackage 1.3.0.

6.2. Enforce alignment of SRS IDs between tables (2.1.5.1.2 and 2.2.6.1.2)

This change creates two new requirements, R146 and R147, that require SRS IDs to be consistent between gpkg_contents and the two dependent tables, gpkg_geometry_columns and gpkg_tile_matrix_set. In previous versions, this was unspecified. This ambiguity creates a potential interoperability issue because client software could confuse the values if they are different. This change also includes an explanatory note in section 1.1.3.1.2 and new abstract tests in Annex A.

There are no known interoperability risks to this change.

6.3. Allow Metadata Scopes to be extended (Annex F.8)

This change does the following three things:

Eliminates Requirement 94. This requirement made it impossible to extend the list of metadata scopes beyond those listed in Table 21, even though there was no normative reason to do so. The rigidity imposed by this requirement is a clear violation of Requirement 25 of the OGC’s Standard for Modular Specifications that governs this SWG. Eliminating these triggers would allow logically-valid extension of the metadata scope list as called for by Requirement 25.
Eliminates the Trigger Definition SQL from the Metadata Extension. As long as those triggers are there, it is not possible to add new scopes to a GeoPackage. Trigger constraints were eliminated from the rest of the encoding standard before reaching v1.0. Why these particular trigger constraints remained is unclear. This change eliminates both the metadata scope and reference scope triggers.
Adds a new metadata scope for "style". The list of metadata scopes that is currently in Table 21 is arbitrary and is clearly not limited to the scopes from ISO19115. Since OGC Testbed-15 identified a need for a new scope, it has been added.

Since there are no semantics involved with metadata scopes, eliminating this requirement poses no interoperability risks on viewing. The only potential interoperability risk would be if all of the following were true:

a GeoPackage client that was not aware of this change attempted to copy gpkg_metadata rows from one GeoPackage to another,
the source GeoPackage contains metadata scopes that were not in the original list of metadata scope (this list did not change from GeoPackage 1.0 to GeoPackage 1.2.1), and
Requirement 94 is being strictly enforced, either through code in the GeoPackage client or triggers in the destination GeoPackage.

The impact of this risk is very low. Simply deleting the offending metadata entry or modifying the offending metadata scope value would resolve the problem.

6.4. Allow Schemas to be used with Attributes and Extensions (Annex F.9)

The original Schema Extension stated that schemas are for features layers. This change loosens the restriction so that a schema may apply to attributes or extensions. This required a change to Requirement 104 which originally specified that the "table_name" from gpkg_data_columns must have a corresponding row in gpkg_contents. Since some extension tables are described in gpkg_extensions, the requirement was loosened so that the corresponding row must be in either table.

The only potential interoperability risk would be if all of the following were true:

a GeoPackage client that was not aware of this change attempted to copy gpkg_data_columns rows from one GeoPackage to another,
the source GeoPackage contains schema rows for extension tables, and
Requirement 104 is being strictly enforced through code in the GeoPackage client.

The impact of this risk is very low. Simply deleting the offending schema entry would resolve the problem.

6.5. Create new R152 to describe empty geometries (2.1.3.1.1)

Previous versions of GeoPackage underspecified the requirements for encoding empty geometries. Proper encoding of empty geometries allows features to be properly excluded from spatial queries. Failing to properly encode empty geometries can lead to false negatives (unexpectedly empty geometries) which would cause unnecessary parsing of WKB blocks. This issue also has the potential to cause problems in clients that do not expect empty geometries in features returned by spatial queries.

This change corrects this oversight starting with this version of the standard. Now when the geometry is empty, the following are mandated:

setting the "empty geometry" flag to true;
setting the "envelope contents" indicator to "0" indicating no envelope; and
if the geometry is a Point, setting each coordinate value set to an IEEE-754 quiet NaN value.

There are no known interoperability risks to this change.

7. Migration

GeoPackage 1.2.1 and 1.3.0 are almost identical. To migrate a 1.2.1 (or 1.2.0) GeoPackage to 1.3.0, execute the following SQLite commands:

pragma user_version=10300;
drop trigger gpkg_metadata_md_scope_insert;
drop trigger gpkg_metadata_md_scope_update;
drop trigger gpkg_metadata_reference_reference_scope_insert;
drop trigger gpkg_metadata_reference_reference_scope_update;
drop trigger gpkg_metadata_reference_column_name_insert;
drop trigger gpkg_metadata_reference_column_name_update;
drop trigger gpkg_metadata_reference_row_id_value_insert;
drop trigger gpkg_metadata_reference_row_id_value_update;
drop trigger gpkg_metadata_reference_timestamp_insert;
drop trigger gpkg_metadata_reference_timestamp_update;

The first command updates the internal version identifier of the GeoPackage to 1.3.0. The drop commands will drop the Metadata Extension triggers that were removed. Note that these triggers will not be present unless the Metadata Extension is in use.

8. Future Work

There is no future work for this document being planned at this time. However, the GeoPackage SWG may wish to produce another version of the GeoPackage Encoding Standard if warranted. The GeoPackage SWG may also recharter as a precursor to standardization of one or more new GeoPackage extensions.

Appendix A: Revision History

Table 3. Revision History
Date	Release	Editor	Primary clauses modified	Descriptions
June 29, 2018	J. Yutzler	.1	all	initial version
May 6, 2019	J. Yutzler	.2	all	release candidate #1
August 9, 2019	J. Yutzler	.3	all	results of SWG electronic vote
December 10, 2019	J. Yutzler	.4	4, 6	release candidate #2
February 18, 2020	J. Yutzler	.5	4, 6	release candidate #3
March 10, 2020	J. Yutzler	.9	4, 6, 7	release to OAB
May 5, 2020	J. Yutzler	.91	3, 4, 6	SWG review #1
July 20, 2020	J. Yutzler	.92	4, 6	SWG review #2
September 25, 2020	J. Yutzler	.93	7	TC review
October 7, 2020	J. Yutzler	.94	4	SWG review #3
January 7, 2021	J. Yutzler	.95	1	SWG review #3