New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
pvgenuchten opened this Issue Oct 28, 2016 · 19 comments

Comments

Projects
None yet
5 participants
@pvgenuchten
Copy link

pvgenuchten commented Oct 28, 2016

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

This comment has been minimized.

Copy link
Contributor

pepijnve commented Oct 28, 2016

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

This comment has been minimized.

Copy link
Contributor

jyutzler commented Oct 28, 2016

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

This comment has been minimized.

Copy link
Author

pvgenuchten commented Oct 28, 2016

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

This comment has been minimized.

Copy link
Contributor

jyutzler commented Oct 31, 2016

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

This comment has been minimized.

Copy link
Author

pvgenuchten commented Nov 11, 2016

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

This comment has been minimized.

Copy link
Contributor

jyutzler commented Jul 1, 2017

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

@pka

This comment has been minimized.

Copy link

pka commented Jul 1, 2017

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

@mhogeweg

This comment has been minimized.

Copy link

mhogeweg commented Jul 1, 2017

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

This comment has been minimized.

Copy link
Contributor

jyutzler commented Jul 1, 2017

@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

This comment has been minimized.

Copy link

mhogeweg commented Jul 1, 2017

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.

magrittepipe

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

This comment has been minimized.

Copy link
Contributor

jyutzler commented Jul 1, 2017

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

This comment has been minimized.

Copy link

mhogeweg commented Jul 1, 2017

@jyutzler

This comment has been minimized.

Copy link
Contributor

jyutzler commented Aug 2, 2017

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

This comment has been minimized.

Copy link
Contributor

pepijnve commented Aug 2, 2017

@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

This comment has been minimized.

Copy link
Contributor

jyutzler commented Aug 2, 2017

@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

This comment has been minimized.

Copy link
Contributor

pepijnve commented Aug 3, 2017

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

@pka

This comment has been minimized.

Copy link

pka commented Aug 17, 2017

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

This comment has been minimized.

Copy link
Contributor

jyutzler commented Jun 25, 2018

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

This comment has been minimized.

Copy link
Contributor

jyutzler commented Jan 28, 2019

@jyutzler jyutzler closed this Jan 28, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment