Example: Link GPKG and Save Style

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:


  1. Choose File-Link from the main menu.

  2. In the Link dialog browse to the folder containing data of interest.

  3. Click the .gpkg file desired.

  4. Click the Options button.

  5. In the Options button choose the cache options desired, for example unchecking the Save cached data... option to keep file size small.

  6. Press Open.  A linked data source will appear in the project.

  7. Press the + icon next to the data source to expand the data source to see the tables, images and drawings it contains.




The  Options dialog allows setting cache options.




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.




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 the drawing 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 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.


Saving and then Importing

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.


See Also



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.