Sustainability of Digital Formats: Planning for Library of Congress Collections

Introduction | Sustainability Factors | Content Categories | Format Descriptions | Contact
Format Description Categories >> Browse Alphabetical List

GeoPackage Encoding Standard (OGC) Format Family

>> Back
Table of Contents
Format Description Properties Explanation of format description terms

Identification and description Explanation of format description terms

Full name GeoPackage Encoding Standard (OGC) family of formats
Description

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.

Production phase Primarily a middle-state format for a package of tiled raster images and/or vector features that can be transmitted between applications.
Relationship to other formats
    Subtype of SQLite_3, SQLite, Version 3
    Has subtype GeoPackage_1_0, GeoPackage Encoding Standard (OGC), version 1.0. Deprecated on OGC website in October 2016.
    Has subtype Chronological versions not described separately on this website. See list of published versions at https://www.ogc.org/standards/geopackage.
    Used by GeoPDF_file, GeoPDF File Format (TerraGo). GeoPDF files as produced by TerraGo software products may include an attachment in the GeoPackage format. The TerraGo GeoPDF Toolbar provides support for users of GeoPDF files, including extraction of the GeoPackage attachment.
    Has extension Extensions documented in separate specifications and not described separately on this website. See extensions listed at https://www.ogc.org/standards/geopackage.
    May contain WKT, Well-known Text

Local use Explanation of format description terms

LC experience or existing holdings As of May 2024, the Library of Congress has a small number of GeoPackages in its collections but the specific version of GeoPackage is unknown.
LC preference The Library of Congress Recommended Formats Statement (RFS) designates GeoPackage as a "preferred" format for GIS Vector Data, GIS Vector and Raster Combined data, as well as GIS Raster and Georeferenced Images for GIS, Geospatial and Non-GIS Cartographic collection materials. The RFS does not specify a version of GeoPackage.

Sustainability factors Explanation of format description terms

Disclosure Open standard, documented in freely available specifications. Developed and maintained by the Geopackage Standards Working Group (SWG) of the Open Geospatial Consortium (OGC). See Charter for the GeoPackage SWG. Information about the development work is available on the Geopackage.org website (https://www.geopackage.org/), which provides access to the current working version as well as earlier versions approved by the OGC.
    Documentation

The GeoPackage specifications can be downloaded from two locations:

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

Adoption

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:

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.

    Licensing and patents No apparent concerns. SQLite, on which GeoPackage is built is a relational database software package for which source code and documentation is in the public domain. The OGC GeoPackage Encoding Standard document is made available on a royalty free, non-discriminatory basis. The document includes a boilerplate call for OGC to be notified of any patents that implementations of the specification might infringe.
Transparency One intent of the GeoPackage format is to have a compact representation appropriate to use for applications on mobile devices. Compact, binary representations of information are inherently less easy for human readers. The .gpkg file is in the SQLite database file format. Open source software is available for viewing and manipulating SQLite files, for example, DB Browser for SQLite.
Self-documentation

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.

External dependencies None beyond software to unpack the data structures.
Technical protection considerations The SQLite application has an extension that supports encryption. However, the GeoPackage specification does not provide for any encryption within the package.

Quality and functionality factors Explanation of format description terms

Still Image
Normal rendering Raster image tiles can be in JPEG_DCT_BL or PNG encodings in the standard GeoPackage.
Clarity (high image resolution) Limited to 8-bits per channel.
Color maintenance See JPEG_DCT_BL or PNG.
Support for vector graphics, including graphic effects and typography Vector graphics and other features are supported through feature tables. No support for vector graphics in raster tiles. See Dataset and GIS factors below.
Support for multispectral bands No support within a single raster image layer.
Dataset
Normal functionality

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.

Support for software interfaces (APIs, etc.)

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

Data documentation (quality, provenance, etc.)

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

GIS images and datasets
Normal functionality

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.

Support for GIS metadata

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


File type signifiers and format identifiers Explanation of format description terms

Tag Value Note
Filename extension gpkg
Specified in all versions of the standard.
Internet Media Type application/geopackage+sqlite3
Registered at IANA by OGC in 2018 for GeoPackage Version 1.2. See https://www.iana.org/assignments/media-types/application/geopackage+sqlite3. The compilers of this resource have not determined the degree to which this media type has been adopted and whether it is used with files in other versions of the GeoPackage Encoding Standard. Comments welcome.
Magic numbers Hex: 53 51 4c 69 74 65 20 66 6f 72 6d 61 74 20 33 00
ASCII: SQLite format 3
In first 16 bytes of the file. Specified in all versions of the standard. Applies to all SQLite database files.
Magic numbers Hex: 47 50 4B 47
ASCII: GKPG
In the application_id field (byte offset 68) of the SQLite database header. Specific to GeoPackage files. Applies to Version 1.2 and greater Version 1.0 has value "GP10". Version 1.1 has value "GP11".
Indicator for profile, level, version, etc. See note.  A GeoPackage contains a value in the user_version field of the SQLite database header to indicate its version. The value is a 5-digit integer with a one-digit major version, two-digit minor version, and two-digit bug-fix. For example, for Version 1.2, this is 10200 (Hex: 00 00 27 D8).
Other NF00795
See https://www.archives.gov/files/lod/dpframework/id/NF00795.ttl. NARA does not identify versions as of May 2024.
Pronom PUID See related format.  See GeoPackage Encoding Standard (OGC), version 1.0
Wikidata Title ID Q22908624
See https://www.wikidata.org/wiki/Q22908624. Wikidata does not distinguish versions as of May 2024.

Notes Explanation of format description terms

General

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.

History

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


Format specifications Explanation of format description terms


Useful references

URLs


Last Updated: 05/17/2024