Sustainability of Digital Formats: Planning for Library of Congress Collections

A GeoPackage is a platform-independent SQLite database file that contains data and metadata tables with names and structures having definitions, integrity assertions, format limitations and content constraints as described in the OGC GeoPackage Encoding Standard from the Open Geospatial Consortium. The first version of this standard was published in February 2014. All versions of the GeoPackage Encoding Standard are based on version 3 of the SQLite file format. As described in #GeoPackageDay 2020 - what is GeoPackage? (February 2020) (link via Internet Archive), in addition to interoperability, GeoPackage was devised with three main goals in mind: to be a convenient, efficient container for geospatial information; to enable operations in all computing environments, including those with Disconnected, Degraded, Intermittent, or Limited (DDIL) network connectivity; and to be extensible, allowing it to evolve to meet future operational needs.

The GeoPackage Encoding Standard specifies GeoPackages for exchange and GeoPackage SQLite Extensions that permit direct use, without intermediate format translations, of vector geospatial features and/or tile matrix sets of earth images and raster maps at various scales. GeoPackages are designed to be interoperable across enterprise and personal computing environments and usable on mobile devices with limited connectivity and bandwidth.  An important use case for the design of GeoPackage was for mobile device use, leading to an emphasis on compactness and computational efficiency. The SQLite database file format is a binary format and uses b-trees to store table data.  B-trees support rapid access to data within tables, and are a basic technique used for organizing data for sorting and searching.  The specification cites the particular b-tree algorithms used.  The algorithms are described in Donald Knuth's The Art of Computer Programming [LCCN: 97002147], Volume 3, pages 471-479.

A useful diagram of the database tables in a GeoPackage is Figure 1 in the Introduction to the standard. A more detailed diagram is in Appendix B, clause B.11, as Figure 4.

A GeoPackage has two required tables:

• The gpkg_spatial_ref_sys table documents coordinate reference systems used for data in the package. It must include a record for WGS-84.
• The gpkg_contents table provides identifying and descriptive information for the tables containing data. It acts as a directory of the primary content in the file.

A GeoPackage may incorporate data for vector features and/or for tiled raster images.

• Vector feature data: A GeoPackage with vector feature data has a gpkg_geometry_columns table that identifies the geometry columns in feature tables, which contain user data representing features. Geometries supported include, points, curves, lines, polygons, etc. See GIS functionality factors for a complete list. Features are rows in a feature table. Feature attributes are columns in a feature table.
• Raster image data: A GeoPackage can store multiple raster and tile pyramid data sets. In a standard GeoPackage, tiles may be in JPEG or PNG encoding.

A GeoPackage can also include:

• Attributes (non-spatial data): Non-spatial attribute data are sets (or tuples or rows) of observations that may not have an explicit geometry property. This data is stored in user-defined attribute tables. These tables may contain properties such as an ID or geo-locatable address that allow them to be relationally linkable to rows in other attribute, feature or tile tables. Note: this feature was introduced in Version 1.2, but had been available as a documented extension prior to that.
• Extensions: An SQLite database that uses constructs from the GeoPackage specification but also contains additional data elements (tables or columns) or SQL constructs (data types, functions, indexes, constraints or triggers) that are not specified in the GeoPackage Encoding Standard, is referred to as an Extended GeoPackage.

  GeoPackage Version 1.0 documented a few registered extensions in individual annexes. Since Version 1.1, Annex F of the Geopackage specification lists registered extensions, with a subclause for each. All extensions are optional, but examples of recommended use of extensions include: (a) using the RTree Spatial Indexes extension, based on the The SQLite R*Tree Module for GeoPackages with a "non-trivial amount of vector data"; (b) using the WKT for Coordinate Reference Systems extension, based on version 2.0.x of https://www.ogc.org/standards/wkt-crs, which is strongly recommended due to inherent weaknesses in the original GeoPackage standard for encoding coordinate reference systems. Use of the Tiles Encoding WebP extension is required to allow representation of raster image tiles in the WebP format. Since GeoPackage 1.1, there has been a registered Metadata extension, designed for incorporating metadata defined in accordance with any authoritative metadata specifications, and relating it to the features, rasters, and tiles data in a GeoPackage. This is intended to provide the support necessary to implement the hierarchical metadata models as defined in ISO 19115.

