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), version 1.0

>> 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), version 1.0
Description

GeoPackage 1.0 was the first release of the GeoPackage Encoding Standard from the Open Geospatial Consortium, published in 2014. Specifications in the family of GeoPackage formats (see GeoPackage_family) specify 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 designing GeoPackage 1.0 was for use on mobile devices.

A GeoPackage is a platform-independent SQLite database file that contains data and metadata tables with names and structures as defined in the standard, having specified definitions, integrity assertions, format limitations and content constraints. A useful diagram of the tables defined is Figure 1 in the Introduction (page viii). A more detailed diagram is in Appendix B, clause B.11, as Figure 4. Version 1.0 of the GeoPackage standard is based on version 3 of the SQLite file format. This 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 SQLite database file format 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 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. Feature attributes are columns in a feature table. Features are rows 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.

An SQLite database that use 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. Version 1.0 of the Geopackage Encoding Standard defines mechanisms for extension and documents a few registered extensions, including the use of WebP for image tiles.

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 GeoPackage_family, GeoPackage Encoding Standard (OGC) Format Family
    Subtype of SQLite_3, SQLite, Version 3

Local use Explanation of format description terms

LC experience or existing holdings None
LC preference  

Sustainability factors Explanation of format description terms

Disclosure Open standard documented in freely available specifications. Developed and maintained by the Open Geospatial Consortium (OGC). GeoPackage versions 1.0 and 1.0.1, as described here, are now deprecated by OGC.
    Documentation

The GeoPackage specifications can be downloaded from OGC: GeoPackage Encoding Standard. The original version, with corrigendum, can be consulted online at http://www.geopackage.org/spec101/index.html as OGC GeoPackage Encoding Standard with corrigendum.

Adoption

For adoption of the GeoPackage format in general, see GeoPackage_family.

Version 1.0 of the GeoPackage standard was published in February 2014, with a corrigendum added in April 2015. The format was rapidly adopted in whole or in part by several GIS software tools, as listed below. Version 1.1 was published on the OGC website in September or October 2016. At the same time, the version described here was marked as deprecated on the OGC website. For recent information on support for GeoPackage in software, see GeoPackage Implementations and for providers distributing data in GeoPackage format, see GeoPackage Data.

Listed here are some of the software tools that supported version 1.0 early:

In late 2014, TerraGo announced its OpenGeoPDF initiative, which includes as a first phase, support in TerraGo Publisher 6.6 for embedding feature data used in a GeoPDF file using a GeoPackage attachment rather than 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.

The compilers of this resource are not aware of adoption of GeoPackage 1.0 for distributing map products or in map delivery services. Comments welcome.

In June 2020, the New South Wales State Archives lists GeoPackage 1.0 in its list of sustainable formats.

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

External dependencies None beyond software to unpack the data structures.
Technical protection considerations The SQLite application does have an extension that supports encryption. However, the GeoPackage 1.0 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 No support for vector graphics in raster tiles. Vector graphics and other features are supported through feature tables. 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 UTF16), 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 version 1.0 of 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.

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
Defined in the standard.
Internet Media Type See note.  No internet media type was registered for this version of the GeoPackage format.
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. Defined in the standard.
Indicator for profile, level, version, etc. Octal: 47 50 31 30
ASCII: GP10
In the application id field (byte offset 68) of the SQLite database header. Indicates version 1.0 of GeoPackage. Defined in standard and SQLite magic.txt file.
Pronom PUID See note.  No corresponding match as of June 2020.
Wikidata Title ID See note.  No corresponding match as of June 2020.

Notes Explanation of format description terms

General

The GeoPackage 1.0 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 13249-3.

Extensions documented in the specification include additional geometry types, additional SQL geometry functions, and WebP as an additional tile image format.

History

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

Version 1.0 of the OGC 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, version 1.1 had been published on the OGC website and versions 1.0 and 1.0.1 had been marked as deprecated.

For later history of GeoPackage format see GeoPackage_family.


Format specifications Explanation of format description terms


Useful references

URLs


Last Updated: 06/22/2020