OGC Testbed-15: Encoding and Metadata Conceptual Model for Styles Engineering Report

All questions regarding this document should be directed to the editor or the contributors:

Contacts

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.

The conceptual model covering style metadata and multiple encodings is summarized in the following Unified Markup Language (UML) class diagram.

The model can be succinctly divided in three main components:

Note that the organization of the model into these three components, makes it complementary with the Symbology Core draft specification (18-067r2). This organization minimizes overlap and duplication between the two models in order to facilitate future convergence between them.

A Style is a sequence of rules for symbolizing instructions that are to be applied by a rendering engine to one or more features and/or coverages.

On a layer by layer basis the WMS and WMTS standards list available style names in their capabilities document. This allows clients to identify the desired style using the STYLES parameter in a GetMap request. However, the WMS and WMTS standards do not offer support for a client to provide their own styles. The SLD standard addressed this limitation in two ways:

Implementations including the SLD extensions for WMS also allow extracting the style encoded as SLD, and modifying the style (GetStyle and PutStyle SLD extension for the WMS protocol).

Moreover, the association between layers and styles is modelled as a one-to-many containment, from the layer to the style.

Traditionally, web maps were often built by stacking multiple layers and choosing the desired style for each (layers and styles WMS parameters). However, it was also possible to provide full basemaps either by using the WMS capabilities tree structure (a layer containing other layers) or by simply leveraging the services "opaque" nature to hide a group of layers with a coordinated symbology under a single layer name.

In the new emerging OGC API specifications currently being developed there is a desire to also support explicit knowledge of the associations between styles and data sources (collections). This is true whether the layers are vector or raster data, while also retaining the ability to keep on rendering fully opaque layers that the server can build using whatever approach is deemed most appropriate. This is in particular useful to support client side rendering, as well as client side style editing.

This scenario involves bidirectional associations between a style and collections:

The relationship of the OGC API - Features standard to style usage is straightforward because a collection can be rendered client-side using styles that the API might provide, or a client might be looking for a suitable style for the layer on a shared style catalog. With the exception of simple styles, for rendering to succeed attributes used by the style need to be present. Thus, knowing their name, expected data type, and semantics is important.

The relationship of the OGC API - Coverages draft specification to styles is similar to the Features one, with two exceptions:

The relationship of the OGC API - Tiles draft specification to styles is more interesting, as it can involve both client and server-side rendering:

At the time of writing there is no tile encoding standard supporting the transfer of both vector and raster information. However, that would not change the conceptual model. The style linked from the collection could simply contain symbolization directives for both data types.

An implementation of the OGC API - Maps draft specification would behave the same as an implementation of the Tiles API in a server side rendering scenario, and would allow a style editor to eventually modify the style used for rendering.

The Style metadata associated components represents most of the UML diagram real estate. The information represented in the model is actually designed to be simple and compact and most of the content is there to provide the possible values of a few enumerations.

At the core of the style metadata the following information is enumerated:

The style metadata is then associated with a thumbnail, a link to a visual representation of a map rendered with the style (not to be confused with a legend) and suitable for presenting a carousel of styles in a client. An example taken from the OpenMapTiles web site follows:

A style can be associated with multiple dates, in particular:

Finally, the style metadata provides indications of the layers involved in the symbolization (which might be just one), and the attributes used by the style for each layer (could be none). While part of this information could be retrieved from the stylesheets themselves, this is a succinct representation enumerating the minimum set of data the style needs in order to actually symbolize data.

In particular, for each layer the following information is provided:

When present, each attribute holds the following information:

The attribute ids can be derived via a simple automatic scan of the style contents. The type can be loosely inferred by the rendering machinery needs and context of where the attribute is used (e.g. an attribute used directly as a rotation needs to be a number). However, both a more precise type and a description also have to do with the semantics of what the style is depicting, thus, manual intervention will be needed to fill those fields with accuracy.

Each style can be considered as an abstract set of instructions to render a particular map, or a portion of the map. The instructions can then be delivered in a particular encoding. In Testbed 15 SLD 1.0, SLD 1.1, Mapbox Styles were used along with other system specific language implementations like GeoServer GeoCSS and GNOSIS CMSS.

Each style language features different characteristics, styling abilities, and different intended target audience, for example:

Some servers have developed the ability to automatically convert between formats. However, the different nature and possibilities of the languages often make for a lossy conversion, and it is sometimes possible to create a better matching output by hand editing the style instead.

Finally, styling languages are not static, but evolve over time, thus it might be necessary to indicate the version of the style language used in the encoding.

Given these considerations, a style metadata can link to one or more stylesheets, that is, encoding of a style, with the following attributes:

A "Styleable layer set" is a group of layers that are typically styled together, as a group, typically to form a basemap.

Common examples of these sets are OpenStreetMap, or Natural Earth.

These data sets can be styled in different ways. For example in Testbed 15 the various actors worked with a base map style, a night variant that map, and a "raster backdrop" version of the same basemap. The different conditions of light (day vs night) and the differences in background color call for a different rendering of the overlayed elements (roads, buildings, points of interest).

The metadata model currently identifies a styleable layer set by the "styleableLayerSet" string attribute in the style metadata. Two styles sharing the same value for said attributes are meant to be alternatives of each other, based on same set of layers. The night and day cases use the exact same set of layers.

The overlay one adds a digital elevation model image as a backdrop.

Examples of the same concept can be found online. For example, both OpenMapTiles and MapBox render their respective sets of layers with different styles depending on the necessities of the customer. Below are some visual examples:

Please note that the same set of layers and the same style name can come with significantly different representations from different vendors, and while being based on similar data sets, the amount of information in each can vary significantly (and quite likely, the actual sets of layers and attributes available in each changes with vendor implementations).

Here are examples from the same area in Chicago, rendered using an "OpenStreetMap" data set, using a style called "OSM Bright", from three different mapping websites (one which is OpenStreetMap proper):

With this in mind, it is best to consider the styleable layer set as an indication provided by a single Styles API to label variants of the same style, on the same dataset, to be used under different conditions.

A more general and interoperable notion of a styleable layer could be built by advertising the set of layers and available attributes. This information could use the same structure as the style metadata, but with an important semantic difference. While the style metadata reports the layers and attributes the style needs to operate on, a styleable layer set would instead report all the attributes available to eventual styles for rendering purposes.

Such an explicit description would allow for sharing styles across servers and catalogs providing the same styleable layer set.

The following style uses a custom function called dimensions to symbolize all types of geometry found, making this a good example of a style using the generic type Vector in the style layer metadata. GeoServer uses this style by default when the geometry type is unknown due to lack of information, or when the geometry is actually generic and different features can contain different geometric types.