In a previous blog post, my colleague Paul van Genuchten, explained our vision and roadmap regarding extended geopackage support in the GIS ecosystem (desktop, server side and mobile phone). The OGC geopackage format was designed with the goal of being interoperable across a range of environments, in particular mobile devices operating in offline and near offline scenarios.
In this post, I would like to focus on a specific component of our toolchain, which is the client software, or geopackage “viewer”. Migrating a project from ESRI (or another) software to QGIS is a common challenge in the GIS world. With the OWS_Context Geopackage extension and the qgpkg plugin, we hope to address this challenge, at the same time that we promote the adoption of this standard by the overall GIS community.
As mentioned in the previous blog post, the client is a QGIS plugin, which started from a previous work from Pirmin Kalberer, the pka/qgpkg . The goal of the pka/gpkg plugin was to enable users to share their QGIS projects, including style and resources. The intermediate format to store information was the QGIS geopackage extension . This extension stores a QGIS project file in one of the extension tables, which works for the described use case, but does not allow interoperability with other GIS software. With this in mind, Paul van Genuchten designed another extension, the OWS Context geopackage extension, which is completely based on OGC standards. The idea is to store styling using OGC:SLD, and the project context using OGC:OWS_Context, so that other software can encode/decode this information.
Although it sounds like a solid approach, the implementation brought some issues into our attention. Although support to SLD exists in QGIS, it is far from being optimal, and there are things which are not currently supported. On the OWC_Context side, it is even more trickier as this is not natively supported on QGIS, so we created a mapping between the information which is present on the context table (e.g.: loaded layers, bounding box, project metadata) and the QGIS project. Unfortunately this mapping is far from being 1:1, which will make difficult to implement a round trip between an encoder/decoder in QGIS (something which was supported in the previous version of the plugin).
Difficulties aside, we have come to a working version of this plugin (published on github), which allows users to load data, styling and context information from a OWC Context geopackage. This includes geopackages encoded in ArcGIS (using GeoCat Bridge).
The next step is to merge this fork with the previous version, so that we can support multiple extended geopackage flavours (for different uses cases) in QGIS. We think this is a nice functionality which should eventually land in the core, and we will submit a proposal to the QGIS grant programme, for polishing it a bit and make it part of QIS. We hope to count with your feedback and your support!