Publication Date: 2021-01-13

Approval Date: 2020-12-14

Submission Date: 2020-11-16

Reference number of this document: OGC 20-019r1

Reference URL for this document: http://www.opengis.net/doc/PER/t16-D010

Category: OGC Public Engineering Report

Editor: Jeff Yutzler

Title: OGC Testbed-16: GeoPackage Engineering Report

OGC Public Engineering Report

COPYRIGHT

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

WARNING

This document is not an OGC Standard. This document is an OGC Public Engineering Report created as a deliverable in an OGC Interoperability Initiative and is 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, any OGC Public 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.

Table of Contents

1. Introduction

1.1. Executive Summary

The OGC GeoPackage Standard has grown substantially in popularity in the Geospatial community. The GeoPackage Encoding Standard was originally developed to provide an open, standards-based platform for transferring and using geospatial information which is platform-independent, portable, self-describing, and compact. In the Testbed-16 GeoPackage activity, the participants developed ways to:

  • Improve the interoperability of GeoPackages through better metadata, and

  • Improve the performance of extremely large GeoPackages so that the format itself is no longer the limit on the size of datasets that can be distributed.

Previous work suggested three specific GeoPackage limitations:

  1. The ability to discover what geospatial content is in a GeoPackage so that a client can assess the type of data contained in a GeoPackage and to determine how it may be processed effectively,

  2. Lack of a standard ability to share portrayal information (styles and symbols) via GeoPackage, and

  3. Poor performance when loading and processing very large GeoPackage vector datasets in client software.

In Testbed-16, participants researched ways to mitigate these limitations, particularly in the context of the Ordnance Survey (OS) MasterMap Topography datasets. The Testbed activity also made use of OS Open Zoomstack, a smaller, freely available, multi-scale dataset. To address the first two limitations, Testbed participants developed GeoPackage metadata profiles designed to advance the discoverability of the contents of a GeoPackage and exchange the OS portrayal styles and symbols. The metadata proved to be interoperable between the server and client implementation.

To address the third limitation, Testbed participants developed a profile of GeoPackage suitable for OS MasterMap data and performed controlled experiments on GeoPackages that used different techniques designed to improve performance. The profile was designed to improve performance by reducing overall GeoPackage size, segment data into smaller GeoPackages, and optimize the ordering of the feature identifiers. OS MasterMap data proved to be an ideal test case due to its size and complexity. The participants demonstrated that large amounts of feature data could be distributed via the GeoPackage Encoding Standard in a manner that maximizes the efficiency of data access.

Based on the results of these tests, the participants recommend that these techniques be used by other GeoPackage-supporting software systems so that these techniques emerge as interoperable solutions. Standardization of these approaches may make it easier for other systems to be able to implement these new capabilities. As a result, the participants proposed a number of change requests and community extensions that are candidates for standardization as part of the GeoPackage ecosystem.

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 Role

Jeff Yutzler

Image Matters

Editor

Andrea Aime

GeoSolutions

Contributor

Adam Parsons

Compusult

Contributor

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

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 shall apply. In addition, the following terms and definitions apply.

● controlled vocabulary

Controlled vocabularies provide a way to organize knowledge for subsequent retrieval and use. They are used in subject indexing schemes, subject headings, thesauri,[1][2] taxonomies and other forms of knowledge organization systems. Controlled vocabulary schemes mandate the use of predefined, authorized terms that have been preselected by the designers of the schemes, in contrast to natural language vocabularies, which have no such restriction. The use of controlled vocabularies in standards such as CDB can significantly increase interoperability and consistent understanding of the semantics. Controlled vocabularies typically are managed through formal processes and official governance.

● coordinate reference system

coordinate system that is related to the real world by a datum term name (source: ISO 19111)

● enumeration

In computer programming, an enumerated type (also called enumeration) is a data type consisting of a set of named values called elements, members, enumeral, or enumerators of the type. The enumerator names are usually identifiers that behave as constants in the language. Similarly, in a database enumerated (enum) types are data types that comprise a static, ordered set of values. They are equivalent to the enum types supported in a number of programming languages. An example of an enum type might be the days of the week, or a set of status values for a piece of data.

● GeoJSON

a geospatial data interchange format based on JSON (source: RFC 7946)

● glob

a pattern set for wildcard characters

● multiplicity

an indication of how many objects may participate in the given relationship, or the allowable number of instances of the element

● stylable layer set

a collection of styles designed to be used within the same domain

