Open Geospatial Consortium

Submission Date: 2019-08-22

Approval Date:   2019-09-16

Publication Date:   2019-11-25

External identifier of this OGC® document: http://www.opengis.net/doc/DP/proposed-gpkg-enhance

Internal reference number of this OGC® document:    19-047

Category: OGC® Discussion Paper

Editor:   Jeff Yutzler

Proposed OGC GeoPackage Enhancements

Copyright notice

Copyright © 2019 Open Geospatial Consortium

To obtain additional rights of use, visit http://www.opengeospatial.org/legal/

Warning

This document is not an OGC Standard. This document is an OGC Discussion Paper and is therefore not an official position of the OGC membership. 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, an OGC Discussion Paper should not be referenced as required or mandatory technology in procurements.

Document type:    OGC® Discussion Paper

Document subtype:

Document stage:    Approved for public release

Document language:  English

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.

i. Abstract

The Open Geospatial Consortium (OGC) GeoPackage Encoding Standard was developed for the purpose of providing an open, standards-based, platform-independent, portable, self-describing, compact format for transferring geospatial information. GeoPackage has proven to be an effective "container" mechanism for bundling and sharing geospatial data for a variety of operational use cases. However, GeoPackage stakeholders have observed persistent interoperability issues, particularly with regards to metadata, extensions, and portrayal.

This paper presents the operational need, proposed approach, and way ahead for addressing these interoperability issues. Section 6 presents three new enhancements (extensions) that are designed to improve the interoperability of GeoPackages in general and metadata in particular. Section 7 presents a vision for implementing an Open Portrayal Framework in GeoPackage. Annex A presents specifications for all of the GeoPackage extensions proposed in this paper. Annex B presents a JSON schema for the proposed encoding for application profiles presented in Section 6. In general, the GeoPackage Standards Working Group (SWG) looks to standardize extensions that address a clear use case, have a sound technical approach, and have a commitment to implementation by multiple organizations. As with the GeoPackage Tiled Gridded Coverage Extension and the GeoPackage Related Tables Extension, these new extensions would be tracked as separate documents from the core GeoPackage Encoding Standard.

The GeoPackage community will benefit from the increased interoperability of operational “mission-ready” GeoPackages that will result from this approach. Additionally, software will be able to quickly determine the validity and utility of a GeoPackage in target operational environments. This will help ensure that GeoPackage production-consumption lifecycles and supporting application tools and services are better aligned with stakeholder missions.

ii. Keywords

The following are keywords to be used by search engines and document catalogues.

ogcdoc, OGC document, geopackage, metadata, profile, application, sqlite

iii. Preface

Note

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.

iv. Submitting organizations

The following organizations submitted this Document to the Open Geospatial Consortium (OGC):

Organization name(s):

  • Image Matters LLC

All questions regarding this submission should be directed to the editor or the submitters:

  • Jeff Yutzler, Image Matters LLC

  • Gate Jantaraweragul, Image Matters LLC

  • Carl Reed, Carl Reed and Associates

1. Scope

The goal of this Discussion Paper is to spread awareness of the way ahead for resolving GeoPackage interoperability issues that have been observed by the implementation community.

2. Conformance

This Discussion Paper defines draft specifications for a number of GeoPackage extensions. However, normative requirements for these extensions have not yet been developed. Therefore, conformance with this Discussion Paper is not applicable.

3. References

The following normative documents contain provisions that, through reference in this text, constitute provisions of this document. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply. For undated references, the latest edition of the normative document referred to applies.

IETF: RFC 7946: The GeoJSON Format, https://tools.ietf.org/html/rfc7946 (2016)

OGC: OGC 05-078r4, OpenGIS Styled Layer Descriptor Profile of the Web Map Service Implementation Specification (2007)

OGC: OGC 12-128r15, OGC® GeoPackage Encoding Standard Version 1.2.1, http://www.geopackage.org/spec121 (2018)

OGC: OGC 18-000, OGC GeoPackage Related Tables Extension, http://docs.opengeospatial.org/is/18-000/18-000.html (2019)

4. Terms and Definitions

This document uses the terms defined in Sub-clause 5.3 of [OGC 06-121r8], which is based on the ISO/IEC Directives, Part 2, Rules for the structure and drafting of International Standards. In particular, the word “shall” (not “must”) is the verb form used to indicate a requirement to be strictly followed to conform to this Best Practice.

