is there a convention to store (ows_)context in geopackage?

[pvgenuchten]

In the process of designing geopackage, did you consider to store context info into the package (in case the geopackage data would be loaded on a map, which order, opacity, default style should the layers use).

Are there conventions to store for example an ows_context file in the package which would contain this configuration?

Or can the order in gpkg_contents be used to add layers to a map?

[pepijnve]

During OWS-10 some analysis work was done regarding OWS context and GeoPackage. We looked at using an OWS context file as a input for a GeoPackage creation service where the service would bundle up all the data sets that are referenced in the context file into a GeoPackage. One idea we that we experimented with was transforming the original OWS context file and embedding it into the GeoPackage. The context file would then contain a reference to both the original source (e.g. a WFS service, KML file, ...) and the corresponding content inside the GeoPackage itself. My own proposal for the geopackage content references was to do this by defining a geopackage MIME type and an associated URI fragment identifier scheme that would allow you to refer to content inside a geopackage file (e.g., http://foobar.com/dataset.gpkg#table=somefeaturetable). The other main proposal was, IIRC, to extend the OWS context XML schema with geopackage specific extensions to achieve the same goal. I argued for the fragment identifier scheme since I felt it was much more generally applicable and valuable than something OWS context specific. You could use this, for instance, to ask an application like QGIS for instance to open a specific table in a geopackage rather than loading everything. We never reached consensus on that last part though. Not sure if any followup work was done after that.

[jyutzler]

There is an identified need for both context files inside a GeoPackage (manifest) and outside (pointer to contents of multiple files). However, as @pepijnve notes we have not come to a consensus on any of it.

[pvgenuchten]

Thank you @pepijnve, that is very helpfull,

My use case is that i want to make an export from a qgis/arcgis mapview to geopackage, load that geopackage on for example a phone and visualise the same content.

In that case i need to export the context. metadata, the SLD's and the data to a single geopackage. Was just wondering if there are any conventions for such a case.

I also see this as a way to transport full projects between arcgis/qgis etc

[jyutzler]

Of those four things, all we have standardized is the data and the metadata. There is a testbed initiative looking at styling but it is not yet standardized.

[pvgenuchten]

Based on discussion with @pka this morning, we decided to set up a draft specification for an ows-context extension for geopackage, based on his work for a qgis-extension for geopackage. Welcoming your thoughts, and hope you consider it as input for the OWS-testbeds work.

[jyutzler]

We are trying to re-awaken this effort. Stay tuned!

[pka]

And we will update the QGIS plugin for our FOSS4G talk "Sharing and Migrating GIS Projects with OGC GeoPackage"!

[mhogeweg]

why not just have a simple table contexts in the geopackage with fields like so:

• id - some identifier
• title - a title for the context
• encoding - JSON|ATOM|... (select the encoding applicable to the context content. this could be a more formal media type of OGC registers those for the context document)
• content - the actual context JSON/ATOM/... as a string field

if you then resolve the referencing of layers in a geopackage you have a pretty self-contained thing that defines a map and has the data.

[jyutzler]

@mhogeweg That is one possibility but if we are going to do that, we might be able to simply use the existing Metadata extension.

There are multiple issues here.

1. How to encode GPKG contents as OWS Context offerings
2. How to point to a GPKG from an OWS Context document that lives outside that GPKG
3. Where to put the OWS context document if it is inside the GPKG

None of these is resolved.

[mhogeweg]

hmmm.. if I understand that extension properly, it is for hierarchical metadata a la ISO 19115.

ah, I see this:

The first component of GeoPackage metadata is the gpkg_metadata table that MAY 
contain metadata in MIME [21] encodings structured in accordance with any authoritative
 metadata specification, such as ISO 19115 [28], ISO 19115-2 [B6], ISO 19139 [B7], 
Dublin Core [B8], CSDGM [B10], DDMS [B12], NMF/NMIS [B13], etc. The GeoPackage 
interpretation of what constitutes "metadata" is a broad one that includes UML models [B14] 
encoded in XMI [B15], GML Application Schemas [30], ISO 19110 feature catalogues [B18], 
OWL [B20] and SKOS [B21] taxonomies, etc.

This opens a pretty broad range of things to be stored in gpkg_metadata.metadata (assuming we consider the context JSON/ATOM 'metadata'... ceci n'est pas une carte?). This could be an approach for item 3.

For item 1, encoding GPKG content as an OWS Context offering could use the OWS:Content element of OWS Context. This element includes a type, href, title, content elements. Type is the media type of the content (OGC would need to define these for GPKG content if not already done). href could be a local (inside GPKG) reference to the feature/tiles tables or a reference to one of the already supported external services. this would resolve item 2 I think. I would leave the case for referencing from one geopackage to another for a later refinement.

[jyutzler]

I think what you say about items 1-3 is right in principle but the devil is in the details.

We could be proven wrong, but at this time we believe referencing from one geopackage to another is an antipattern.

[mhogeweg]

Do you have an example with just (ISO/FGDC) metadata in a geopackage? I was considering UC demos and one could be to hook up the geoportal server metadata editor to a geopackage metadata entry.

[jyutzler]

The OWS Context SWG has proposed a mechanism where a GeoPackage offering is encoded with an SQL query that performs a prototype request for that data. More details here. (OWS SWG subscribers only)

[pepijnve]

@jyutzler I can't see the details so sorry if this is a bit off the mark. Embedding code (SQL statement) seems like a disaster waiting to happen. What happens when someone embeds a DELETE FROM ... or DROP TABLE ... and applications naively execute that without checking?

[jyutzler]

@pepijnve noted.

Readers of this thread, also note that there is a competing approach that was produced outside OGC. See https://github.com/GeoCat/qgpkg/blob/ows-spec/owc_geopackage_extension.md and https://t.co/BzoY7pQwc7

[pepijnve]

@jyutzler is there anything you can publish publicly from the SWG wiki or mailing list so people can compare?

[pka]

Hi Jeff, there is no contact information at http://www.geopackage.org/extensions.html. So I ask you here to add the mentioned QGIS styling extension https://github.com/pka/qgpkg/blob/master/qgis_geopackage_extension.md and to change the URL of the ows extension to https://github.com/pka/qgpkg/blob/master/owc_geopackage_extension.md, since the code has been merged in the meantime. We've referenced the extension page in our FOSS4G talk today as "Third-party extension registry".

[jyutzler]

When OGC 18-037 is published by OGC (it has been approved for release already), I will close this issue. The community extensions are out there (provided as-is, of course). If there is movement to move either work to a standard extension, I will open a new ticket.

[jyutzler]

http://docs.opengeospatial.org/dp/18-037r1/18-037r1.html Also, this is being looked at as part of the OGC Vector Tiles Pilot.