GPKG is the OGC GeoPackage format for storing vector and raster spatial data within an SQLite database container within a single .gpkg file. As an interchange format, GPKG is a well-implemented, capable format that is clearly superior to older formats such as shapefiles. We can export drawings and tables to GPKG files. Manifold can also create Manifold virtual computed fields within GPKG.
When copying and pasting a drawing into a GPKG database or when exporting a drawing to GPKG, Manifold writes the coordinate system of the drawing in WKT format into the GPKG system table, where it can be accessed by third-party applications.
Important: GPKG requires the installation of third-party software. A fast and simple installation package is available from the Manifold product downloads page. Use that package and install as recommended below. Using packages from other sources is not recommended. See the discussion at the end of this topic for information on installing the third-party software required.
There are two main limitations to GPKG:
GPKG requires the installation of third-party software. GPKG does not work if we have not installed the third-party DBMS software it requires.
GPKG is a slow format for large numbers of objects. As a spatial DBMS it is far slower than PostgreSQL. It is fine as an interchange format for larger numbers of objects but only if we understand that after we import from GPKG we will work with the data either within Manifold (superfast) or save the data within a fast DBMS like PostgreSQL.
We can either import data from GPKG into a Manifold .map project or we can leave the data within the GPKG file and link to it to enable editing or other use of the data "in place" within the GPKG. Which we choose will depend on the number of objects involved, the speed of GPKG we can tolerate or not tolerate, and the convenience of keeping data within the GPKG for any interchange requirements.
Compared to fast databases like PostgreSQL, GPKG is a slower format and is generally too slow to use with larger numbers of objects. A 1.3 GB GPKG is too slow to use, while the same data stored in PostgreSQL would be acceptably fast, and the same data stored in Manifold .map format would be pleasantly fast.
Important: When importing a GPKG file the tables, images and drawings that appear in the Manifold project are Manifold components with no further connection to the GPKG file from which they were imported.
To import from GPKG format:
Choose File-Import from the main menu.
In the Import dialog browse to the folder containing data of interest.
Double-click the .gpkg file desired.
Everything found in that .gpkg database will be imported into the project.
Double-clicking on the desired .gpkg file in the Import dialog as seen above will import into our project everything found in that .gpkg database. This particular GPKG file is one of the samples published by OGC.
The .gpkg database contains a drawing and an image. Those have been imported together with all of the GPKG database infrastructure tables required to organize the DBMS built into the file. We can double-click on the image or the drawing to open them.
For a more interesting display, we first create a new data source using a Google street maps imageserver as shown in the Example: An Imageserver Tutorial topic. We then create a map and drag and drop the Google layer into the map, and then we drag and drop the Veg_DC.geom drawing into the map.
GPKG does a good job of storing and providing coordinate system information so the drawing has the correct coordinate system assigned and appears in the right place in a map along with known good layers such as Google. The drawing will be re-projected on the fly to match the Pseudo-Mercator projection used by the map. In the illustration above we have used Style to format the colors of the drawing's areas to provide a more interesting display.
Zoomed in, the drawing seems to show different vegetation types in Washington, DC, in the United States.
GPKG may be slower than a fast DBMS like PostgreSQL, but it is fast enough to enable native storage of spatial data when there are not too many objects. In Manifold we can take advantage of that by linking a GPKG file into our project. The link creates a data source cylinder that indicates the data is stored outside of the project, in the original GPKG file. When we expand the data source we can see the data within. This works well for smaller data sets until GPKG gets too slow.
Important: When linking a GPKG file the tables, images and drawings that appear in that data source in the Manifold project stay resident in the GPKG file. They are GPKG components even though they may appear in many respects, for the convenience of the user, to be Manifold components.
To link a GPKG format file:
Choose File-Link from the main menu.
In the Link dialog browse to the folder containing data of interest.
Click the .gpkg file desired.
Check or uncheck the Save cache box as desired.
Press Link. A linked data source will appear in the project.
Press the + icon next to the data source to expand the data source to see the tables, images and drawings it contains.
The Save cache button allows setting cache options.
Most often when linking to a format like GPKG, we will ensure the Save cached box is not checked. Working with the GPKG will be faster if we check the box, but if we are going to cache data within the project we may as well simply import the GPKG and use full Manifold speed. We uncheck the box and then we press Link.
That creates a data source that contains all of the tables and other contents of the .gpkg file's database. We can double-click on the Veg_DC.geom drawing to open it.
The drawing opens in default format. To color it with more appealing fill colors for the areas, we launch Style.
We use the fid field to automatically color fill color for the areas using the settings above. We have pressed the Full Range button to calculate the full range of values before pressing the Tally button to generate 16 breaks for applying the palette chosen, the Color Brewer CB Spectral palette. Press Apply.
That colors areas in the drawing using the fid field. This has zero logical utility: it is just a means of coloring the drawing in a distinctive manner so later on we can see that the styling we have applied is indeed saved within the GPKG file.
For a more interesting display, we first create a new data source using a Bing street maps imageserver as shown in the Example: An Imageserver Tutorial topic. We then create a map and drag and drop the Bing layer into the map, and then we drag and drop the drawing from the data source into the map. The drawing will be re-projected on the fly to match the Pseudo-Mercator coordinate system used by the map.
To continue on with this workflow to save the new styling, see the Example: Link GPKG and Save Style topic.
GPKG is not a simple file format like .csv or .shp, but instead is a small DBMS system packaged within a file. GPKG is implemented as an SQLite database extended with SpatiaLite capabilities, so it requires installation of SQLite software together with SpatiaLite software on any computer on which a GPKG file will be used. If we do not have SQLite and SpatiaLite installed on our computer we cannot use GPKG.
There are two ways to get the SQLite and SpatiaLite software required to work with GPKG. The official way is to visit the official websites for SQLite and SpatiaLite and download what the creators of those products provide and to create the various .dlls as desired. As a practical matter that path is realistic only for experts, and even for experts that path has many opportunities for errors: for example, some people create .dlls without spatial index support, which means the package will not be useful for a full-functioned GPKG.
The practical way is to visit the Manifold downloads page and to download the pre-packaged zip files Manifold provides to make the process easier. These include all files for SQLite, SpatiaLite and GPKG. That process is much easier for people who are not programmers or expert users of open source.
The official sources for SQLite and SpatiaLite:
To install SQLite and SpatiaLite on our computer, we visit the above web pages and then we find and download an appropriate set of pre-compiled binaries or, using our C programming skills, we create our own binaries. We install the right combination of binaries in the right places and, like magic, everything works perfectly. This is straightforward for experts.
For users who prefer an easier process, Manifold has assembled an informal collection of binaries for popular open source DBMS packages into two collections of files, one for 64-bit operation and one for 32-bit operation. The collections include binaries required for clients connecting to MySQL and PostgreSQL / PostGIS, as well as binaries for SQLite and SpatiaLite required to work with GPKG files and other SQLite / SpatiaLite databases.
Visit the Downloads Page on the Manifold web site and download the two extension-dlls zip files, one ending in x64 and the other ending in x86, from the section titled DLLs For Popular Open Source DBMS Packages. Unzip the x64 zip file into the bin64 folder of your Manifold installation. Unzip the x86 zip file into the bin folder of your Manifold installation. Done.
The Manifold collections of binaries may be unofficial files that are provided with no support and no guarantees, but they are provided in good faith by Manifold programmers in a configuration that works well with Manifold.
We are working with Manifold on a 64-bit Windows 10 system. We have unzipped the extension-dlls-x64.zip file into the bin64 folder of our Manifold installation. That creates a folder called extension-dlls-x64 as seen below in File Explorer.
That is all we need to do. Manifold will automatically utilize any .dll files that are located within the bin64 hierarchy. If we are curious what .dll files have been installed, we can explore the extension-dlls-x64 folder.
It contains three folders, one each for MySQL, PostgreSQL / PostGIS and SQLite / SpatiaLite.
Within the sqlite-spatialite-x64 folder we see the .dll files that comprise the SQLite and SpatiaLite software ensemble. If we get SQLite and SpatiaLite through other means, such as by direct downloads from the official sites, these are the .dll files we must have within our PATH for 64-bit execution.
Why doesn't Manifold install required DLLs as part of Manifold installation? Adding the required .dlls would increase the size of the Manifold and Viewer installation packages by over 15 MB, a big jump considering the installation of Viewer is only 47 MB. A better way would be to automatically download on demand the required .dll package for those who want to use GPKG, a feature likely to appear in future builds of Manifold.
Do I need all of the DLLs to work with GPKG? Strictly speaking, we can read/write existing GPKG files, but not create them, with only the sqlite3.dll installed. Manifold's GPKG dataport provides its own versions of spatial functions required to enable writes to spatial indexes when SpatiaLite or similar extensions that normally provide these functions cannot be loaded. As a practical matter, it is wise to simply install all of the DLLs.
Example: Modify GPKG Geometry with SQL then Add Drawing- This topic provides a "Hello, World" example that shows a simple, but typical, task involving spatial data. We will take a country-sized data set in GeoPackage (GPKG) format and change all areas in the data to the boundary lines for those areas and then save those boundary lines as a new table. We add a spatial index to the table and create a new drawing to visualize the new table.
Example: Link GPKG and Save Style - A companion topic to the GPKG topic. How to link a GPKG, open a drawing, Style it and then save so the styling is retained within the GPKG file.