The family of OGC GeoPackage format specifications includes several chronological versions of the core standard and specifications for a few extensions. See Notes below for more detail. Extensions are discussed in General Notes; chronological versions are listed in History.

The GeoPackage specifications can be downloaded from two locations:

• OGC: GeoPackage Encoding Standard on the OGC website.
• GeoPackage.org website

At any point, the current working version is available at https://www.geopackage.org/spec/.

For information from OGC on support for GeoPackage in software, see GeoPackage Implementations and Implementations by Specification for GeoPackage 1.2. The latter resource also lists support for particular extensions. OGC provides the GeoPackage 1.2 Conformance Test Suite to verify the structure and content of a GeoPackage 1.2 data container file.

As of June 2020, examples of GIS software tools that provide support for GeoPackage files include:

• GDAL (Geospatial Data Abstraction Library), a driver library used by other GIS products. Starting with GDAL 2.2, the driver has been able to create GeoPackage databases following the 1.0/1.0.1, 1.1 or 1.2 versions. For GDAL 2.2, it will automatically adjust to the minimum version required for the features of GeoPackage used. For GDAL 2.3 or later, it will default to 1.2. Explicit version choice is possible by specifying the VERSION dataset creation option. GDAL also supports a number of the published extensions to GeoPackage. See GPKG – GeoPackage vector and GPKG – GeoPackage raster for details. GDAL is used by many applications for import, export, and transformation of geospatial data, such as Cadcorp SIS and the open-source QGIS. See Software using GDAL.
• SAFE software's FME (Feature Manipulation Engine) has had a Reader and Writer for GeoPackage since 2015. See OGC GeoPackage Reader/Writer.
• ESRI ArcGIS has had support for GeoPackage vector features since 2014. See Esri Leads in Supporting OGC Standards (2014) and How to Use OGC GeoPackages in ArcGIS Pro (2020).
• GeoPackage Libraries, made available by the U. S. National Geospatial-Intelligence Agency (NGA).
• Global Mapper from Blue Marble Geographics.
• Luciad Portfolio products from Hexagon, for example, LuciadMobile. Hexagon GeoMedia also has support for GeoPackage.
• MapLink Pro from Envitia.
• Carto platform for developing applications based on geospatial data and analysis. See 2018 blog post Beyond the Shapefile with File Geodatabase and GeoPackage.
• GeoTools, an open-source Java code library. See GeoPackage Plugin.

Since late 2014, TerraGo Technologies has used GeoPackage files for embedding feature data in its GeoPDF files rather than a proprietary implementation of Adobe's object data mechanism. TerraGo Toolbar 6.6's Identify tool can display the feature attributes. The GeoPackage file can be extracted and saved as a separate file.

For providers distributing data in GeoPackage format, see GeoPackage Data from the GeoPackage SWG. As of June 2020, this page indicates that government entities in Australia, New Zealand, and the United Kingdom are using GeoPackage as a distribution format for important products. For example, the U. K. Ordnance Survey is making a number of its OpenData products available in GeoPackage format. See OS OpenData products now available in GeoPackage format from April 2019. See also BGS Geology | DiGMapGB. Layers from the OpenStreetMap are available (updated monthly) as GeoPackage files from https://download.osmdata.xyz/.

