coordinate system that is related to the real world by a datum [ISO 19111]

set of mathematical rules for specifying how coordinates are to be assigned to points [ISO 19111]

collection of data, published or curated by a single agent, and available for access or download in one or more formats [DCAT]

abstraction of real world phenomena [ISO 19101-1:2014]

a set of features from a dataset

Distance of a point from a chosen reference surface measured upward along a line perpendicular to that surface. [ISO 19111] Note 1 to entry: A height below the reference surface will have a negative value, which would embrace both gravity-related heights and ellipsoidal heights.

curve composed of straight-line segments (aka line) [ISO 19136:2007]

planar surface defined by 1 exterior boundary and 0 or more interior boundaries [ISO 19136:2007]

a platform-independent SQLite database file that contains GeoPackage data and metadata tables with specified definitions, integrity assertions, format limitations and content constraints.

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

A GeoPackage that contains features per clause Features and/or tiles per clause Tiles and row(s) in the gpkg_contents table with data_type column values of "features" and/or "tiles" describing the user data tables.

quantity having direction as well as magnitude

Note to entry: A directed line segment represents a vector if the length and direction of the line segment are equal to the magnitude and direction of the vector. The term vector data refers to data that represents the spatial configuration of features as a set of directed line segments. [ISO 19123:2005]

representation of geometry through the use of constructive geometric primitives [ISO 19107:2003]

A collection of pure CDB Datasets and/or user-defined datasets. Please see section 3.2 of Volume 1: OGC CDB Core Standard: Model and Physical Data Store Structure for details on the CDB versioning strategy and structure.

GPKG GeoPackage

Identifiers

The normative provisions in this standard are denoted by the URI http://www.opengis.net/spec/cdb-vector-geopackage/1.2

All requirements and conformance tests that appear in this document are denoted by partial URIs which are relative to this base.

A GeoPackage is the SQLite container and the OGC GeoPackage Encoding Standard governs the rules and requirements of content stored in a GeoPackage container. The GeoPackage Standard defines the schema for a GeoPackage, including table definitions, integrity assertions, format limitations, and content constraints. The required and supported content of a GeoPackage is entirely defined in the standard.

CDB is an open standard defining physical, logical, and conceptual models for a single, “versionable,” virtual representation of the earth. CDB structured data stores provide for a geospatial content and model definition repository that is plug-and-play interoperable between database authoring workstations. Moreover, a CDB structured data store can be used as a common online (or runtime) repository from which various simulator client devices can simultaneously retrieve and modify, in real-time, relevant information to perform their respective runtime simulation tasks (OGC CDB Standard, 2018).

The geometries supported by the GeoPackage standard are consistent with the OGC Simple Feature Standard. A GeoPackage is capable of storing feature geometries as Points, LineStrings, Polygons, MultiPoints, MultiLineStrings, MultiPolygons, and GeomCollection. A strength of the GeoPackage is the portability and utility in non-traditional simulation environments, such as hand-held tactical devices. These strengths and the self describing nature of a GeoPackage created demand not just in the traditional modelling and simulation community but also other domains for having the ability to use GeoPackages in a CDB data store.

When working with vector feature data, one of the properties is the feature’s geometry. A geometry is an ordered sequence of vertices that are connected by straight line segments or circular arcs. The semantics of the geometry are determined by its type. The GeoPackage core supports six geometry types. Other types may be used but their definition and use requires development of a GeoPackage extension. The GeoPackage in CDB standard is based on the core geometry types and does not require any extensions to support additional geometries.

Further, the GeoPackage standard allows the additional specification of "Z" values and "M" values. Z values may be thought of as "elevation". However, the use of "elevation" is inexact. Instead this standard uses the term height to define the semantics of the Z values. "M" stands for measurement. Measurements could be such properties as "temperature" or "reflectance". Whether Z and or M values are part of a given GeoPackage is determined by what values are set for the z and m columns in the GeoPackage Geometry Columns Table Definition. These are optional values.

