Open Geospatial Consortium

Submission Date: <2021-mm-dd>

Approval Date:   <2021-mm-dd>

Publication Date:   <2021-mm-dd>

External identifier of this OGC® document: http://www.opengis.net/doc/{doc-type}/{standard}/{m.n}

Internal reference number of this OGC® document:    21-053

Version: 1.0

Category: OGC® Abstract Specification

Editor:   Jeff Yutzler

OGC GeoPackage Conceptual Model

Copyright notice

Copyright © 2021 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 distributed for review and comment. This document is subject to change without notice and may not be referred to as an OGC Standard.

Recipients of this document are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation.

Document type:    OGC® Standard

Document subtype:    if applicable

Document stage:    Draft

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

This document presents the conceptual and logical models for version 1.x of the OGC GeoPackage Standard. The intent is that these models can be used to implement the GeoPackage standard using technology other than a SQLite database.

ii. Keywords

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

ogcdoc, OGC document, geopackage, gpkg, logical model, conceptual model

iii. Preface

The GeoPackage conceptual and logical models were developed in response to numerous requests from the GeoPackage implementation and developer community.

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

  • Image Matters LLC

  • US Army Geospatial Center

  • Carl Reed and Associates

v. Submitters

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

Name Affiliation

Jeff Yutzler

Image Matters LLC

Amy Youmans

US Army Geospatial Center

Carl Reed

Carl Reed and Associates

1. Scope

This OGC document describes an OGC Conceptual Model (CM) and Logical Model (LM) Standard for encoding geospatial information based on the GeoPackage Standard. A GeoPackage is an open, standards-based, platform-independent, portable, self-describing, compact format for transferring geospatial information. The GeoPackage Conceptual Model Standard (this document) describes the model for encoding the following:

  • Vector features;

  • Tile matrix sets of imagery and raster maps at various scales;

  • Attributes (non-spatial data); and

  • Extensions.

The CM and LM are Platform Independent Models (PIMs). The CM is a high level description of the concepts involved in the GeoPackage standard. The LM is an abstract representation of an interface or data model that can be executed to produce physical artifacts. As such, neither the GeoPackage CM nor the LM can be implemented directly. Rather, they serve as the base for Platform Specific Models (PSM). A PSM adds to the PIM the technology-specific details needed to fully define the model for use with a specific technology. The PSM can then be used to generate artifacts such as schemas needed to build GeoPackage implementations. These artifacts include table definitions, integrity assertions, format limitations, and content constraints.

This document was developed retroactively from the GeoPackage Encoding Standard (GES) 1.3.0. At the time the GES was first developed, OGC members decided that developing the CM or LM was not necessary as the GES was intended specifically for the SQLite database format. However, as SQLite’s inherent limitations became more apparent, stakeholders determined that it would be beneficial to the community to document and standardize the CM and LM so that other PSMs could potentially be supported in the future. As a result, this document is agnostic to potential uses and implementation technologies. The OGC believes that GeoPackage has the potential to evolve to support use cases and computing environments that go beyond what was originally conceived for the GES.

2. Conformance

This standard identifies nine (9) conformance classes. One conformance class is defined for each package in the UML model. Each conformance class is defined by one requirements class.

Only the Core conformance class is mandatory; all other conformance classes are optional. In the case where a conformance class has a dependency on another conformance class, that conformance class should also be implemented.

The tests in Annex A are organized by Requirements Class. For example, an implementation of the Core conformance class must pass all tests specified in Annex A for the Core requirements class.

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.

OGC: OGC 06-103r4, OpenGIS Implementation Standard for Geographic Information - Simple feature access - Part 1: Common architecture (2011) https://portal.ogc.org/files/?artifact_id=25355

OGC: OGC 12-128r17, OGC GeoPackage Encoding Standard 1.3.0 (2020) http://www.geopackage.org/spec130/index.html

OGC: OGC 17-066, OGC GeoPackage Extension for Tiled Gridded Coverage Data (2017) http://docs.opengeospatial.org/is/17-066r1/17-066r1.html

OGC: OGC 17-083r2, OGC Two Dimensional Tile Matrix Set (2019) http://docs.opengeospatial.org/is/17-083r2/17-083r2.html

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

