Publication Date: 2018-mm-dd

Approval Date: 2018-mm-dd

Posted Date: 2018-xx-xx

Reference number of this document: OGC 18-066

Reference URL for this document: http://www.opengis.net/doc/PER/t13-xxx

Category: Release Notes

Editor: Jeff Yutzler

Title: Release Notes for GeoPackage v1.3.0

Revision Notes

COPYRIGHT

Copyright © 2018 Open Geospatial Consortium. To obtain additional rights of use, visit http://www.opengeospatial.org/

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-128r16) and does not modify that standard.

This document was approved by the OGC membership on approval date. 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.

Over the course of 2018 and 2019, 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

  • CITE Compliance, Interoperability, Testing, and Experimentation

  • CRS Coordinate Reference System

  • DDL Database Definition Language

  • GPKG GeoPackage

  • 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

479

A

1.1.1.1.2.

Mention new media type

Informational

445

448

A

2.1.6.1.2., A

Eliminate misleading "assignable" language

Clarity

446

449 and 494

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

499

507

A

I, #34

Update normative reference for WKT2

Perfunctory

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

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)

This change adds two new requirements, R150 and R151, to specify the rules for primary keys or primary-key like columns in user-defined features and attributes tables, respectively. While user-defined tables should have primary keys in general, the concept of primary keys does not exist in SQLite for views. These new requirements establish a new option for implementers. User-defined components that lack primary keys (presumably because they are views) must have a primary-key-like column (containing unique integers) as the first column. In previous GeoPackage versions, how to encode a view was unclear. This change also includes an explanatory note with a similar message for tiles views.

Note

This is the most complex change in this set of changes. Stakeholders agree that feature views are not viable the way the standard is currently written, but there is disagreement as to whether it is feasible to produce a primary-key-like column in all cases.

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 requires 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:

  1. 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.

  2. 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.

  3. 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 problem 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. 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