More on SLD and SE

Styled Layer Descriptor (SLD) and Symbology Encoding (SE) are two related OGC standards. They have been around for over a decade but I think we can safely say that they have not definitively met their primary purpose - to enable the portrayal of feature data in an interoperable way. The most common complaint with these standards boils down to one thing - a high barrier to entry. This manifests itself in a few ways:

1. SLD and SE are XML encodings. While many server-side developers are comfortable dealing with XML, this only represents a small fraction of the market these days. Most developers want nothing to do with XML if they can help it. JSON is a more natural choice for web applications, mobile applications, and many server-side frameworks. CSS is comfortable for many front-end developers. SQL developers (think GeoPackage) want to be working with SQL predominantly. A way past this issue would be to produce a conceptual model that could then be implemented in formats more appropriate for the target environment. The conceptual model could then be implemented a fairly small number of times and then abstracted for the various encodings.
2. SLD and SE are fairly complicated. The documents are long and intimidating and compliance is an all-or-nothing affair. It would be helpful to have something akin to "Simple Features" for SLD and SE - a core that only covers the most important and common options. Like most things in software development, the Pareto Principle applies.
3. Tools are lacking. There is currently no public executable test suite for the two standards. While GeoServer's SLD and SE support are pretty robust, alternatives are pretty hit-or-miss. If we want people to use these standards, we need the tools that make them easy to use.

On the flip side, SLD and SE also suffer from a lack of extensibility. There are use cases that cannot be handled by SLD and SE out of the box[1] and without an extension mechanism, there is no clear way for a developer to introduce interoperable solutions. This means that complex portrayals (think MIL-STD-2525) are a non-starter.

When a solution is not ideal for either the low end (lots of potential users) or the high end (lots of potential funding), all that is left is the skinny middle and it isn't enough. This is solvable if we have the will. That phrase is key - if we have the will[2]. The solution is not going to fall from the sky. It is going to take effort and leadership from a number of organizations over the course of more than a year. OGC appears to be willing to take the lead here but the effort requires community support to be successful. There will be opportunities to participate and I hope that you will find a way to do so. 

[1] The "TENET report" enumerates several limitations of the OGC SE, including hierarchical symbols, multiple delineations, and pivot points.

 

[2] Total tangent here. I first drafted this post on 9/13/17 and happened to include this phrase which comes from a Grant Hart song of the same name. That very night he passed away (unexpectedly, at least to me). RIP Grant.

Improving geopackage.org

Part of my job as GeoPackage SWG Chair is to improve outreach. This includes disseminating information (like this blog post) but it also means making information easier to discover. I feel good about the state of the specification / encoding standard but our outreach leaves room for improvement. One potential area of improvement is our website, geopackage.org. It is okay but it could be much better.

Over the next few months, I intend to revamp this site to make it more useful for its target audiences. When a visitor reaches the site, it should be self-evident where to go for relevant information. We're not there today. In response, I plan to reorganize the content to align it by reader type: general, developer, administrator, data publisher, data consumer, and SWG participant.

For this to work, I need more input from the user community. For example, a geopackage.org reader may wish to learn not only what GPKG implementations are out there but what they are useful for. Therefor I will be reaching out to vendors to clarify the role of the software that is currently listed under http://www.geopackage.org/implementations.html. I am also going to solicit user guides and demonstrations that can be incorporated into the site. This content can describe FOSS or proprietary software; my goal is to inform and to present options to the community.

If you can help me out here, I want to know about it.

A Busy Time at GeoPackage

Things have been busy on the GeoPackage front. I sense an uptick in both interest and adoption of GeoPackage. FOSS4G was the most public example but there have been others. With this in mind, I would like to share three recent developments. It is a busy time at GeoPackage!

1. GeoPackage 1.2 has been formally adopted by OGC. The OGC standards page has the "official" PDF version of the document (edit: and now the release notes) and the HTML version is what is currently at geopackage.org/spec. Thanks go to the large number of people who made this release possible.

2. OGC has released "OGC GeoPackage Extension for Tiled Gridded Coverage Data" for public comment. This extension is a reworking of the elevation extension. The primary change was expanding the scope of the extension from just elevation data to any regular gridded coverage data. The normative changes from the original extension are minimal - just a few additional columns that allow us to define what content is held in the tiles. We expect that implementers will find it easy to transition from the elevation extension to this one.
 
3. OGC has issued a call for participants for the "GeoPackage Related Tables Extension Interoperability Experiment". Yes, that is a mouthful. The idea is that our friends at Compusult have produced an extension for associating tables with existing feature or attribute tables in a GeoPackage. Among other things, it can be used to establish a many-to-many relationship between features and multimedia files. We are looking for willing participants (OGC membership optional) to help us determine if the extension accomplishes what it is designed to do. If you are interested, please accept the Observer Agreement and plan to dial into the kickoff tentatively scheduled for September 25.