OGC: OGC 18-010r7, Geographic information — Well-known text representation of coordinate reference systems (2019) https://docs.opengeospatial.org/is/18-010r7/18-010r7.html (also ISO 19162:2019)

4. Terms and Definitions

This document used the terms defined in OGC Policy Directive 49, 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 standard and OGC documents do not use the equivalent phrases in the ISO/IEC Directives, Part 2.

This document also uses terms defined in the OGC Standard for Modular specifications (OGC 08-131r3), also known as the 'ModSpec'. The definitions of terms such as standard, specification, requirement, and conformance test are provided in the ModSpec.

For the purposes of this document, the following additional terms and definitions apply.

Conceptual Model

model that defines concepts of a universe of discourse [ISO 19101-1:2014, 4.1.5].

GeoPackage Encoding Standard

The original encoding standard for GeoPackage adopted by OGC as 12-128. GES for short.

GeoPackage SQLite Configuration

consists of the SQLite 3 software library and a set of compile- and runtime configurations options.

GES

GeoPackage Encoding Standard (see above).

Implementation Specification

Specified on the OGC Document Types Register at http://www.opengis.net/def/doc-type/is.

Logical Model

a data model of a specific problem domain expressed independently of a particular database management product or storage technology (physical data model) but in terms of data structures such as relational tables and columns, object-oriented classes, or XML tags [OGC: 19-014r3].

Platform Independent Model

a model that is independent of a specific platform [Object Management Group, Model Driven Architecture Guide rev. 2.0].

Platform Specific Model

a model of a system that is defined in terms of a specific platform [Object Management Group, Model Driven Architecture Guide rev. 2.0].

5. Conventions

This section provides details and examples for any conventions used in the document. Examples of conventions are symbols, abbreviations, use of XML schema, or special notes regarding how to read the document.

5.1. Conceptual Model

The CM is comprised of definitions of relevant concepts. Since the CM was reverse-engineered from the GES, this CM provides references in italics indicating how the concepts are realized in the GES.

5.2. Logical Model

The LM uses a modified form of Unified Modeling Language (UML) to describe GeoPackage classes. Classes are represented as UML classes and columns are represented as UML attributes. The conventions used are as follows:

5.2.1. Relationships

Diagram
Figure 1. A solid arrow indicates an association.
Diagram
Figure 2. A diamond-based arrow indicates an aggregation.
Diagram
Figure 3. A solid line with a solid arrowhead indicates an inheritance.
Diagram
Figure 4. A dotted line with a solid arrowhead indicates a realization.

5.2.2. Multiplicity

  • Multiplicity is assumed to be 1 unless otherwise specified.

  • An unbounded multiplicity (0..n) is represented as *.

  • For attributes, see Figure 5.

  • Other relationship multiplicities are explicitly specified.

Diagram
Figure 5. A Question Mark ? after a type name indicates a nullable attribute type

6. Standardization Targets (Informative)

This standard defines a Logical and Conceptual Model that are independent of any encoding or formatting techniques. The Standardization Targets for this standard are:

  1. Conceptual Models (extended versions of this conceptual model)

  2. Logical Models (extended versions of this logical model)

  3. Encoding Standards (encodings of this logical model)

The Logical Model is defined by a UML model. This standard is a representation of that UML model in document form. In the case of a discrepancy between the UML model and this document, the UML model takes precedence.

6.1. Conceptual Models

A Conceptual Model standardization target is a version of the GeoPackage Conceptual Model tailored for a specific user community. This tailoring can include:

  1. Omission of one or more of the optional concepts

  2. Additional concepts documented through extensions.

Of these options, actions #1 can be performed when creating an Encoding Standard. Action #2 requires an extension of the Conceptual Model. These extensions are accomplished using the extension mechanism described in Extensions. Extensions of the Conceptual Model conform with the Extension Conformance Class.

6.2. Logical Models

A Logical Model standardization target is a version of the GeoPackage Logical Model tailored for a specific user community. This tailoring can include:

  1. Omission of one or more of the optional UML packages

  2. Reduction of the multiplicity for an attribute or association

  3. Restriction on the valid values for an attribute

  4. Documentation of new concepts defined by an extended Conceptual Model.

