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.