3.1. Abbreviated terms

  • COP Common Operational Picture

  • DDIL Denied Disconnected Intermittent Limited

  • GEMINI GEo-spatial Metadata INteroperability Initiative

  • GML Geography Markup Language

  • GPKG GeoPackage

  • JSON JavaScript Object Notation

  • OS Ordnance Survey

  • OWS OGC Web Services

  • PNG Portable Network Graphics

  • SLD Stylable Layer Descriptor

  • SVG Scalable Vector Graphics

  • UK United Kingdom

  • UML Unified Modeling Language

  • VTP2 OGC Vector Tiles Pilot, Phase 2

  • WFS Web Feature Service

  • WPS Web Processing Service

  • XML eXtensible Markup Language

3.2. Conventions

This Engineering Report uses a modified form of Unified Modeling Language (UML) to describe GeoPackage tables. Tables are represented as UML classes with the T label and columns are represented as UML attributes. The conventions used are as follows:

diag a14a91ca5f465f72f670a7ef05ecdd83
Figure 1. A green circle indicates a mandatory column.
diag bfd75325918a46dc9fe358fd66378e43
Figure 2. A solid arrow indicates a foreign key relationship, with the arrow label indicating the name of the referencing column in the dependent table.
diag c07587797956520c975516be131f8d17
Figure 3. A dashed arrow indicates a table_name relationship, with the arrow indicating the name of the referencing column in the referencing table.
diag e4d6bb3efcd6417911ee2a46d9b695c6
Figure 4. Non-explicit references between tables are indicated with a dashed arrow with a box at its base.

4. Overview

Section 5 describes the operational scenario used to test and demonstrate the work of this testbed activity.

Section 6 describes the efforts to encode metadata in a GeoPackage using draft GeoPackage metadata profiles.

Section 7 describes the efforts to improve GeoPackage performance when loading, accessing, and rendering very large vector datasets.

Section 8 describes the implementations produced by each of the participants.

Section 9 describes feedback, recommendations, and future work.

Annex A provides performance measurements and other statistics.

Annex B provides draft GeoPackage Extensions, including the metadata profiles.

Annex C provides example metadata documents.

Annex D provides schemas including database schemas and JSON schemas for metadata documents.

Annex E contains the revision history.

Annex F contains the bibliography.

5. Scenario

In Testbed 16, the data (see Datasets) was loaded into a GeoServer instance provided by GeoSolutions. GeoSolutions provided a WPS server that exported valid GeoPackages according to the various extensions evaluated in the GeoPackage Testbed 16 activity. Arrays present in the source data were converted to strings encoded as JSON arrays. The ensuing GeoPackages were opened by the Compusult GeoPackage client.

GeoPackages were created with several types of metadata:

This metadata increased the utility of the resulting GeoPackages, as demonstrated through the Compusult GeoPackage client.

In addition to metadata, the GeoPackages were created using a number of techniques to improve GeoPackage performance.

  1. Reduce overall dataset size by replacing text strings with more compact enumerations.

  2. Segment the data into smaller GeoPackages so that the file for each segment was not too big.

  3. Improve the ordering of the feature data so that it could be accessed more quickly.

Note

In addition, an approach for generalizing data was also researched. While generalization was not relevant for MasterMap data, the process led to significant performance gains for Zoomstack, in some cases as much as a 300X improvement in read throughput.

GeoSolutions captured metrics on how GeoPackage size was affected by the GeoPackage extensions that were used in creation. GeoSolutions also conducted performance measurement of client read speed when the ordering strategy was used. Compusult conducted performance measurement of client read speed when the segmentation, ordering, and generalization strategies were used. While benchmarking is difficult due to the inconsistency of disk speeds and access time, both GeoSolutions and Compusult were able to measure dramatic improvements in client read performance in their tests.

5.1. Datasets

The Testbed 16 activities used two separate data sets provided by Ordnance Survey.

5.1.1. OS MasterMap Topography

OS MasterMap topography is "the most detailed and accurate view of Great Britain’s landscape – from roads to fields, to buildings and trees, fences, paths and more." This dataset is delivered as a large set of GML files. The data can be used with a set of four freely available style sets also available as SLD. The MasterMap topography is to be displayed only at high scales (1:4000 and above). However, this dataset has a very significant size: 50GB as compressed GML files, 300GB as imported in PostgreSQL, and 200GB as an encoded GeoPackage (after optimizations). See MasterMap Data for more details. This dataset was ideal for tuning write and read performance, as well as experimenting with different content layouts.

5.1.2. OS Zoomstack

OS Zoomstack is a single GeoPackage providing "a single, customisable map of Great Britain to be used at national and local levels." Quoting from the documentation, "OS Open Zoomstack is a comprehensive vector basemap covering Great Britain at a national level, right down to street-level detail." This GeoPackage can be used with a set of six freely available style sets encoded, among other formats, as SLD.