Of these options, actions #1, #2, and #3 can be performed when creating an Encoding Standard. Only action #4 requires an extension of the Logical Model. These extensions are accomplished using the extension mechanism described in Extensions. Extensions of the Logical Model conform with the Extension Conformance Class.

6.3. Encoding Standards

Encoding Standards define how a Logical Model should be implemented using a specific technology. Conformant Encoding Standards provide evidence that they are an accurate representation of the Logical Model. This evidence should include implementations of the abstract tests specified in Annex A (normative) of this document. Since this standard is agnostic to the implementing technologies, the specific techniques to be used for conformance testing cannot be specified. Encoding Standards need to provide evidence of conformance which is appropriate for the implementing technologies. This evidence should be provided as an annex to the Encoding Standard document.

The GeoPackage Encoding Standard (OGC 12-128) is the canonical example of an encoding standard for GeoPackage. This standard implements the Logical Model while describing all of the requirements needed to meet the particulars of the SQLite format.

7. GeoPackage Conceptual Model (Normative)

This section presents the normative definition of the GeoPackage Conceptual Model (CM). The CM consists of a set of terms and their definitions. Since most readers will be familiar with the GES, an indication of how GeoPackage concepts are realized in the GES is presented in italics.

7.1. Core

All GeoPackages conform to Core.

Attribute

a value for a particular attribute type for a particular entity. In the GES, an attribute is realized through a column value of a user-defined table.

Attribute Type

a characteristic of an entity. An attribute type has a name, a data type, and a value domain associated to it. No restrictions are implied as to the type of attributes a user-defined type may have. Not all entity types have attributes. (SOURCE: Adapted from ISO19101) In the GES, an attribute is realized through a column of a user-defined table.

Coordinate Reference System (CRS)

A coordinate reference system, or spatial reference system, is a set of mathematical rules for specifying how coordinates are to be assigned to points that is related to an object by a datum. (SOURCE: ISO 19111:2019) The GES uses the term "spatial reference system." In the GES, a spatial reference system is realized through a gpkg_spatial_ref_sys row.

Entity

For the purposes of this standard, an entity is simply a unit of content contained in a GeoPackage. This is deliberately open-ended so as not to prejudice the content that a GeoPackage may contain. In the GES, an entity is realized through a row of a user-defined table.

Entity Store

a container for entities. In the GES, an entity store is realized through a user-defined table and a row in gpkg_contents.

Entity Type

the characteristics of an entity, including attribute types (if any). In the GES, an entity type is realized through the schema of a user-defined table.

GeoPackage

an open, standards-based, platform-independent, portable, self-describing, compact format for transferring geospatial information. In the GES, a GeoPackage is realized through a GeoPackage file.

Spatial Reference System (SRS)

see "Coordinate Reference System".

7.2. Features

GeoPackages that conform to the Features Requirements Class contain the content represented here. The Features Requirements Class implements Simple Features as per OGC 06-103r4. The definitions of the concepts below are from that document unless otherwise indicated.

Feature

abstraction of real world phenomena (SOURCE: ISO 19101). For the purposes of this document, it refers to an individual realization thereof. In the GES, a feature is realized through a row of a user-defined features table.

Feature Store

a container for features. In the GES, an attributes store is realized through a user-defined features table.

Feature Type

the attributes that comprise a class of a feature. In the GES, a feature type is realized through the schema of a user-defined features table.

Geometry

spatial object representing a geometric set (SOURCE: ISO19107) In the GES, a geometry is realized through a Well Known Binary value for a geometry attribute for a feature in a user-defined features table.

Geometry Attribute

a specialization of attribute for geometry values. In the GES, a geometry attribute is realized through a column of a user-defined features table.

Geometry Attribute Type

a specialization of attribute types for a geometry data type. In the GES, a geometry attribute type is realized through a row of gpkg_geometry_columns.

7.3. Tiles

GeoPackages that conform to the Tiles Requirements Class contain the content represented here. The Tiles Requirements Class implements Tile Matrix Sets as per OGC 17-083r2. The definitions of the concepts below are from that document unless otherwise indicated.

Tile

