Fork me on GitHub
Visit the OGC
GeoPackage

An Open Format for Geospatial Information

GeoPackage is an open, standards-based, platform-independent, portable, self-describing, compact format for transferring geospatial information.

The GeoPackage Encoding Standard describes a set of conventions for storing the following within an SQLite database:

  • vector features
  • tile matrix sets of imagery and raster maps at various scales
  • attributes (non-spatial data)
  • extensions

To be clear, a GeoPackage is the SQLite container and the 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. These capabilities are built on a common base and the extension mechanism provides implementors a way to include additional functionality in their GeoPackages.

Since a GeoPackage is a database container, it supports direct use. This means that the data in a GeoPackage can be accessed and updated in a "native" storage format without intermediate format translations. GeoPackages that comply with the requirements in the standard and do not implement vendor-specific extensions are interoperable across all enterprise and personal computing environments. GeoPackages are particularly useful on mobile devices such as cell phones and tablets in communications environments where there is limited connectivity and bandwidth.

See the "e-Learning Course"

Highlighted News
OGC has adopted GeoPackage 1.4.0, a new version of the encoding standard.
Official Standards Information

For all official, normative information on the GeoPackage standard, including PDF format download, see the OGC standards program GeoPackage page. Links below provide access to HTML editions of the published OGC standards.

OGC GeoPackage 1.4.0

OGC GeoPackage 1.3.1

OGC GeoPackage 1.3.0

OGC GeoPackage 1.2.1

OGC GeoPackage 1.2.0

OGC GeoPackage 1.1.0

OGC GeoPackage 1.0.1

Official Test Suite
OGC has developed an executable test suite for portions of the GeoPackage standard. For information on installing and running the test suite locally, see the GitHub page.


FAQ

Q How did GeoPackage come about?

A It was designed and prototyped following a multi-year, open process of requirements testing and public input.


Q Can GeoPackage be extended?

A It is designed for extension. If you need more than the core GeoPackage feature set, you may submit an issue at the issue tracker. In addition, you may join OGC's open process to standardize community-tested enhancements. For more information on the standards working group, go to http://www.opengeospatial.org/projects/groups/geopackageswg.


Q Does GeoPackage replace Shapefile?

A It could but it doesn’t have to. If all you need is simple exchange and display then GeoPackage may be overkill and something like GeoJSON may be more appropriate. If you are looking for database capabilities like random access and querying then GeoPackage is a platform-independent, vendor-independent choice. GeoPackage was carefully designed this way to facilitate widespread adoption and use of a single simple file format by both commercial and open-source software applications — on enterprise production platforms as well as mobile hand-held devices.


Q How do you define the spatial extents for your tile pyramid?

A There are two places for the extents. The first, in gpkg_contents, is designed to declare the extents of the content. This one will often be used by applications to define the default view of the tiles. (That means that if a GeoPackage indicates global extents in gpkg_contents, an app is likely to open up the whole world even though it is probably not what the user wants.) The second is in gpkg_tile_matrix_set. It defines the extents of the tile pyramid and is used to calculate the boundaries of each tile in the tile matrix set.


Q Can you mix JPG and PNG files within the same tile pyramid?

A Yes. This technique is particularly useful at edges or holes of your tile pyramid. While JPG tiles are preferred for imagery due to their increased compression, they do not support transparency. It is common to use PNG tiles in the relatively small number of tiles that do not have complete coverage so that you can use its transparency capability.


Q What security capabilities does GeoPackage support?

A As a file encoding, GeoPackage has no explicit security capabilities. However, some organizations have had success with the SQLite Security Extension (SEE).


Q What is the intended content model for the metadata tables?

A We deliberately left this open-ended. We expect that communities of interest will produce profiles of GeoPackage that will specify the metadata (content and format) appropriate for their domain.


Q How are GeoPackage files shared between apps on iOS and Android devices?

A OGC does not yet have a methodology or best practice for sharing files between apps on mobile devices. On Android there are a couple of different options. With some of the newer updates, Android has some interesting security constraints. There could be a nice solution using the ContentProvider API.

On the iPhone, the security issues of the device cause a lot of problems for cross-app file sharing. Inherently, the device does not want applications to share data except in very narrowly defined ways. So data sharing between apps is not feasible at this time.


Q What is the relationship between GeoPackage and SpatiaLite?

A SpatiaLite was a major influence on the vector portions of GeoPackage but after extensive discussions, the working group chose to diverge from the SpatiaLite format in a few subtle ways. SpatiaLite now supports GeoPackage as of version 4.2.0.


Q What is the relationship between GeoPackage and MBTiles?

A MBTiles was a major influence on tile support in GeoPackage. In addition to being an international standard, GeoPackage differs from MBTiles in a few ways.

  • MBTiles only supports tiles in the Spherical Mercator projection. While this is the default in GeoPackage, other projections are supported through an extension.
  • MBTiles only supports a single tileset in a file. GeoPackage supports multiple tile sets in a single file, as well as feature data and metadata.
  • The two specifications use a different convention for tile numbering.


Q Why does GeoPackage use a different Well-Known Binary (WKB) encoding than PostGIS or SpatiaLite?

A The original OGC/ISO standard for WKB does not contain all of the information we wanted to store. In response, both PostGIS and SpatiaLite developed their own ad hoc extensions. After much deliberation, the Standards Working Group (SWG) agreed not to standardize on either of them. Instead, the SWG decided to add additional information to the header so that standard WKB parsers/marshalers could be used for the bulk of the geometry.


Q Is there a media type (formerly MIME type) for GeoPackage?

A There is now: application/geopackage+sqlite3.


Q How do I model multiple geometries in the same feature?

A See the modeling guidelines page.


Q What is meant by a "native" GeoPackage library?

A A native GeoPackage library is a library that is native to the device's operating system. Note that individual vendors may create their own native GeoPackage libraries to support different use cases. A library written in Go to support server-side operations may have a completely different API than an Android or iOS library with an API designed to support a mobile application. The GeoPackage standard is agnostic to libraries and APIs, focusing instead on the contents of the GeoPackages that act as inputs or outputs.


Q What were the reasons to go with SQLite, when OGC has invested heavily in PostGIS?

A OGC has not invested in PostGIS, rather PostGIS implements OGC standards. PostGIS is just like any other RDBMS implementation of the Simple Features spec. The primary use case for designing GeoPackage was mobile device use, and that's why SQLite was chosen as a platform. In this case OGC as an organization is specifying a technology. This is unusual for OGC and the decision was not made lightly, but practicality and ease of implementation won out over standards purity. And we are happy to say we have yet to get any negative feedback on this decision -- probably because SQLite is considered more like a library than a standalone application.