Geometries are stored as binary blobs in a GeoPackage. Please read GeoPackage clause 2.1.3. Geometry Encoding carefully. This clause defines the binary encoding used and references OGC/ISO Well Known Binary Types (WKB) OGC WKB simple feature geometry types specified in OGC 06-103r4 are a subset of the ISO WKB geometry types. WKB geometry types are are restricted to 0, 1 and 2-dimensional geometric objects that exist in 2, 3 or 4-dimensional coordinate space. They are not geographic or geodesic geometry types. The axis order in WKB is always (x,y{,z}{,m}) where x is easting or longitude, y is northing or latitude, z is optional elevation and m is optional measure.

The following table provides a summary of the GeoPackage geometry types in relation to Shapefile geometries. As can be seen, the GeoPackage core set of geometry types is 100 percent compatible with the Shapefile geometry types.

While previous work focused on the process and requirements for transforming CDB structured vector Shapefiles into GeoPackages, the identified use cases are apropos when defining how to store and access any other vector/geometry content regardless of encoding or format. This has to do with how the data are physically structured in a GeoPackage container.

However, vector data encodings and containers developed outside a CDB data transformation process would also require definition of additional requirements. For example, a GeoJSON encoding of feature data would require a transformation to "break" the GeoJSON file into the appropriate tile and LoD structure in order to be consistent with the CDB data store and structure requirements. The same would be true of vector data provided as none CDB structured Shapefiles, CityGML encodings, Oracle Spatial structured data, Esri GeoDataBase files and so on.

Both the OGC OGC CDB - Leveraging GeoPackage Discussion Paper and the OGC CDB Vector Data in GeoPackage Interoperability Experiment Engineering Report focused on a constrained set of well defined use cases related to the current CDB structure and how to best use GeoPackage for resolving each of the use cases. As such, dealing with non-CDB structured vector content was not addressed.

The four initial use cases identified in the OGC Discussion Paper are:

In all cases, the experimentation focused on just vector data encoding as Shapefiles.

The research and tests performed and reported in the Discussion Paper were refined and provided the basis for the work done in the OGC GeoPackage in CDB Interoperability Experiment. In the interoperability experiment, Use Case 1 above was further refined into 4 options - each a possible approach for one to one conversions. All options were tested and reported on by the participants. Many of the lessons learned, independent of the IE focus on Shapefiles already in a CDB, are germane to any process or workflow in which data are stored in a GeoPackage container that is to then be stored in a CDB data store.

If you wish to transform CDB structured Shapefiles into CDB structured GeoPackages, please refer to the Volume 14: OGC CDB Guidance on Conversion of CDB Shapefiles into CDB GeoPackages (Best Practice) add URL and description when document is available.

This section defines the GeoPackage requirements that need to be considered when implementing a CDB compliant GeoPackage for use in a CDB data store. This section also provides any clarifications and/or profiles of those requirements.

This section documents the CDB requirements that need to be considered when implementing a CDB compliant GeoPackage for use in a CDB data store. This section also provides any clarifications and/or profiles of those requirements. The majority of the requirements referenced in this section are detailed in Volume 1: OGC CDB Core Standard: Model and Physical Data Store Structure (hereafter known as CDB Core). In the GeoPackage in CDB standard, requirements are specified that themselves reference specific requirements in the Core

This section describes conformance tests for the the optional extension to the CDB standard for structuring and storing any vector data as a GeoPackage container. These abstract test cases describe the conformance criteria for verifying the structure and content of any data store or database claiming conformance to the CDB 1.2 standard.

The conformance class base id is “http://www.opengis.net/spec/cdb/1.2/” and all of the other conformance tests URLs are created in this path. Each conformance class then appends: "/conf/cdb-core/geopackage" to this base ID. Another issue that the reader should pay attention to is the test method. When the test method is assigned with “Visual”, it means that the purpose of the test should be “visually” investigate the file contents, image, or other content.