Let's Make a GeoPackage Extensions Registry

One of the best ideas I have heard recently is that there needs to be a registry for proprietary GeoPackage extensions. While OGC has a number of registered extensions as part of the encoding standard, is it only natural that there are going to be proprietary ones out there. What we don't have today is a way for developers to see what exists as prior art. We then run the risk of developers reinventing the wheel and the longer this persists, the harder it is to deal with. The last thing we want is multiple competing extensions out there and no interoperability between them.

I believe an extensions registry will address this problem effectively. I will do the legwork for creating it. In the short term it is going to be pretty simple - just a web page off of geopackage.org with a bunch of hyperlinks. I will use the Leaflet Plugins page as inspiration; hopefully one day we will end up more like QGIS Plugins but it won't happen overnight.
Update: this is now live at http://www.geopackage.org/extensions.html.

To be added to the registry, I will need from the developer a completed Extension Template [1]. This template includes all of the information developers will need to understand what the extension does and how it works. I will post the template to geopackage.org (or more likely, link to it) and help publicize it. If the extension suits other people's needs then great! If a number of implementers start using a particular extension, let the GeoPackage SWG know and we will discuss whether it is ready to be adopted by OGC.

[1] The raw AsciiDoc of the template is on GitHub. If filling out a template is going to be a major problem, let me know and I'll see what can be done to help you out.

The Styling / Portrayal Ad Hoc Meeting

On Thursday June 29, I facilitated a Styling / Portrayal Ad Hoc at the OGC Technical Committee Meeting. This ad hoc meeting was called because there is broad agreement that GeoPackage would benefit from standardized feature styling and portrayal capabilities. (Anecdotal evidence suggests that the lack of common/standardized solutions here is already inhibiting GeoPackage adoption.) However, there is also agreement in OGC circles that whatever capabilities used by GeoPackage should apply across all of OGC Simple Features. The meeting was attended by over 40 people (combined in-person and on-line[1]).

Much of the meeting centered around Styled Layer Descriptor (SLD) and Symbology Encoding (SE), two OGC encoding standards[2]. The consensus was that while these are annoying (XML!) formats to work with and that they have a number of issues, they are not that far off for meeting most needs. (The geospatial community has created a number of specifications over the years but none of the alternatives have been standardized and many of them have been abandoned.) The attendees tentatively agreed that attempting to move SLD/SE forward was the best available option for supporting the desired capabilities in a timely manner.

The attendees agreed on the following action items:

•  Rechartering the SLD/SE Standards Working Group (SWG) with the goal of producing updated standards that feature a core and extensions model and/or multiple conformance levels so that there is some separation between essential and non-essential elements

•  Finding someone to create an executable test suite, developer’s guide, and other materials to lower the bar for developer use

•  Initiating a pilot to experiment with the SLD/SE changes

My own next step is to take these findings back to OGC’s Architecture Board and try to turn them into action.

[1] Don't get me started on the pathetic state of hybrid in-person / on-line meetings in 2017.

[2] There was also discussion of portrayal registries, but that is a topic for another day.