For the purposes of this report, the definitions specified in Clause 4 of the OWS Common Implementation Standard OGC 06-121r9 shall apply. In addition, the following terms and definitions apply.

  • Conceptual Model (CM)

    ISO defines a "conceptual model" as "a model that defines concepts of a universe of discourse" in https://www.iso.org/standard/69325.html[ISO 19101].
In the field of computer science, CM is a particular case of a general conceptual model which is also called a domain model.
In this ER, CM is an abstract model to represent the abstract concepts, relevant term, basic entities, their behavior (or attributes) and their relationships used by domain experts.
A CM is explicitly chosen to be independent of a specific design, encoding or implementation concerns.

  • Extended GeoPackage

    A GeoPackage that contains any additional data elements (tables or columns) or SQL constructs (data types, indexes, constraints or triggers) that are not specified in the OGC GeoPackage encoding standard.

  • Feature

    Representation of some real-world object or phenomenon, e.g. a building, a river, or a person. A feature may or may not have geometric aspects.

  • GeoJSON

    GeoJSON is an open standard format designed for representing simple geographical features, along with their non-spatial attributes. It is based on JSON, the JavaScript Object Notation. The geometries of features include points, line strings, polygons, and multi-part collections of these types (source: https://tools.ietf.org/html/rfc7946).

  • GeoPackage file

    A platform-independent SQLite database file that contains geospatial data and metadata tables with specified definitions, integrity assertions, format limitations and content constraints, all of which comply with the requirements stated in the OGC GeoPackage encoding standard.

  • Interoperability

    The capability to communicate, execute programs, or transfer data among various functional units in a manner that requires the user to have little or no knowledge of the unique characteristics of those units (source: https://www.iso.org/standard/59221.html[ISO 19119]).

  • Layer

    The basic unit of geographic information that may be requested as a map from a server.

  • Map

    A pictorial representation of geographic data.

  • Model

    Abstraction of some aspects of a universe of discourse https://www.iso.org/standard/59193.html[ISO 19109].

  • Portrayal

    Portrayal presentation of information to humans https://www.iso.org/standard/46226.html[ISO 19117].

  • Stylable Layer Set

    A StylableLayerSet is a set of layers (those identified as associated with that StylableLayerSet) to which a particular set of style sheet documents (those associated with that StylableLayerSet) can be applied to.
The multiple layers within a multi-layer tile set would typically be associated with a unique StylableLayerSet. A StylableLayerSet could also be shared by multiple tile sets meant to be used together (especially when each tile set contains a single layer), or by a group of tile sets or layers following the same schema(s).

  • Style

    Styles provide the mapping from feature types and feature properties and constraints to parameterized symbols used in drawing maps. (source: OGC Glossary of Terms)
A style organizes the rules of symbolizing instructions to be applied by a rendering engine on one or more geographic features and/or coverages. (from working group consensus Jan 18, 2019)

  • Style Set

    A style set is a label for a group of style sheets which would typically be unique for a multi-layer tile set.
A style set could also be shared by multiple tile sets meant to be used together, each containing a single layer, or a group of tile sets with the same schema.

  • Style Sheet

    A style sheet is a container for styling rules for a single layer or for multiple layers.

  • Styles API

    A Web API for accessing, uploading, deleting and editing styles.

  • Tile

    A geometric shape with known properties that is the result of the tiling (tessellation) of a plane. A tile consists of a single connected "piece" without "holes" or "lines" (topological disc).

  • Tile Set

    A set of tiles with common properties that meets the definition of a tessellation. In short, a collection of subsets of the plane, i.e. tiles, which cover the space without gaps or overlaps.
Note

A comment on the correct terminology for 'Vector Tiles' is appropriate before continuing. The decision made by the participants is as follows: When explicitly referring to the conceptual model and addressing tiled point, poly-line and polygon data in a formal context the correct terminology is Tiled Feature Data. When discussing the initial pilot, the extension work and the associated extensions using the terms 'Vector Tile(s)' is accepted.

4.1. Abbreviated terms

  • BLOB Binary Large OBject

  • CDS Concept Development Study

  • COTS Customer Off The Shelf

  • CRS Coordinate Reference System

  • CSS Cascading Style Sheets

  • DDIL Denied, Degraded, Intermittent, or Limited

  • GeoJSON Geospatial JavaScript Object Notation

  • GPKG GeoPackage

  • KML Keyhole Markup Language

  • JSON JavaScript Object Notation

  • MVT Mapbox Vector Tiles

  • OGC Open Geospatial Consortium

  • OPF Open Portrayal Framework

  • OWS OGC Web Services

  • RTE Related Tables Extension

  • SLD Styled Layer Descriptor

  • SRS Spatial Reference System

  • SWG Standards Working Group

  • VT Vector Tiles, Vector Tiling, Vectiles

  • VTP Vector Tiles Pilot

  • VTPExt Vector Tiles Pilot Extension

  • WFS Web Feature Service

  • WMS Web Map Service

  • WMTS Web Map Tile Service

  • XML eXtensible Markup Language

5. Conventions

The GeoPackage database diagrams in section 6 are a modified form of Unified Modeling Language (UML) class diagrams. Tables are indicated with a T icon. Tables are grouped logically into packages for presentation purposes, but this logical structure is not actually reflected in the database itself. Solid arrows indicate a foreign key relationship via the labeled property. Dashed arrows indicate a table name reference via the named column. Where relevant, an * indicates a multiplicity of 1..n. PlantUML was used to render the diagrams from plain text.

GeoPackage extensions in Annex A are developed in accordance with the GeoPackage Extension Template.

The schema in Annex B.1 is developed in accordance with JSON Schema draft 07.

6. GeoPackage Proposals (Informative)

6.1. Metadata Profiles

GeoPackage has supported metadata since version 1.0. In version 1.0, metadata was supported through the metadata option. In version 1.1, this section of the standard was relegated to an extension so that it would be more consistent with other parts of the GeoPackage standard. This approach has proven to not be enough of a change. The Metadata Extension is rarely being used operationally and effective GeoPackage client support for metadata is even less common.

The contributors to this paper believe that while the Metadata Extension is potentially a very powerful tool, the mechanism is insufficiently defined to be workable operationally. There is currently no agreement on the meaning and significance of metadata in GeoPackage or how that metadata should be used to serve any particular purpose. In addition, someone opening a GeoPackage would have no way of recognizing that the file has any particular type of metadata in it. They would have to inspect every single row in the gpkg_metadata table. This lack of guidance places an unreasonable demand on developers.

This paper presents an approach for addressing these gaps by introducing GeoPackage "metadata profiles". A metadata profile is an agreement on what a metadata document will look like and how it will be used in a GeoPackage. The proposal is to leverage the extension mechanism to hold the information that expresses this agreement. The proposed approach has two parts:

  • Creating a new extension that defines a new extension "scope" (i.e., the gpkg_extensions.scope column) of "metadata"

  • Creating an extension for each metadata profile that describes the meaning and significance of a particular type of metadata

6.1.1. Metadata Extension Review

Before delving deeper into the metadata proposals, reviewing the Metadata Extension as it exists today may be beneficial. The following content is drawn from the GeoPackage Getting Started Guide.

The extension provides a means to store metadata in a GeoPackage and relate it to content already in the GeoPackage. There is no GeoPackage requirement that any such metadata be provided. This extension simply provides a mechanism for storing such information. The metadata extension is agnostic with regards to the metadata model and/or standard used. Metadata may be encoded in accordance with any authoritative metadata specification and in any content encoding.

gpkg_extensions

To use this extension, add the following rows to [this table](http://www.geopackage.org/spec121/#gpkg_extensions_cols).

table_name column_name extension_name definition scope

gpkg_metadata

NULL

gpkg_metadata

http://www.geopackage.org/spec121/#extension_metadata

read-write

gpkg_metadata_reference

NULL

gpkg_metadata

http://www.geopackage.org/spec121/#extension_metadata

read-write
gpkg_metadata

Add a row to [this table](http://www.geopackage.org/spec121/#gpkg_metadata_cols) for each metadata document.

Column Value

id

primary key

md_scope

[Metadata Scope](http://www.geopackage.org/spec120/#metadata_scopes) - default "dataset"

md_standard_uri

Uniform Resource Identifier (URI) reference to the metadata structure definition authority (e.g., http://metadata.ces.mil/dse/ns/GSIP/nmis/2.2.0/doc for the NSG Metadata Implementation Specification (NMIS))

mime_type

MIME encoding of metadata (e.g., text/xml)

metadata

The actual metadata document
gpkg_metadata_reference

Add a row to [this table](http://www.geopackage.org/spec121/#gpkg_metadata_reference_cols) for each GeoPackage, table, column, row, or row/column that has a metadata document. Multiple rows can refer to a single gpkg_metadata entry. It is also possible for an element (geopackage, table, column, row, or row/column) to have multiple metadata documents.

Column Value

reference_scope

one of "geopackage", "table", "column", "row", or "row/col"

table_name

user-defined table name (or NULL for whole GeoPackage)

column_name

for reference_scope of "column" or "row/col", column name in user-defined table (NULL otherwise)

row_id_value

for reference_scope of "row" or "row/col", the row ID (NULL otherwise)

timestamp

timestamp value in ISO 8601 format

md_file_id

Foreign key to gpkg_metadata

md_parent_id

Foreign key to the parent metadata document (if applicable, NULL otherwise)

6.1.2. Metadata Profiles Implementation

A metadata profile is an optional agreement on how metadata is to be used in a GeoPackage to meet a particular purpose. Through the GeoPackage extension mechanism, a community of interest MAY define one or more metadata profiles that specify the encoding, scope, and purpose of a particular type of metadata. Without this mechanism, a GeoPackage client would be forced to inspect all metadata content to respect an out-of-band (non-machine-encoded) agreement to determine how metadata is being used in that GeoPackage.

The contributors to this paper propose implementing metadata profiles through the following:

  • A new extension that adds add a new "scope" value to gpkg_extensions of "metadata" (as opposed to "read-write" or "write-only") to differentiate it from other extension types.

  • A new extension with this scope to capture the rules and use for each specific metadata profile.

These changes would be backward compatible because applications not familiar with metadata profiles would simply ignore them.

The proposed approach is demonstrated through the examples presented in the following subsections.

Styles Metadata

Testbed-15 participants identified a need for metadata for styles. In conjunction with a Styles Extension (see GeoPackage Open Portrayal Framework (Informative)), a metadata profile would describe the style metadata. Figure 1 illustrates the relationship between the relevant GeoPackage tables when this metadata profile is in use.

styles metadata
Figure 1. GeoPackage Styles Metadata Model
Dataset Provenance

By default, there is no indication of where the data for particular GeoPackage content originated. If in-field updates are to be possible, a GeoPackage client would need some way of knowing the origin of the data. By adding metadata documents for each layer to a GeoPackage, a GeoPackage client would have the information necessary to perform delta updates. There are two candidate encodings for this information, each captured in a separate draft metadata profile:

Figure 2 illustrates the relationship between the relevant GeoPackage tables when this metadata profile is in use.

contents metadata
Figure 2. GeoPackage Dataset Provenance Model
Delta Updates

Some GeoPackage stakeholders have identified a need to track updates to a GeoPackage, for example, in a disconnected mode. This would potentially allow those updates to be tracked, reviewed, and applied to another repository. GeoPackage is a single-user database with no built-in security so any management of updates beyond version and checksum will rely on the trustworthiness of software and users. With that understanding, the GeoPackage Metadata Extension supports the elements needed to track updates made locally.

The contributors to this paper propose a delta updates metadata profile. This profile includes the following:

  • A single row can be added to gpkg_metadata for each collection (editing) session. The contributors to this paper propose to use an OWS Context document containing citation information as the metadata document.

  • Then a row can be added to gpkg_metadata_references for each edit. That row can reference a row or row/column combination.

This metadata profile can be used in conjunction with the dataset provenance metadata profile discussed in the previous section to enable in-field delta updates. Even if this mechanism is not in place, delta updates can still be performed after-the-fact through these tables.

Figure 3 illustrates the relationship between the relevant GeoPackage tables when this metadata profile is in use.

delta updates
Figure 3. GeoPackage Delta Updates Model
Note

This metadata profile is similar to what was originally presented in the GeoPackage Encoding Standard as hierarchical metadata example number 2.

6.1.3. Way Ahead

The contributors to this paper intend to present this concept to OGC’s Metadata Domain Working Group (DWG). If the DWG is amenable to the approach, it may lead to an interoperability experiment. Individual metadata profiles would need to be developed independently and standardized if they are to be required operationally.

Note

The GeoPackage SWG considered this approach in July 2019, but did not agree to accept it at that time. One possible reason for the motion’s failure to pass is that things were moving too quickly and that this was too important to be rushed with minimal discussion and experimentation.

6.2. Application Profiles

The GeoPackage community wants GeoPackage to be interoperable, but it is not easy to achieve interoperability in an ecosystem that is extensible by design. The GeoPackage community has observed persistent interoperability issues in GeoPackage use, particularly when participants make use of GeoPackage’s open-ended extension mechanism. Multiple interoperability experiments have demonstrated that the desired level of interoperability has not been achieved yet. In particular, organizations that want to use GeoPackages from disparate sources are not having great success. Feedback from the GeoPackage community includes the following:

  • GeoPackage has many degrees of freedom, including but not limited to extensions e.g., Spatial Reference Systems (SRSs), geometry types, tile matrix sets, tile formats, etc.;

  • Conformance to the standard is no guarantee of interoperability, and;

  • There is currently no clear way to determine whether a client will be able to fully use the information available in a particular GeoPackage.

While the gpkg_extensions table declares what extensions are in use, this is not proving to provide sufficient information. There are some options that are not explicitly defined through this mechanism and cannot be determined without a row-by-row scan of GeoPackage data tables. This is a convoluted process that would add unreasonable time to GeoPackage loads.

The contributors to this paper propose improving interoperability by introducing application profiles to GeoPackage. An application profile would categorize and itemize a set of optional elements for a particular GeoPackage. Application profiles have a role for communities of interest, GeoPackage producers, and GeoPackage clients. Application profiles could be implemented operationally through three incremental capabilities described in the following subsections.

6.2.1. Ad-hoc Agreements

In some circumstances, it may be sufficient to have an ad-hoc agreement (verbal or written) on what GeoPackage options are to be used in a particular scenario. Communities of Interest could attempt to convey the specific options that are permitted and required for GeoPackages and GeoPackage clients. GeoPackage producers could attempt to convey what types of business objects have been added to a GeoPackage (feature, layer, map, 3D scene, observation, etc.) and what options were used to manage that information. Meanwhile, GeoPackage consumers would attempt to convey the specific GeoPackage elements that their software supports. While this "checklist" approach is difficult to enforce, it is a reasonable stop-gap that would potentially work in closed ecosystems.

6.2.2. Machine-readable Manifests

The standard will benefit from a uniform manner capturing the information described in the "Ad-hoc Agreements" above. Use of machine-readable documents would provide a robust way to convey that information in a way that can be verified and enforced completely through software. The proposal is for a new metadata profile (metadata scope: "manifest", reference scope: "geopackage") and a new metadata document that captures this information. Annex B contains the working version of the JSON Schema for GeoPackage Application Profiles along with an example document. Ideally the JSON Schema should be standardized, but that is outside of the scope of this discussion paper.

Note

The metadata scope of "manifest" is new and not currently on the list of approved metadata scopes.

This capability would benefit communities of interest, GeoPackage producers, and GeoPackage consumers.

  • Communities of interest would be able to publish application profiles that encapsulate the allowed optional and required set of options for a GeoPackage within that community. Communities of interest could also encourage the development and use of software that can produce an application profile, add a manifest to a GeoPackage, and/or validate that the contents of a particular GeoPackage conform to its manifest.

  • GeoPackage producers will be able to clearly and consistently convey the specific content that have been added to a GeoPackage and then validate that the content is encoded in accordance with the standard.

  • GeoPackage clients will be able to readily validate and/or exploit "mission-ready" GeoPackage contents and notify users when a GeoPackage contains elements that the software is not designed to handle.

When this capability is in place, there should be no confusion about whether GeoPackages can be used operationally in a given domain or application environment.

6.2.3. Bill of Materials

Application profiles may also be used as a "bill of materials" that specifies a set of options that may be incorporated into a GeoPackage. Allowing GeoPackage consumers to provide a bill of materials with a GeoPackage production request would allow a GeoPackage producer to produce a GeoPackage that only uses white-listed set of options. The ensuing GeoPackage would still contain a manifest and, by agreement, this manifest would only contain elements that were present in the bill of materials.

6.2.4. Way Ahead

The next step would be an interoperability experiment to determine if application profiles can be produced, shared between participants, and encoded into GeoPackages as manifests. An interoperability experiment would also provide an opportunity for participants to review the JSON encoding and recommend changes before it becomes standardized. As with other metadata profiles, the metadata profile for manifests would need to be standardized. The GeoPackage community would also benefit from open tools to produce application profiles, encode them into GeoPackages as manifests, validate that GeoPackages conform to their own manifests, and produce GeoPackages that conform to a bill of materials.

6.3. Semantic Annotations

Interoperability is greatly hindered when formal semantics are lacking from data descriptions. There is an unbounded set of ancillary information that may be operationally relevant to GeoPackage users. Members of the GeoPackage community have periodically proposed adding additional columns to existing GeoPackage tables to address one-off operational needs. Adding additional columns to existing tables introduces interoperability risks and does not necessarily meet operational needs due to their unclear semantics.

In response, the a new extension to allow Semantic Annotations to be placed on any GeoPackage business objects is proposed. The schema for a Semantic Annotation is straight-forward, including resolvable URIs and types along with a human-readable name and description. Semantic Annotations are linked to business objects via the Related Tables Extension.

There is a wide range of ways these annotations can be used, including but not limited to real-time context-sensitive behaviors during mission operations. Some examples of these scenarios are presented in the following subsections. For non-semantically-aware systems, a semantic annotation is effectively a "category" or tag.

6.3.1. Example 1: Linking Layers to Styles

As the OGC develops its vision for an open portrayal framework, the coupling of styles and layers is unclear. Since the styles that will work for a particular layer are independent of the data (and may be produced by one or more completely different organizations), a loose coupling between layers and styles is preferred. By annotating layers (regardless of content type) with known valid styles, a GeoPackage client may provide a user a reasonable set of style options to choose from. Whether the styles are stored directly in the GeoPackage or are accessible through a separate style service, the client will be able to retrieve the styles and apply them to the data in the layer.

Figure 4 illustrates the relationship between these tables when these semantic annotations are in use.

styles
Figure 4. Model for Layer-to-Style Semantic Annotations

6.3.2. Example 2: Stylable Layer Sets

The "stylable layer set" concept was introduced to group multiple styles that apply to the same data set or schema. For example, a stylable layer set could apply to a theater of operations and could group a set of styles (e.g., "topographic", "satellite overlay", and "night") The original proposal called for a column to be added to a pair of tables, but the semantic annotation approach would be more flexible and could be applied to any content type. In this case, both the layers and the styles could be annotated with one or more stylable layer sets.

Figure 5 illustrates the relationship between these tables when these semantic annotations are in use.

stylable layer set
Figure 5. Model for Semantic Annotations for Stylable Layer Sets

6.3.3. Example 3: Layer-to-Layer Linking

When a GeoPackage contains a relatively large volume of vector data (either in conventional or tiled layers), it is a recommended practice to pre-render raster tiles that cover a large geographic area. This reduces the need to render extreme numbers of features at run-time. In scenarios where a full OWS Context is considered to be over-kill for the scenario, a simple semantic annotation can be used to link vector and raster layers that represent the same underlying data.

6.3.4. Way Ahead

As with other GeoPackage capabilities, this would be implemented in GeoPackage as an extension that would require its own maintenance cycle, including an interoperability experiment to vet the approach and standardization as an independent document.

7. GeoPackage Open Portrayal Framework (Informative)

The goal of the OGC Open Portrayal Framework (OPF) is to allow production of high-quality digital maps over the web from existing vector data. This section describes the challenges and proposed mitigations specifically for GeoPackage producers and clients. Figure 6 illustrates a generalized view of a spatial data infrastructure. As shown on the left side of the diagram, features and styles are often developed independently of each other. A data producer may not have any knowledge of the portrayal requirements which are often the purview of a completely different organization. A successful OPF must also account for the possibility that there is a many-to-many relationship between potential data sources and potential visualizations.