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, conceptual model, logical model, standard, specification
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. Security considerations
No security considerations have been made for this document.
V. 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
VI. 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 |
VII. Introduction
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.
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.
Abstract Specification Topic 23 - GeoPackage Conceptual and Logical Model
1. Scope
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.
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. Normative references
The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.
ISO: ISO 19115-1, Geographic information — Metadata — Part 1: Fundamentals. International Organization for Standardization, Geneva https://www.iso.org/standard/53798.html.
John Herring: OGC 06-103r4, OpenGIS Implementation Specification for Geographic information — Simple feature access — Part 1: Common architecture. Open Geospatial Consortium (2011). https://portal.ogc.org/files/?artifact id=25355.
Jeff Yutzler: OGC 12-128r18, OGC® GeoPackage Encoding Standard. Open Geospatial Consortium (2021). https://www.geopackage.org/spec131/index.html.
Carl Reed: OGC 17-066r1, OGC GeoPackage Extension for Tiled Gridded Coverage Data. Open Geospatial Consortium (2018). https://docs.ogc.org/is/17-066r1/17-066r1.html.
Joan Masó: OGC 17-083r2, OGC Two Dimensional Tile Matrix Set. Open Geospatial Consortium (2019). https://docs.ogc.org/is/17-083r2/17-083r2.html.
Jeff Yutzler: OGC 18-000, OGC GeoPackage Related Tables Extension. Open Geospatial Consortium (2019). https://docs.ogc.org/is/18-000/18-000.html.
Roger Lott: OGC 18-010r7, Geographic information — Well-known text representation of coordinate reference systems. Open Geospatial Consortium (2019). https://docs.ogc.org/is/18-010r7/18-010r7.html.
Carl Reed: OGC 19-014r3, Topic 22 — Core Tiling Conceptual and Logical Models for 2D Euclidean Space. Open Geospatial Consortium (2020). https://docs.ogc.org/as/19-014r3/19-014r3.html.
ISO: ISO 19101-1:2014, Geographic information — Reference model — Part 1: Fundamentals. International Organization for Standardization, Geneva (2014). https://www.iso.org/standard/59164.html.
4. Terms and definitions
This document uses 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 document 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.
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.
4.1. Aggregation
An aggregation represents a part-whole relationship between two model elements. In the context of this document, it indicates containment. In the GES, an aggregation is used to describe how a GeoPackage contains tables or a table contains columns or rows.
4.2. Association
An association represents a generic relationship between two model elements. In the GES, an association is used to represent a foreign key — primary key relationship between two tables.
4.3. Conceptual Model
model that defines concepts of a universe of discourse
[SOURCE: ISO 19101-1:2014]
4.4. Dependency
A dependency represents a need of one model element for another for specification.
4.5. GeoPackage Encoding Standard
The original encoding standard for GeoPackage adopted by OGC as 12-128. GES for short.
[SOURCE: OGC 12-128r18]
4.6. GeoPackage SQLite Configuration
consists of the SQLite 3 software library and a set of compile- and runtime configurations options.
4.7. GES
GeoPackage Encoding Standard (see above).
[SOURCE: OGC 12-128r18]
4.8. Implementation Specification
Specified on the OGC Document Types Register at http://www.opengis.net/def/doc-type/is.
4.9. Inheritance
An inheritance relationship represents the ability of one model element to implement the properties and behaviors of another model element (the supplier). In the context of this document, the supplier is a concrete element with a real-world implementation.
4.10. 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
[SOURCE: OGC 19-014r3]
4.11. Platform Independent Model
a model that is independent of a specific platform [Object Management Group, Model Driven Architecture Guide rev. 2.0].
4.12. 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].
4.13. Realization
A realization relationship represents the ability of one model element to implement the behavior of another. In the context of this document, the supplier is an abstract element with no real-world implementation.
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
Figure 1 — A solid arrow indicates an association.
Figure 2 — A dotted arrow indicates a dependency.
Figure 3 — A diamond-based line indicates an aggregation.
Figure 4 — A solid line with a solid arrowhead indicates an inheritance.
Figure 5 — 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 6.
Other relationship multiplicities are explicitly specified.
Figure 6 — A Question Mark ? after a type name indicates a nullable or optional 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:
Conceptual Models (extended versions of this conceptual model)
Logical Models (extended versions of this logical model)
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:
Omission of one or more of the optional concepts
Additional concepts documented through extensions.
Of these options, action #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 Clause 7.5. 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:
Omission of one or more of the optional UML packages
Reduction of the multiplicity for an attribute or association
Restriction on the valid values for an attribute
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 Clause 7.5. 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 characteristic of an entity. (SOURCE: Adapted from ISO 19101-1:2014) In the GES, an attribute is realized through a column value of a user-defined table.
Attribute Type
a characteristic of an entity type. 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 ISO 19101-1:2004) 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
An individual item that is perceivable or conceivable. (SOURCE: ISO/IEC 21838-1:2021) In the GES, an entity is realized through a row of a user-defined table.
NOTE In this standard, “entity” is used to denote the concept that is denoted “particular” in ISO/IEC 21838-1:2021). 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.
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
A class of entities having common characteristics. (SOURCE: Adapted from 19156:2011) 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
An abstraction of real world phenomena. (SOURCE: ISO 19101). For the purposes of this document, it refers to an individual realization thereof. Features can be classified as geographic and non-geographic. In the GES, the Features Requirements Class is for geographic features. For non-geographic features, see Clause 7.4 below.
Feature Store
A container for features. In the GES, a feature store is realized through a user-defined features table (for geographic features) or attributes table (for non-geographic features; see below).
Feature Type
A class of features having common characteristics. (SOURCE: Adapted from ISO 19101) In the GES, a feature type is realized through the schema of a user-defined features table (for geographic features) or attributes table (for non-geographic features; see below).
Geographic Feature
A representation of real world phenomenon associated with a location relative to the Earth. (SOURCE: ISO 19125-2:2004) In the GES, a geographic feature is realized through a row of a user-defined features table.
Geometry
A spatial object representing a geometric set. (SOURCE: ISO 19107) 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 1 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 2 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 Discrete Global Grid System (DGGS) and other organizations including irregular ones.
7.4. Attributes
GeoPackages that conform to the Attributes Requirements Class contain the content represented in Figure 10.
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 Store
a container for attributes sets. In the GES, an attributes store is realized through a user-defined attributes table.
Non-Geographic Feature Set
a user-defined type with one or attributes, none of which is a geometry. In the GES, a non-geographic feature set is realized through the schema of a user-defined attributes table.
Non-Geograpic Feature Set Type
A class of features having common characteristics. (SOURCE: Adapted from ISO 19101) In the GES, an non-geographic feature set type is realized through the schema of 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-1) 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.
8. GeoPackage Logical Model (Normative)
This section presents the normative definition of the GeoPackage Logical Model (LM). The LM 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 7.
Figure 7 — Core GeoPackage Classes
Table 1
| 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 2 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 2 — 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 8.
Figure 8 — Features GeoPackage Classes
Table 3
| 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 9.
Figure 9 — Tiles GeoPackage Classes
Table 4
| 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 10.
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 “non-geographic feature set” will be used to describe a user-defined class with multiple attributes and no geometry.
Figure 10 — Attributes GeoPackage Classes
Table 5
| 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 11.
Figure 11 — Extensions GeoPackage Classes
Table 6
| 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 12.
Figure 12 — Metadata GeoPackage Classes
Table 7
| 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 13.
Figure 13 — Schema GeoPackage Classes
Table 8
| 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 14.
Figure 14 — Tiled Gridded Coverage Extension GeoPackage Classes
Table 9
| 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 2, the Encoding Standard SHALL describe the encoding of the additional required coordinate reference system listed in Table 10. | |
Table 10 — 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 15.
Figure 15 — Related Tables GeoPackage Classes
Table 11
| 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
(informative)
Revision History
Table A.1
| 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 |
| 2022-04-15 | 0.5 | Roger Lott | multiple | correctness, clarity, and consistency |
| 2022-04-27 | 0.51 | Gobe Hobona | 8 | consistency |
| 2022-04-28 | 0.52 | Irina Bastrakova | 4 | consistency |
| 2022-05-09 | 0.6 | Carl Reed | all | review for clarity and consistency |
| 2022-08-25 | 0.7 | Jeff Yutzler | multiple | comments from open comment period |
| 2022-09-15 | 0.9 | Jeff Yutzler | all | migration to metanorma template |