The Zoomstack data set, around 11GB in size (see Space used by table, sorted from larger to smaller tables for details), provided a multi-scale map. Due to the small size of this dataset, the data was suitable for quick tests. As evident in Column level size details, geometries are the major component of space utilization in this dataset, while potentially enumerated fields (type when present) use an amount of space that is one or two orders of magnitude smaller.

In Testbed-16, participants used Zoomstack in scenarios where the huge size of the MasterMap data was cumbersome. Unlike the MasterMap dataset, ZoomStack is a true multi-zoom level dataset, visible from the country level and down to the road level, although not as detailed as the former. The data is also a natural fit for the generalized tables extension.

6. Metadata

Being able to discover what geospatial content is contained in a GeoPackage enables a developer to quickly assess the type of data contained in a GeoPackage and to determine how to best process the content. 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. Without having to access the row entries in GeoPackage tables, manually opening a GeoPackage provides no way of recognizing if the file has any particular type of associated metadata.

6.1. The Metadata Extension

As described in the GeoPackage Getting Started Guide and illustrated in Figure 5, the Metadata Extension is enabled by adding two rows into gpkg_extensions:

c+m
Figure 5. The GeoPackage Metadata Extension

6.2. Semantic Annotations

Semantic annotations provide a way to represent the meaning of any business object (layer, feature, tile, style, etc.) through a resolvable URI. [1] In Testbed-16, semantic annotations were implemented in GeoPackage through the draft Semantic Annotations Extension. Semantic annotations may be placed on virtually any row in the GeoPackage.

6.3. Metadata Profiles

"Proposed GeoPackage Enhancements" cite:[Yutzler2019] proposed the concept of Metadata Profiles to meet this documented GeoPackage requirement. Profile creation consists of two parts:

  • Creating a new GeoPackage extension that defines a new “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.

Once the Metadata Extension is enabled, individual metadata profiles can be activated with additional rows in gpkg_extensions with a scope of "metadata". The Testbed-16 participants investigated implementing metadata profiles for OS MasterMap feature data. However, metadata profiles are also suitable for many other raster and imagery datasets. As described in the following subsections, participants tested a number of these profiles during Testbed-16 .

6.4. Common Operational Pictures

One of the use cases identified in the OGC OWS Context GeoJSON Encoding Standard is the exchange of a set of resources as a Common Operational Picture (COP). In Testbed-16, COPs were encoded as metadata in the GeoPackage as per GeoPackage Common Operational Picture Metadata Profile. The design for this capability is illustrated in Figure 6.

c+m owc1
Figure 6. The Common Operational Picture Metadata Profile

Since the OWS Context standard predates GeoPackage, OWS Context does not support referencing of GeoPackage layers. In Testbed-16, the participants extended OWS Context using the ideas first presented in "GeoPackage / OWS Context Harmonization Discussion Paper" cite:[Yutzler2018]. OWS Context GeoPackage Extension describes the extension used in Testbed-16 to extend OWS Context to represent GeoPackage contents.

In addition, semantic annotations were used to separate OWS Contexts representing COPs from OWS Contexts used for other purposes.

  • In gpkgext_semantic_annotations, a type of "im_metadata_cop_owc_geojson" was used and the title, description, and uri values were populated by the GeoPackage Producer.

  • In gpkgext_sa_reference, a row was added referencing the appropriate row in gpkg_metadata.

6.5. Dataset Details

UK GEMINI (GEo-spatial Metadata INteroperability Initiative) is a specification for a set of metadata elements that describe geospatial data resources. ISO 19115:2003 compliant UK GEMINI discovery level metadata is provided for the OS MasterMap data and can be found on the GIgateway®.

The following is a detailed description of the metadata elements that are provided on the GIgateway:

  • Title: The title of the product.

  • Abstract: The abstract gives a brief description of the product.

  • Currency: The currency takes the form of date of last update for the feature.

  • Lineage: The lineage metadata takes the form of product specification name and date of product specification.

  • Spatial extent: The spatial extent is supplied in the form of geographic identifiers (for example, England, Scotland, and Wales) and in the form of geographic coordinates.

  • Spatial reference system: The spatial reference system for all products takes the form of a British National Grid system, namely OSGB36®.

  • Data format: Data format takes the form of the name of the format or formats the product is supplied in.

  • Frequency of updates: Frequency of update takes the form of a stated period of time.

  • Distributor contact details: Distributor contact details include with postal address, phone number, fax number, email address and website.

  • Data originator: Given as the company having primary responsibility for the intellectual content of the data source; in all cases this will be Ordnance Survey.

  • Other metadata available includes keywords, start date of data capture, access constraints, use constraints, level of spatial data, supply media and presentation details.

