Wednesday, June 12, 2019

Introducing Application Profiles

Bottom Line Up Front: we want GeoPackage to be interoperable, but we are not there yet. It is not easy to achieve interoperability in an ecosystem that is extensible by design. Organizations that want to be use GeoPackages from disparate sources are not having great success. We have learned important lessons from the interoperability experiments that have been conducted:
  • GeoPackage has many degrees of freedom, including but not limited to extensions (e.g., SRSs, geometry types, tile matrix sets, tile formats, etc.)
  • conformance to the standard is no guarantee of interoperability
  • there is currently no clear way to determine whether a client will be able to fully use the information available in a particular GeoPackage
I propose to solve this problem by introducing application profiles to GeoPackage. An application profile would itemize all of the optional elements in use in the database. In terms of roadmap or capability evolution, I propose a set of three incremental capability levels.
  1. Verbal/written agreement
  2. Machine-readable manifests that declare what options are in use in the GeoPackage so that a GeoPackage Client can determine whether it can be fully used
  3. Allowing consumers to provide a "bill of materials" with a GeoPackage production request so that the ensuing GeoPackage only uses white-listed options
While Capability Level 1 would be better than nothing, I do want to propose a specific approach for the machine-readable document. Last week I introduced the concept of metadata profiles. Now I propose a new metadata profile (metadata scope: "manifest", reference scope: "geopackage") for a JSON document that captures this information. The working version of the JSON Schema for that document is on GitLab along with a sample manifest document.

Tuesday, June 4, 2019

It's Time We Had A Little Talk...About Metadata

I know this is going to make people uncomfortable, but it is time to talk about this. People want to put metadata in GeoPackage. It is just a fact of life. We need to be ready and that is why we are having this discussion. 

While GeoPackage has had support for metadata since its inception, I acknowledge that there is something missing. There is currently no agreement on how metadata should be used in GeoPackage to serve any particular purpose. Someone opening a GeoPackage would have no way of recognizing that the file has any particular type of metadata in it, short of inspecting every single row in the gpkg_metadata table. No way.

I propose that we address this gap by introducing "metadata profiles" to GeoPackage. A metadata profile is an agreement on what a metadata document will look like and how it will be used in the GeoPackage. I propose to leverage the extension mechanism to express this information. This approach has two parts:

  1. Introduce a new extension that defines a new extension "scope" (i.e., the gpkg_extensions.scope column) of "metadata"
  2. Create an extension for each metadata profile:
    • using this new "metadata" extension scope
    • defining the metadata scope, standard/specification, and MIME type that uniquely identify it
    • defining the reference scope ("geopackage", "table", "row", or "row/col") that it will be used for 
As part of OGC's Testbed-15, I intend to explore this concept further. Here are some profiles that we are considering:
I will explore these further in subsequent blog posts.