Before continuing with this example, please read the GPKG topic.
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.
GPKG has the ability to retain Style information from Manifold. We can link to a GPKG database file, style a drawing within that database file, and the GPKG file will retain that styling information. This topic provides an example based on the example GPKG files used in the GPKG topic.
We begin by linking a GPKG file into our project.
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.
Choose the cache option desired, for example unchecking the Save cache box to keep file size small.
Press Open. 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 box allows save or not save cache.
Most often when linking to a format like GPKG, we will ensure the Save cached data between sessions 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 click OK and then back in the Link dialog we click Open.
Most often when linking to a format like GPKG, which is fast for links, we will ensure the Save cache box is not checked. If we check the box then Manifold will build a cache within the project file that contains all the data we fetch from the GPKG. 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 therefore un-check the Save cache box and then we click Open.
That creates a data source that contains all of the tables and other contents of the .gpkg file's database. We can drag and drop the Veg_DC.geom drawing into a map we have created.
It is often convenient to work with data against a "known good" background, so we will open the Veg_DC.geom drawing as a layer in a map that uses Bing as a background layer. To do that, we first create a map using a Bing streets image server as a base layer, and then we drag and drop the Veg_DC.geom drawing into the map as a layer.
The drawing opens in default format. We can turn on the Bing layer to see if it is correctly georegistered.
From the view above, it is clear the Veg_DC.geom drawing was imported using the correct coordinate system, as it appears where it should be relative to a "known good" layer, Bing.
To color the drawing with more appealing fill colors for the areas, we click on the Veg_DC.geom layer in the map to ensure it has the focus, and then we launch Style pane.
We use the fid field to control area fill color using the settings above. We entered a method of equal count, a Fill of interpolate, and then we entered 16 into the Breaks box and pressed Tally. We have applied the Color Brewer Spectral palette. Press Update Style.
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.
We turn on the Bing layer for the full display of all layers in the map.
We save our project and then we delete the Sample_Gpkg_WashingtonDC_Vector data source.
That leaves our project with just a map with one layer, the Bing streets layer.
Next, using the procedure in the GPKG topic, we import the same GPKG file we linked earlier in this example.
The contents of the .gpkg database now appear as components in the project. This is exactly what would happen had we sent the .gpkg file to a colleague on a different continent and they imported it into their project.
If we drag and drop the Veg_DC.geom drawing into the map we see that the styling we created when the .gpkg file was linked into the project has been saved within the .gpkg file. The styling is now part of the .gpkg file, as least as far as Manifold applications are concerned.
We will now have a bit of fun: we will once again link the same file into the project.
That again creates a Sample_Gpkg_WashingtonDC_Vector data source in the project. We can expand the data source and drag and drop the drawing from within the linked data source into the map:
We now have the same data as two different drawings using the same styling in two layers in the map. One drawing was imported into the project and renders within the map at full Radian speed because it comes from Manifold storage in the project. The other drawing comes from the linked .gpkg file and renders within the map as fast as the GPKG / SQLite / SpatiaLite DBMS ensemble can provide it. With a drawing this small we will not notice the time it requires to render, but if it was a big drawing we would see that the linked version renders more slowly because GPKG technology is way slower than Manifold's Radian technology.
If we have sharp eye, we may notice another difference between the two drawings. In some regions like that marked above by a green rectangle, the linked version of the drawing appears to have fewer objects in it than the obviously more dense rendering of the drawing that was imported, as seen in the preceding view of the map. Why is that?
If we zoom into the region of the green rectangle we can double-click the layers off and on in turn and both appear to be absolutely identical. They should be, because both layers have identically the same objects in them. To understand what is going on, we take a look at the very smallest objects shown, such as the object marked by a magenta arrow in the illustration above. When the linked layer is on, we see it as a very small object.
When the imported layer is on and the linked layer is off, we see the imported layer shows that small object using a group of pixels. What is going on is that Manifold knows one layer comes from a linked source and is optimizing the approximation of very small objects that populated zoomed out views. That optimization has slightly different visual results depending on whether the data comes in from high-speed local storage or from relatively slower external storage.
If we have sharp eyes we may note another discrepancy, as indicated in the illustration above by the larger arrow. It shows a group of objects in the sample data layer that appear to be placed in the Anacostia River.
What we have discovered is that Bing is not perfectly accurate or averaged at all scales of zoom. If we drag and drop a Google Streets layer into the map we see that Google provides better detail. The objects are not in the water but in a park by the water.
We can drag and drop a Google satellite layer into the map to see what is there in real life.
Zooming far in we see that the objects occupied a small strip of land between the Anacostia Riverwalk Trail and the river.
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.