a geometric shape with known properties that may or may not be the result of a tiling (tessellation) process. A tile consists of a single connected "piece" (topological disc) without "holes" or "lines". In this CM, a tile is restricted to a small rectangular representation of geographic data, often part of a set of such elements, covering a tiling scheme and sharing similar information content and graphical styling. A tile can be uniquely defined in a tile matrix by one integer index in each dimension. Tiles are mainly used for fast transfer (particularly in the web) and easy display at the resolution of a rendering device. Tiles can be grid based pictorial representations, coverage subsets, or feature based representations (e.g., vector tiles). In the GES, a tile is realized through a row of a user-defined tiles table.

Tile Matrix

a grid tiling scheme that defines how space is partitioned into a set of conterminous tiles at a fixed scale. In the GES, a tile matrix is realized through a row of gpkg_tile_matrix.

Note

A tile matrix constitutes a tessellation of the space that resembles a matrix in a 2D space characterized by a matrix width (columns) and a matrix height (rows).
Tile Matrix Set

a tiling scheme composed by collection of tile matrices defined at different scales covering approximately the same area and has a common coordinate reference system. In the GES, a tile matrix set is realized through a row of gpkg_tile_matrix_set.

Tile Pyramid

a tile set organized in pyramid structure of tiles of different spatial extent and resolution at different zoom levels. In the GES, a tile pyramid is realized through a user-defined tiles table and a row of gpkg_contents.

Tile Set

a set of tiles – a collection of subsets of the space being partitioned [OGC 19-014r3]. In this standard, In this CM, a tile set is a series of actual tiles containing data and following a common tiling scheme.

Tiling Scheme

a scheme that defines how space is partitioned into individual tiled units. A tiling scheme defines the spatial reference system, the geometric properties of a tile, which space a uniquely identified tile occupies, and reversely, which unique identifier corresponds to a space satisfying the geometric properties to be a tile. [OGC 19-014r3]

Note

A tiling scheme is not restricted to a coordinate reference system or a tile matrix set and allows for other spatial reference systems such as DGGS and other organizations including irregular ones.

7.4. Attributes

GeoPackages that conform to the Attributes Requirements Class contain the content represented in Figure 9.

Attributes Set

a user-defined type with one or attributes, none of which is a geometry. In the GES, an attributes set is realized through a row of a user-defined attributes table.

Note

OGC 12-128 defined this concept as "attributes". However, this conflicts with the standard definition of an attribute as a member of a class.
Attributes Set Type

the characteristics (attribute types) of an attributes set. In the GES, an attributes set type is realized through the schema of a user-defined attributes table.

Attributes Store

a container for attributes sets. In the GES, an attributes store is realized through a user-defined attributes table.

7.5. Extensions

GeoPackages that conform to the Extensions Requirements Class contain the content represented here.

Extension

a set of one or more requirements clauses that either profiles / extends existing requirements clauses in the GeoPackage standard or adds new requirements clauses. In the GES, extensions are realized through rows of gpkg_extensions.

7.6. Metadata

GeoPackages that conform to the Metadata Requirements Class contain the content represented here.

Metadata

for the purposes of this document, a discrete unit of data about data. (SOURCE: ISO 19115) In the GES, metadata is realized through rows of gpkg_metadata.

Metadata Reference

a reference indicating the element(s) that particular metadata pertains to. In the GES, a metadata reference is realized through a row of gpkg_metadata_reference.

7.7. Schema

GeoPackages that conform to the Schema Requirements Class contain the content represented here.

Attribute Descriptor

an extended description of an attribute type. In the GES, an attribute descriptor is realized through a row of gpkg_data_columns.

Constraint

a restriction on the range of an attribute value. In the GES, a constraint is realized through a row of gpkg_data_column_constraints.

7.8. Tiled Gridded Coverages

GeoPackages that conform to the Tiled Gridded Coverage Requirements Class contain the content represented in here.

Coverage

a function that describe characteristics of real-world phenomena that vary over space and/or time. Typical examples are temperature, elevation and precipitation. A coverage is typically represented as a data structure containing a set of such values, each associated with one of the elements in a spatial, temporal or spatiotemporal domain. Typical spatial domains are point sets (e.g. sensor locations), curve sets (e.g. contour lines), grids (e.g. orthoimages, elevation models), etc. A property whose value varies as a function of time may be represented as a temporal coverage or time-series [SOURCE: ISO-19109].

Coverage Tile

