The GeoPackage specification describes a set of conventions for storing the following within an SQLite database: These capabilities are built on a common base and an extension Mechanism is described to provide implementors a way to include additional functionality in their GeoPackages. Since a GeoPackage is a database, it supports direct use, meaning that its data can be accessed and updated in a ‘native’ storage format without intermediate format translations. GeoPackages are interoperable across all enterprise and personal computing environments, and are particularly useful on mobile devices like cell phones and tablets in communications environments with limited connectivity and bandwidth. Donec id elit non mi porta gravida at eget metus. Fusce dapibus, tellus ac cursus commodo, tortor mauris condimentum nibh, ut fermentum massa justo sit amet risus. Etiam porta sem malesuada magna mollis euismod. Donec sed odio dui. Donec id elit non mi porta gravida at eget metus. Fusce dapibus, tellus ac cursus commodo, tortor mauris condimentum nibh, ut fermentum massa justo sit amet risus. Etiam porta sem malesuada magna mollis euismod. Donec sed odio dui. Donec id elit non mi porta gravida at eget metus. Fusce dapibus, tellus ac cursus commodo, tortor mauris condimentum nibh, ut fermentum massa justo sit amet risus. Etiam porta sem malesuada magna mollis euismod. Donec sed odio dui. This GeoPackage contains a raster tile pyramid that was created with free imagery obtained from Geomatics Yukon and covers an approximately 30 square-kilometer area centered on the City of Whitehorse. It uses the Web Mercator (EPSG:3857) coordinate reference system, 256×256 pixel tiles, contains zoom levels 11-18, and is 110.8MB in size. A It was designed and prototyped following a multi-year, open process of requirements testing and public input. 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. 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. 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. 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. 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. 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. 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. Source.