OGC RBT Follow-up 2

Last week, I wrote about the Releasable Basemap Tiles Sprint and how tiles were used as an enabling technology to efficiently deliver feature data in a GeoPackage. Here, I will focus on the other half of the problem, how to visualize the feature data once it has been delivered from the GeoPackage to the client. Proper portrayal requires both styles (how lines, polygons, and text are drawn) and symbols (reusable graphic elements to be used for points and fills). We have two basic challenges[1]:

1. Architecture – we want to retain flexibility. In some environments, the styles and symbols must be delivered with the data so that the system can operate in a Disconnected, Intermittent, or Limited (DIL) environment. In other cases, the styles and symbols will be provided separately by another system. A naming scheme must allow clients to use either architecture seamlessly.
2. Interoperability – there is no perfect standard for conveying styles or symbols. They all have strengths and weaknesses[2]. We want to support commonly used standards and specifications in a way that is discoverable by clients.

The RBT Engineering Report[3] includes a section that includes a draft styling specification. As with the tiled feature data approach, the approach here divides requirements into conformance classes. The engineering report presents three conformance classes.

1. The base class establishes the schemas for four new tables needed to describe the content.
2. A second class is for fonts, which need their own table.
3. An additional class is for Mapbox GL, the styling standard used in the code sprint.

There is a lot of power in the work we have done. Sprite sheets can be used to deliver multiple symbols in the same file. The URI mechanism will allow styles and symbols to be packaged with the GeoPackage or through another system. We do have some additional work to do before we are ready to adopt this work as a standard beyond the administrative work of standards-writing:

1. A conceptual model for styling and symbology metadata, something for our tables to map to that will encourage interoperability with other emerging standards such as OGC API – Styles.
2. Additional conformance classes for other styling formats, including SLD/SE, CartoSym CSS, and CartoSym JSON, or at least an interoperable way to express which formats are being used.

[1] See https://geopackage.blogspot.com/2018/06/where-we-are-with-feature-styling-and.html for further discussion on this topic.

[2] Obligatory XKCD reference.

[3] The draft is here but a final version will be added here upon publication.

OGC RBT Sprint Follow-up 1

OGC has recently completed the Releasable Basemap Tiles Sprint. From my perspective as the GeoPackage Standards Working Group Chair, the goals of this code sprint were the following:

• Demonstrate the viability and interoperability of raster and vector map tiles in a GeoPackage;
• Exercise and review the existing specifications and draft standards for tiled feature data and styling and symbology that have been under development since at least 2019; and
• Prepare draft standards for public review and hopefully OGC adoption.

The sprint looked at three emerging standards: tiled feature data, semantic annotations, and styling and symbology. We will focus on tiled feature data here. As described in my previous post, the goal is to store feature data in a more efficient manner by leveraging the existing tiles option. This approach builds on the one devised by Mapbox in their Vector Tiles, but without being tethered to it. Mapbox Vector Tiles is Mapbox's intellectual property and the OGC community has asked for an alternative that offers more flexibility.

The approach that is in progress now and should be released soon for public comment will have  a set of conformance classes in a single document. From a governance perspective, the conformance classes allow implementers to implement as much or as little as they see fit. From a GeoPackage perspective, the conformance classes will appear as rows to the gpkg_extensions table, to make them discoverable by clients. Following are the planned conformance classes:

1. Base, establishing the gpkgext_vt_layers and gpkgext_vt_fields tables that govern what layers and what fields are in what tile sets.
2. Mapbox Vector Tiles, indicating that individual tiles are encoded using Mapbox's protocol buffers-based encoding.
3. GeoJSON, indiating that individual tiles are encoded as a GeoJSON file.
4. WKB Collection, indicating that the individual tiles are encoded as collections of Well Known Binary BLOBs. This is a relatively new option that could obviate the need for the GeoJSON option.
5. Attributes, indicating that feature attribution will be stored separately from the tiles themselves, using the GeoPackage Attributes Option.
6. Features / Tiles Mapping, indicating that the GeoPackage Related Tables Extension will be used to track the many-to-many relationship between tiles and features, potentially improving efficiency and adding improved querying options.