a tile containing coverage data. In the GES, a coverage tile is realized through a row in a user-defined tiles table and a row in gpkg_2d_gridded_tile_ancillary.

Tiled Gridded Coverage

a tile pyramid containing coverage data encoded as coverage tiles. In the GES, a tiled gridded coverage is realized through a user-defined tiles table, a row in gpkg_2d_gridded_coverage_ancillary, and a row in gpkg_contents.

7.9. Related Tables

GeoPackages that conform to the Related Tables Requirements Class contain the content represented here. The purpose of this requirements class is to support a many-to-many relationship between two entities, defined as the "base" entity and the "related" entity. In the CM there is no semantic difference between these concepts, but profiles may be used to provide those semantics.

Extended Relation

a descriptor for the relationship between the base entity and the related entity. In the GES, an extended relation is realized through a row in gpkgext_relations.

8. GeoPackage Conceptual Model (Normative)

This section presents the normative definition of the GeoPackage Conceptual Model (CM). The CM is primarily presented as UML diagrams but are augmented with text where needed. The diagrams are intended to be normative, but if there is any discrepancy between the diagrams and the text then the text takes priority.

Note

Requirements are numbered to maintain alignment with OGC 12-128.

8.1. Core

A GeoPackage contains the content represented in Figure 6.

core
Figure 6. Core GeoPackage Classes

Requirements Class

http://www.opengis.net/spec/GeoPackage/1.3/req/core

Target type

Encoding Standard

Dependency

http://ogc.org/standards/ct/01-009

Dependency

urn:iso:ics:35.240.70:iso:19162:2019

Requirement 5

http://www.opengis.net/spec/GeoPackage/1.3/req/core/value_types

The Encoding Standard SHALL describe the encoding of values as per the ValueType enumeration.

A

Boolean values SHALL be encoded as a boolean value representing true or false.

B

TinyInteger values SHALL be encoded as 8-bit signed two’s complement integer in the range [-128, 127].

C

SmallInteger values SHALL be encoded as 16-bit signed two’s complement integer in the range [-32768, 32767].

D

MediumInteger values SHALL be encoded as 32-bit signed two’s complement integer in the range [-2147483648, 2147483647].

E

Integer values SHALL be encoded as 64-bit signed two’s complement integer in the range [-9223372036854775808, 9223372036854775807].

F

Float values SHALL be encoded as 32-bit IEEE floating point number.

G

Real values SHALL be encoded as 64-bit IEEE floating point number.

H

String values SHALL be encoded as variable length string encoded in either UTF-8 or UTF-16.

I

Blob values SHALL be encoded as variable length binary data.

J

Geometry values are described in the Features Requirements Class.

K

Date values SHALL be encoded as ISO-8601 date strings in the form YYYY-MM-DD encoded in either UTF-8 or UTF-16.

L

DateTime values SHALL be encoded as ISO-8601 date/time strings in the form YYYY-MM-DDTHH:MM:SS.SSSZ with T separator character and Z suffix for coordinated universal time (UTC) encoded in either UTF-8 or UTF-16.

Requirement 10

http://www.opengis.net/spec/GeoPackage/1.3/req/core/srs

The Encoding Standard SHALL describe the encoding of coordinate reference systems as per the CoordinateReferenceSystem class.

A

The definition SHALL be encoded as Well-Known Text 2 (CRS WKT2) as per OGC 18-010r7.

Requirement 11

http://www.opengis.net/spec/GeoPackage/1.3/req/core/srs_default

The Encoding Standard SHALL describe the encoding of the three required coordinate reference systems listed in Table 1 below.

Requirement 13

http://www.opengis.net/spec/GeoPackage/1.3/req/core/contents

The Encoding Standard SHALL describe the encoding of GeoPackage contents as per the EntityStore and EntityType classes.

A

Each EntityStore object SHALL refer to the CoordinateReferenceSystem object that describes its coordinate reference system.
Table 1. Coordinate Reference System Required Records
name id organization organization_coordsys_id definition description

any

4326

EPSG or epsg

4326

any

any

any

-1

NONE

-1

undefined

any

any

0

NONE

0

undefined

any

8.2. Features

GeoPackages that conform to the Features Requirements Class contain the content represented in Figure 7.

features
Figure 7. Features GeoPackage Classes

Requirements Class

http://www.opengis.net/spec/GeoPackage/1.3/req/features

Target type

Encoding Standard

Dependency

http://www.opengis.net/spec/GeoPackage/1.3/req/core

Requirement 18

http://www.opengis.net/spec/GeoPackage/1.3/req/features/data_type

The Encoding Standard SHALL describe the encoding of features as an EntityStore instance with a dataType of features.

Requirement 19

http://www.opengis.net/spec/GeoPackage/1.3/req/features/wkb

The Encoding Standard SHALL describe the encoding of geometry values as attribute values containing the GeoPackageBinary format specified in OGC 12-128.

Requirement 20

http://www.opengis.net/spec/GeoPackage/1.3/req/features/geometry_attribute_type

The Encoding Standard SHALL describe the encoding of a geometry attribute type as per the GeometryAttributeType class.

A

The valueType SHALL be Geometry.

B

The geometryType SHALL be encoded as per the GeometryType enumeration.

C

The coordinate reference system SHALL reference a CoordinateReferenceSystem object.

D

The z SHALL be encoded as per the DimensionSupport enumeration.

E

The m SHALL be encoded as per the DimensionSupport enumeration.

Requirement 29

http://www.opengis.net/spec/GeoPackage/1.3/req/features/feature_store

The Encoding Standard SHALL describe the encoding of features as per the FeatureStore, FeatureType, AttributeType, Feature, and Attribute classes.

A

A Feature SHALL conform to the FeatureType of the FeatureStore.

B

A FeatureType SHALL have an AttributeType that specifies a unique integer identifier.

C

A FeatureType SHALL have exactly one geometry column as described by the GeometryAttributeType of the FeatureType.

8.3. Tiles

GeoPackages that conform to the Tiles Requirements Class contain the content represented in Figure 8.

tiles
Figure 8. Tiles GeoPackage Classes

Requirements Class

http://www.opengis.net/spec/GeoPackage/1.3/req/tiles

Target type

Encoding Standard

Dependency

http://www.opengis.net/spec/GeoPackage/1.3/req/core

Requirement 34

http://www.opengis.net/spec/GeoPackage/1.3/req/tiles/data_type

The Encoding Standard SHALL describe the encoding of tiles as an EntityStore instance with a dataType of tiles.

Requirement 38

http://www.opengis.net/spec/GeoPackage/1.3/req/tiles/tms

The Encoding Standard SHALL describe the encoding of tile matrix sets as per the TileMatrixSet class.

A

The min_x, max_x, min_y, and max_y values SHALL be exact so that the bounding box coordinates for individual tiles in a tile pyramid may be calculated from those values. All tiles present in the tile pyramid SHALL fall within this bounding box.

B

The coordinate reference system SHALL be encoded as per the CoordinateReferenceSystem class.

Requirement 42

http://www.opengis.net/spec/GeoPackage/1.3/req/tiles/tm

The Encoding Standard SHALL describe the encoding of tile matrixes as per the TileMatrix class.

A

A TileMatrixSet SHALL have one TileMatrix per zoom level.

B

The width of a TileMatrix (the difference between min_x and max_x of the TileMatrixSet) SHALL equal the product of matrixWidth, tileWidth, and pixelXSize for that zoom level. Similarly, height of a TileMatrix (the difference between min_y and max_y of the TileMatrixSet) SHALL equal the product of matrixHeight, tileHeight, and pixelYSize for that zoom level.

C

The zoomLevel for a TileMatrix SHALL not be negative.

D

The matrixWidth, matrixHeight, tileWidth, tileHeight, pixelXSize, and pixelYSize for a TileMatrix SHALL be greater than 0.

Requirement 54

http://www.opengis.net/spec/GeoPackage/1.3/req/tiles/user_defined

The Encoding Standard SHALL describe the encoding of user-defined tile pyramids as per the TilePyramid and Tile classses.

A

A tile pyramid MAY be sparsely populated.

8.4. Attributes

GeoPackages that conform to the Attributes Requirements Class contain the content represented in Figure 9.

Note

OGC 12-128 defined this concept as "attributes". However, this conflicts with the standard definition of an attribute as a member of a class. In this document, the term "attributes set" will be used to describe a user-defined class with multiple attributes and no geometry.
attributes
Figure 9. Attributes GeoPackage Classes