The United States Geological Survey (USGS) is beginning to make use of the GeoPackage format for distributing data, particularly for very large datasets. In January 2018, the United States Geological Survey (USGS) National Geospatial program announced that it was investigating distributing spatial data in the open GeoPackage format to supplement and extend its FGDB (Esri File Geodatabase) and spatial web services deliveries. The U.S. Interagency Elevation Inventory can be downloaded as a GeoPackage. The inventory is a resource that identifies by geographic location in the United States and its territories the elevation-related data available from NOAA, U.S. Geological Survey, Federal Emergency Management Agency, U.S. Army Corps of Engineers, U.S. Department of Agriculture - Natural Resources Conservation Service, U.S. Forest Service, and National Park Service. For other examples of the use of GeoPackage for data distribution by governmental entities in the United States, see Useful References below.

In June 2020, the New South Wales State Archives (link via Internet Archive) lists GeoPackage 1.0 in its list of sustainable formats. The compilers of this resource would welcome information about other recommendations for the GeoPackage format from archival entities that collect and preserve geospatial datasets. Comments welcome.

The format defines an optional table gpkg_data_columns to hold descriptions of the data field in a specified column, including: short name, title, description, and a link to descriptions of constraints (min/max, etc.) stored in a supplementary table, gpkg_data_column_constraints.

The format also defines an optional gpkg_metadata table, which may contain metadata in encodings for which MIME types exist (with a default of text/xml) based on any authoritative metadata specification, such as ISO 19115, ISO 19115-2, ISO 19139, Dublin Core, CSDGM, DDMS, NMF/NMIS, etc. The GeoPackage interpretation of what constitutes metadata is broad. It also includes UML models encoded in XMI, GML Application Schemas, ISO 19110 feature catalogues, OWL and SKOS taxonomies, etc. A GeoPackage that contains a gpkg_metadata table is required to have a gpkg_metadata_reference table to associate metadata in the gpkg_metadata table with data in the feature, and tiles tables. The two tables are intended to provide the support necessary to implement the hierarchical metadata model defined in ISO 19115. Metadata values can be associated with the entire geopackage or to a table, column, row, or table cell (row/col).

In the specification for version 1.0, the tables to hold metadata were described in the main specification (clause 2.4). Since version 1.1, this content has been described as an "extension" in Annex F. The compilers of this resource are not aware of substantive changes in the structure of the tables. Comments welcome.

Accessibility Features

Accessibility features for GIS data can be a complex combination of factors to support still images, 3D formats, and datasets. In general, this means data to alt text for images, content for screen readers to enable user interactivity events such as object selection, rotation and zoom, alt text for image forms, color contrast definition as well as caption and subtitle support as well as structured data to identify regions and grids on pages and defined relationships in tables. Depending on implementation, GeoPackage files have the potential for good accessibility support with its defined structures and focus on interoperability but this will also depend on the subtypes. Comments welcome.

Data types from SQLite supported are: boolean, tinyint (8 bits), smallint (16 bits), mediumint (32 bits), int/integer (64 bits), float (32 bits), double/real (64 bits), text (UTF-8 or UTF-16), blob, date (YYYY-MM-DD, stored as text), datetime (YYYY-MM-DDTHH:MM:SSSZ stored as text). Also defined is a type for representing a geometry type, typically selected from a set defined in the standard but optionally user-defined. The blob datatype appears to be usable in limited circumstances, either using a structure fully defined in the standard, or associated with a MIME type.

A package compliant with the encoding standard is intended to provide SQL access to its contents via SQLite version 3 software APIs.

The format allows embedding of rich metadata of all types. See Self-documentation in Sustainability Factors above.

Each table for features or tiles must have an associated spatial reference system. If the srs_id column value references a geographic coordinate reference system (CRS), then the min/max x/y values are in decimal degrees; otherwise, the srs_id references a projected CRS and the min/max x/y values are in the units specified by that CRS. The gpkg_spatial_ref_sys table in a GeoPackage is required to include a record for WGS-84.

