OGC Testbed-15: Portrayal Summary ER

A Style is a sequence of symbolizing and rendering instructions that are to be applied by a rendering engine to one or more features and/or coverages. Styles in the OGC standards baseline have traditionally played two different roles:

These two approaches worked well in the past. More recently evolution for Web based mapping systems now requires more robust support for styling. In particular:

In order to meet these requirements, two fundamental components had to be developed.

The conceptual style model is expressed in UML and builds around the central element Style. A Style has StyleMetadata to describe typical metadata aspects such as title, keywords, abstract, point of contact, version, or access constraints. Style metadata links to a thumbnail to allow quick style assessment. A Style can include any number of layers, and each layer is defined by a set of required attributes that the data needs to provide for proper styling. A Stylesheet describes the actual style encodings available.

The organization of the style model makes it complementary with the draft OGC Symbology Core standard (18-067r2). Overlap and duplication between the two models have been minimized to facilitate future convergence.

The Styles API is a Web API that enables map servers and clients as well as visual style editors to manage and fetch styles. This API is fully documented in OGC Testbed-15: Styles API Engineering Report (OGC 19-010). The Styles API is consistent with the emerging OGC API family of standards. The Styles API implements the conceptual model for style encodings and style metadata as documented in the OGC Testbed-15: Concept Model for Style Encoding & Metadata Model Engineering Report (OGC 19-023).

Both the conceptual model and the Style API work well in conjunction with OGC API - Features and the emerging specifications OGC API - Coverages, -Tiles, and -Maps. With features, a collection can be rendered client-side using styles that the API might provide by reference, or a client might be looking for a suitable style for the layer on a shared style catalog. The OGC API - Coverages relation to style is similar to the Features API. The difference is that coverage rendering can involve a number of operations on the raster bands, including band selection, contrast stretching, color map application and hill shading. Client-side rendering of raw raster data, while possible, has not yet reached the same widespread support as the vector case. Using the emerging specification OGC API - Tiles, styles can be used to support server-side or client-side rendering. In the case of server side rendering, a tile can identify the applied style, which allows future modifications to that style if available at a Web endpoint with Styles API support. In the case of client-side rendering, the client can consume the style to retrieve rendering instructions. In conjunction with the emerging OGC API - Maps, the behavior is similar to the API Tiles with server-side rendering applied.

Interestingly enough, the conceptual styles model already supports tile containers that include both vector and raster data, though these containers are not supported by available tile encodings.

Styles can be managed and modified by users through the OGC API - Styles. The Styles API is a Web API that enables map servers and clients as well as visual style editors to manage and fetch styles. Visual style editors that create, update and delete styles for datasets that are shared by other Web APIs implementing the OGC API - Features - Part 1: Core standard or the draft OGC API - Coverages or draft OGC API - Tiles specifications.

Testbed-15 did some experiments with converting styles from one encoding to another. In summary, it can be stated that style encodings do not allow seamless conversion from one model to another.

One of the key requirements for the OPF activity was to reduce the transmission traffic caused by updates to tile stores. A tile store containing a pyramid of tiles with twenty zoom levels may include billions of tiles. Updating entire tile stores or tile caches would cause enormous traffic if all tiles are replaced, just because a small subset of the source data is to be updated. OPF participants therefore looked into the option to update only the subset of tiles where changes occurred, i.e. changesets.

Testbed-15 experimented with this situation assuming a tight connection between an image archive and the tile store. The use case implemented in Testbed 15 added a new satellite scene to the image archive, which then triggered updates to the connected tile store. The draft OGC Changesets API specification enables clients to retrieve only the tiles that have been affected by the new imagery. For sure, the number of affected tiles eventually depends on a number of aspects, such as the tiling strategy, or additional processing steps such as for feature extraction, interpolation, or generalization.

To achieve this functionality, the draft Changesets API is designed to operate with checkpoints. The Changesets API works with any data resource that supports a mechanism to request for server-side changes in a resource collection since a previous checkpoint.

In order to implement this capability, the service needs to keep an audit of every change in the resource(s) and assign a checkpoint identifier to each change. At some point in time, a client will request a resource collection and receive that collection with a checkpoint identifier. After a while, the client may send a request for updates and notify the server about the original checkpoint. The server will then inform the client about the changes in the resources up to a current checkpoint and the client can then update its copy of the resources.

In addition, the Changesets API supports further filtering on top of checkpoints. For example, this additional filtering allows the client or service to retrieve only updates that are flagged as important. This functionality was not tested extensively in Testbed-15.

The offline use case complements the other components of the Open Portrayal Framework. A key goal of the OPF thread is to enable a seamless online/offline experience. That is, a user with full connectivity receives data and styling information from Web endpoints. The user then loses connectivity and switches transparently to a local copy of the data with corresponding styling information. Once connectivity is re-established, the user reconnects to Web endpoints while the offline data on the device gets updated in the background to be prepared for future offline situations again.

The OPF activity used the GeoPackage standard as the container solution for data, styles, and corresponding elements such as symbols or fonts. Please note that fonts were not addressed in Testbed-15, but are a potential subject for future GeoPackage research. The GeoPackage standard supports a flexible extension mechanism that worked well for the additional style data. However, the associations between data, styles, and symbols led to the development of a new construct called "Semantic Annotation". The Semantic Annotation concept allows for any type of associations to be added to a GeoPackage without changing the underlying table structure of existing tables. While adding some overhead, the advantages of the new solution quickly outperformed the added complexity.