Requirements Class

http://www.opengis.net/spec/GeoPackage/1.3/req/attributes

Target type

Encoding Standard

Dependency

http://www.opengis.net/spec/GeoPackage/1.3/req/core

Requirement 118

http://www.opengis.net/spec/GeoPackage/1.3/req/attributes/data_type

The Encoding Standard SHALL describe the encoding of attributes sets as an EntityStore instance with a dataType of attributes.

Requirement 119

http://www.opengis.net/spec/GeoPackage/1.3/req/features/feature_store

The Encoding Standard SHALL describe the encoding of attributes sets as per the AttributesStore, AttributesSet, AttributesSetType, AttributeType, and Attribute classes.

A

An AttributesSet SHALL conform to the AttributesSetType of the AttributesStore.

B

An AttributesSetType SHALL have an AttributeType that specifies a unique integer identifier.

C

An AttributesSetType SHALL NOT contain a GeometryAttributeType.

8.5. Extensions

GeoPackages that conform to the Extensions Requirements Class contain the content represented in Figure 10.

extensions
Figure 10. Extensions GeoPackage Classes

Requirements Class

http://www.opengis.net/spec/GeoPackage/1.3/req/extensions

Target type

Encoding Standard

Dependency

http://www.opengis.net/spec/GeoPackage/1.3/req/core

Requirement 58

http://www.opengis.net/spec/GeoPackage/1.3/req/extensions/def

The Encoding Standard SHALL describe the encoding of extensions as per the Extension class.

A

An extension MAY apply to the whole GeoPackage or to specific EntityStore instances. The Encoding Standard SHALL describe the encoding of relevant EntityStore instances.

B

The Encoding Standard SHALL describe the encoding of extensions that pertain to a particular AttributeType of a particular EntityStore.

C

Extensions SHALL have a unique extension_name which SHALL be a unique case sensitive value of the form <author>_<extension_name> where <author> indicates the person or organization that developed and maintains the extension. The valid character set for <author> SHALL be [a-zA-Z0-9]. The valid character set for <extension_name> SHALL be [a-zA-Z0-9_].

D

An extension_name with the "gpkg" author name SHALL be reserved for extensions defined in an OGC document (e.g., Best Practices Document or Encoding Standard).

E

A definition value SHALL contain a permalink, URI, or reference to a document defining the extension.

F

A scope value SHALL conform to the ExtensionScope enumeration.

8.6. Metadata

GeoPackages that conform to the Metadata Requirements Class contain the content represented in Figure 11.

metadata
Figure 11. Metadata GeoPackage Classes

Requirements Class

http://www.opengis.net/spec/GeoPackage/1.3/req/metadata

Target type

Encoding Standard

Dependency

http://www.opengis.net/spec/GeoPackage/1.3/req/core

Dependency

http://www.opengis.net/spec/GeoPackage/1.3/req/extensions

Requirement 93

http://www.opengis.net/spec/GeoPackage/1.3/req/metadata/metadata

The Encoding Standard SHALL describe the encoding of metadata as per the Metadata class.

A

Metadata scopes from the MetadataScope enumeration SHOULD be used if possible. However, this list is not exhaustive and MAY be extended.

Requirement 95

http://www.opengis.net/spec/GeoPackage/1.3/req/metadata/metadata_reference

The Encoding Standard SHALL describe the encoding of metadata references as per the MetadataReference class so that each Metadata instance is associated with the GeoPackage element or elements that it pertains to.

A

MetadataReference scopes SHALL conform to the ReferenceScope enumeration.

Requirement 102

http://www.opengis.net/spec/GeoPackage/1.3/req/metadata/hierarchical

The Encoding Standard SHALL describe the encoding of hierarchical metadata so that a particular metadata entry MAY have a parent.

8.7. Schema

GeoPackages that conform to the Schema Requirements Class contain the content represented in Figure 12.

schema
Figure 12. Schema GeoPackage Classes

Requirements Class

http://www.opengis.net/spec/GeoPackage/1.3/req/schema

Target type

Encoding Standard

Dependency

http://www.opengis.net/spec/GeoPackage/1.3/req/core

Dependency

http://www.opengis.net/spec/GeoPackage/1.3/req/extensions

Requirement 103