Geometry types supported in a GeoPackage include: Point,Curve, LineString, Surface, CurvePolygon, Polygon, GeometryCollection, MultiSurface, MultiPolygon, MultiCurve, MultiLineString, MultiPoint. These are based on ISO/IEC 13249-3:11, Information technology — Database languages — SQL Multimedia and application packages — Part 3: Spatial. ISO/IEC 13249 is often referred to as SQL/MM.

The format allows embedding of rich metadata of all types. See Self-documentation in Sustainability Factors above.

The standard requires that a Geopackage satisfy two integrity checks that are optional for SQLite database files in general, but supported by SQLite PRAGMA software. The SQLite PRAGMA integrity_check SQL command must return ok for a GeoPackage. The SQLite PRAGMA foreign_key_check SQL with no parameter value must return an empty result set indicating no invalid foreign key values.

The standard defines a StandardGeoPackageBinary subformat used to record feature table geometries with or without optional elevation (Z) and/or measure (M) values in SQL blobs. This subformat is based on Well-Known Binary as defined in ISO/IEC 13249-3:2011 [Information Technology -- Database languages -- SQL multimedia and application packages -- Part 3: Spatial] clause 5.1.46, with the addition of an explicit encoding for an empty point set, which is not defined in ISO/IEC 13249-3.

Extensibility of GeoPackage format: Clause 2.3 of the specification defines an extension mechanism using an optional gpkg_extensions table and provides guidance on development of extensions. Registered extensions are documented in Annex F of the specification and include additional geometry types, additional SQL geometry functions, and WebP as an additional tile image format. Extensions documented in separate OGC specifications include OGC GeoPackage Extension for Tiled Gridded Coverage Data and OGC GeoPackage Related Tables Extension. See GeoPackage Extensions on GeoPackage.org for a list of extensions that have been considered in testbeds or by a particular community. Examples include extensions for 3D Tiles (link via Internet Archive) and for Dataset Provenance Metadata. The compilers of this resource have not attempted to determine whether any of the extensions not endorsed by OGC as of June 2020 are being used in practice. Comments welcome.

Some history and influences on the format development are described by Even Rouault (a GDAL developer) in a 2014 blog post.

The family of GeoPackage format specifications includes several chronological versions of the core standard.

• Version 1.0 of the GeoPackage Encoding Standard was approved on January 19, 2014 and published on February 12, 2014. A corrigendum was published in April 2015. By October 2016, versions 1.0 and 1.0.1 had been marked as deprecated.
• Version 1.1 (originally expected to be version 1.0.2) was published in September or October 2016. GeoPackage 1.1 was described as a technical amendment to version 1.0.1 because a number of substantive changes altered conformance requirements. Many changes were corrections to the Tiles portion of the specification. Other changes were re-organization, particularly for documentation of existing extensions, for improved readability and usability. See Revision Notes for OGC Implementation Standard GeoPackage v1.1.
• Version 1.2 was published in August 2017, with a corrigendum published in September 2018 as version 1.2.1.  An important addition was the addition of support for tables of non-spatial attributes. Other changes included: updated versioning mechanism, to allow for version increments in SQLite header; and deprecation of some extensions related to user-defined geometry types because they were not sufficiently defined to ensure interoperability.  See Release Notes for OGC GeoPackage Encoding Standard v1.2 and Release Notes for OGC GeoPackage Encoding Standard v1.2.1.
• Version 1.3 was available for public comment in May 2020. Described as a minor revision to the current version 1.2.1. Substantive changes included: clarifying use of views in user-defined tables; requiring IDs for Spatial Reference Systems (SRS) to be consistent between gpkg_contents and the two dependent tables, gpkg_geometry_columns and gpkg_tile_matrix_set; allowing metadata scopes to be extended; loosening the restriction on user-supplied schemas for applicability to attributes and extensions; enforcing consistent encoding for empty geometries. See Release Notes for OGC GeoPackage Encoding Standard v1.3.0.

The GeoPackage blog provides more insight on issues concerning changes between versions.

At any point, the current working version is available at https://www.geopackage.org/spec/.