Since GEMINI metadata is available for OS MasterMap, adding that metadata to the GeoPackage was a natural choice. GeoPackage Gemini Metadata Profile describes how GEMINI metadata documents may be added to a GeoPackage as metadata. As illustrated in Figure 7, one row is added to gpkg_metadata for each GEMINI document and one row is added to gpkg_metadata_reference for each GEMINI document – feature table combination.

c+m
Figure 7. The GeoPackage Metadata Extension for GEMINI Metadata

6.6. Dataset Provenance

In Testbed-16, GeoPackages were produced via a Web Processing Service (WPS) instance.

A WPS Execute request describes all of the relevant parameters, including which datasets are to be loaded into the GeoPackage. In core GeoPackage, there is no direct link between contents and their source. However the relationship may be described through metadata. This information may be useful when evaluating GeoPackage contents for fitness of purpose. This information could potentially enable in-field updates, such as when the source data is updated on a regular schedule.

There are a number of candidate encodings for the metadata including OWS Context. The OGC has adopted two encoding standards for OWS Context: Atom and GeoJSON. The Testbed-16 participants selected the GeoJSON encoding for this project because GeoJSON is easier for modern client applications to parse.

Note

"GeoPackage / OWS Context Harmonization Discussion Paper" cite:[Yutzler2018] proposed a relational encoding for OWS Context suitable for GeoPackage, but this approach stalled during Testbed-15.

The OWS Context GeoJSON Encoding specifies a number of offering types including WPS, WFS, and GML. In this metadata profile, an OWS Context document was populated with multiple resources:

  • A WPS resource indicating the WPS request that led to the creation of this GeoPackage

  • A WFS resource indicating the WFS instance that served the data after it was imported into GeoServer

6.6.1. Hierarchical Metadata

The GeoPackage Metadata Extension supports hierarchical metadata. Through hierarchical metadata, a GeoPackage client can identify metadata that pertains to the whole GeoPackage file and metadata that is relevant to a particular layer (e.g., feature table). In the Testbed-16 experiment, the metadata elements for the whole GeoPackage file included the WPS request that led to the creation of the GeoPackage. Further, the metadata elements for individual layers included descriptions of the WFS resources that served the data were included. Due to the hierarchical nature of the metadata, when needed a GeoPackage client can navigate from a the layer metadata to the metadata for the whole GeoPackage.

Note

Since a WFS (or other data resource) serving GeoPackage data might not be available online, the layer level dataset provenance metadata should be considered optional.

In the OWS Context GeoJSON encoding, the context is represented by a GeoJSON FeatureCollection and individual resources (layers) are represented by GeoJSON Feature instances. In this metadata profile, the FeatureCollection is inserted into gpkg_metadata as a metadata document, but the GeoJSON Feature instances referring to the feature data (not the WPS instance) are removed. The Feature instances are subsequently inserted into gpkg_metadata as their own entries.

As illustrated in Figure 8, gpkg_metadata_reference is populated as follows:

  • One row with an md_file_id of the parent metadata document reference_scope of "geopackage".

  • One row for each GeoPackage contents table and resource Feature instance, with an md_file_id of that Feature instance, a parent_id of the parent metadata document, and a reference_scope of "table".

c+m owc2
Figure 8. The Dataset Provenance Metadata Profile

6.6.2. Schema and Examples

6.6.3. Semantic Annotations

In addition, semantic annotations were used to separate OWS Contexts representing dataset provenance from OWS Contexts used for other purposes.

  • In gpkgext_semantic_annotations, a type of "im_metadata_dp_owc_geojson" was used and the title, description, and uri values were populated by the GeoPackage Producer.

  • In gpkgext_sa_reference, a row was added referencing the appropriate row in gpkg_metadata.

6.7. Portrayal

OS provides portrayal information for MasterMap in a GitHub repository. This repository contains styling rules using the OGC Styled Layer Descriptor (SLD) format and symbol information in both the Scalable Vector Graphics (SVG) and Portable Network Graphics (PNG) formats.

GeoPackage does not have core support for portrayal information, but recent efforts including the Vector Tiles Pilot, Phase 2 have led to a Portrayal Community Extension. Figure 9 illustrates how portrayal information can be added to GeoPackage through this extension.

diag 826ed2ab8a9f117e52acb84d04955157
Figure 9. The GeoPackage Portrayal Extension

6.7.1. Styles