http://www.opengis.net/spec/GeoPackage/1.3/req/schema/ad

The Encoding Standard SHALL describe the encoding of attribute descriptors as per the AttributeDescriptor class.

A

An AttributeDescriptor SHALL reference a particular AttributeType of a particular EntityStore.

Requirement 107

http://www.opengis.net/spec/GeoPackage/1.3/req/schema/constraint

The Encoding Standard SHALL describe the encoding of constraints as per the Constraint class and its subclasses.

8.8. Tiled Gridded Coverages

GeoPackages that conform to the Tiled Gridded Coverage Requirements Class contain the content represented in Figure 13.

tgce
Figure 13. Tiled Gridded Coverage Extension GeoPackage Classes

Requirements Class

http://www.opengis.net/spec/GeoPackage/1.3/req/tgce

Target type

Encoding Standard

Dependency

http://www.opengis.net/spec/GeoPackage/1.3/req/core

Dependency

http://www.opengis.net/spec/GeoPackage/1.3/req/tiles

Dependency

http://www.opengis.net/spec/GeoPackage/1.3/req/extensions

Requirement 11-5

http://www.opengis.net/spec/GeoPackage/1.3/req/tiles/data_type

The Encoding Standard SHALL describe the encoding of 2D gridded coverages as an EntityStore instance with a dataType of 2d-gridded-coverage.

Requirement 11-1

http://www.opengis.net/spec/GeoPackage/1.3/req/tgce/ca

The Encoding Standard SHALL describe the encoding of tiled gridded coverages as per the CoverageAncillary class.

A

The gridCellEncoding SHALL conform to the GridCellEncoding enumeration.

Requirement 11-2

http://www.opengis.net/spec/GeoPackage/1.3/req/tgce/ta

The Encoding Standard SHALL describe the encoding of coverage tiles as per the TileAncillary class.

Requirement 11-3

http://www.opengis.net/spec/GeoPackage/1.3/req/tgce/srs

In addition to the three coordinate reference systems listed in Table 1, the Encoding Standard SHALL describe the encoding of the additional required coordinate reference system listed in Table 2.

Table 2. Spatial Reference System Required Records
name id organization organization_coordsys_id definition description

any

4979

EPSG or epsg

4979

any

any

8.9. Related Tables

GeoPackages that conform to the Related Tables Requirements Class contain the content represented in Figure 14.

rte
Figure 14. Related Tables GeoPackage Classes

Requirements Class

http://www.opengis.net/spec/GeoPackage/1.3/req/rte

Target type

Encoding Standard

Dependency

http://www.opengis.net/spec/GeoPackage/1.3/req/core

Dependency

http://www.opengis.net/spec/GeoPackage/1.3/req/extensions

Requirement 12-4

http://www.opengis.net/spec/GeoPackage/1.3/req/rte/xr

The Encoding Standard SHALL describe the encoding of extended relationships as per the ExtendedRelation class.

A

The ExtendedRelation SHALL describe the "base" and "related" EntityStore instances that participate in this relationship.

B

The relationName SHALL conform to the RelationName enumeration.

Requirement 12-9

http://www.opengis.net/spec/GeoPackage/1.3/req/rte/m2m

The Encoding Standard SHALL describe the encoding of many-to-many relationships between "base" and "related" Entity instances that are members of the EntityStore instances defined in an ExtendedRelation instance.

Annex A: Revision History

Date Release Editor Primary clauses modified Description

2021-05-01

0.1

Jeff Yutzler

all

initial version

2021-06-21

0.2

Jeff Yutzler

all

code complete

2021-07-31

0.3

Amy Youmans

all

review for clarity

2021-08-18

0.4

Carl Reed

1, 7

review for clarity and consistency

Annex B: Bibliography

Note
Example Bibliography (Delete this note).

The TC has approved Springer LNCS as the official document citation type.

Springer LNCS is widely used in technical and computer science journals and other publications

  • For citations in the text please use square brackets and consecutive numbers: [1], [2], [3]

– Actual References:

[n] Journal: Author Surname, A.: Title. Publication Title. Volume number, Issue number, Pages Used (Year Published)

[n] Web: Author Surname, A.: Title, http://Website-Url

[1] OGC: OGC Testbed 12 Annex B: Architecture. (2015).