The Portrayal Extension defines two tables for style information, gpkgext_styles and gpkgext_stylesheets. While this table structure allows a style to have multiple encodings, this feature was not used in Testbed-16.

These tables were populated as follows:

gpkgext_styles

  • id primary key

  • style a text name for the file

  • description null

  • uri the URL of the file landing page on GitHub

gpkgext_stylesheets

  • id primary key

  • style_id gpkgext_styles.id

  • format application/vnd.ogc.sld+xml;version=1.0

  • stylesheet the actual file

6.7.2. Symbols

The Portrayal Extension defines three tables for symbol information: gpkgext_symbols, gpkgext_symbol_images, and gpkgext_symbol_content. While this table structure supports multiple encodings for each style and encoding of multiple styles into a single file as sprites, neither of these approaches was used in Testbed-16.

These tables were populated as follows:

gpkgext_symbols

  • id primary key

  • symbol a text name for the file

  • description null

  • uri the URL of the file landing page on GitHub

gpkgext_symbol_images

  • id primary key

  • symbol_id gpkgext_symbols.id

  • content_id gpkgext_symbol_content.id

  • others null

gpkgext_symbol_content

  • id primary key

  • format "image/svg+xml"

  • content the actual file

  • uri the URL of the file on GitHub

The Portrayal Extension does not define an explicit coupling between layers and styles. (Coupling, in this context, refers to association of styles with layers.) Without any additional design elements, coupling is completely the responsibility of the user and/or client application as illustrated in Figure 10. In many scenarios, having the GeoPackage explicitly declare the coupling between layers and styles simplifies operations for the GeoPackage client operator. In Testbed-16, this coupling was done using semantic annotations.

f+p
Figure 10. GeoPackage Portrayal without Coupling to Layers

As illustrated in Figure 11, semantic annotations can be applied to features table and a style (a row in gpkgext_styles). This links the table and the style together.

c+sa
Figure 11. Semantic Annotations for OS MasterMap portrayal

In Testbed-16, semantic annotations were established for styles in a GeoPackage through the following:

  1. Ensure required tables are present as per the Semantic Annotations Extension:

    • gpkgext_sa_reference

    • gpkgext_semantic_annotations

  2. Populate gpkg_extensions with references to all tables mentioned above.

  3. Add a row to gpkgext_semantic_annotations for every style’s semantic annotation

    • type: Style

    • title: gpkgext_styles.style

    • description: gpkgext_styles.description

    • uri: gpkgext_styles.uri

  4. Add a row to gpkgext_sa_reference for every row that must be annotated.

    • The style in gpkgext_styles

    • Every table in gpkg_contents that is allowed to be used with that style (key_column_name and key_column_value are null).

6.7.4. Stylable Layer Sets

There are a number of scenarios where multiple styles or stylesheets are designed to be used together. In the Testbed-16 scenario, there are four stylesheets (standard, backdrop, light, outdoor) for each of the six feature types. Since a client user may wish to change the style for each layer at once, there needs to be a mechanism to aggregate these styles together. In Testbed-16, this was done through stylable layer sets. As developed in the OGC Vector Tiles Pilot, Phase 2 (VTP2), a stylable layer is created through a semantic annotation and both the styles and layers are tagged with that annotation.

In Testbed-16, semantic annotations were established for stylable layer sets in a GeoPackage through the following:

  1. Ensure required tables are present as per the Semantic Annotations Extension:

    • gpkgext_sa_reference

    • gpkgext_semantic_annotations

  2. Populate gpkg_extensions with references to all tables mentioned above

  3. Add a row to gpkgext_semantic_annotations for every style’s semantic annotation

    • type: StylableLayerSet

    • title: "backdrop", "light", "outdoor", or "standard"

    • description: null

    • uri: like a gpkgext_styles.uri, but with the filename replaced by /stylableLayerSet/[title]

  4. Add a row to gpkgext_sa_reference for every row that must be annotated

    • Every style in gpkgext_styles that is associated with that stylable layer set

    • Every table in gpkg_contents that is associated with that stylable layer set (key_column_name and key_column_value are null)

7. Large Vector Datasets

7.1. Baseline

During Testbed-16, the participants had access to the OS MasterMap Topography dataset. The dataset is licensed and may not be redistributed with permission. The download of the OS MasterMap Topography dataset is comprised of 50GB of gzipped GML files, allocated to 10 folders. The XML schemas for the GML files can be found here.

The data is meant to be rendered using the SLD version provided at the Topography Layer stylesheets. Each feature type is associated with 4 different variations of the styles, as illustrated by the following figures.

Table 2. Examples of Topography Layer Stylesheets. Contains OS data © Crown Copyright and database right 2020.