Publication Date: 2020-02-06

Approval Date: 2019-11-22

Submission Date: 2019-10-31

Reference number of this document: OGC 19-018

Reference URL for this document: http://www.opengis.net/doc/PER/t15-D015

Category: OGC Public Engineering Report

Editor: Martin Klopfer

Title: OGC Testbed-15: Open Portrayal Framework Engineering Report


OGC Public Engineering Report

COPYRIGHT

Copyright © 2020 Open Geospatial Consortium. To obtain additional rights of use, visit http://www.opengeospatial.org/

WARNING

This document is not an OGC Standard. This document is an OGC Public Engineering Report created as a deliverable in an OGC Interoperability Initiative and is not an official position of the OGC membership. It is distributed for review and comment. It is subject to change without notice and may not be referred to as an OGC Standard. Further, any OGC Public Engineering Report should not be referenced as required or mandatory technology in procurements. However, the discussions in this document could very well lead to the definition of an OGC Standard.

LICENSE AGREEMENT

Permission is hereby granted by the Open Geospatial Consortium, ("Licensor"), free of charge and subject to the terms set forth below, to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property without restriction (except as set forth below), including without limitation the rights to implement, use, copy, modify, merge, publish, distribute, and/or sublicense copies of the Intellectual Property, and to permit persons to whom the Intellectual Property is furnished to do so, provided that all copyright notices on the intellectual property are retained intact and that each person to whom the Intellectual Property is furnished agrees to the terms of this Agreement.

If you modify the Intellectual Property, all copies of the modified Intellectual Property must include, in addition to the above copyright notice, a notice that the Intellectual Property includes modifications that have not been approved or adopted by LICENSOR.

THIS LICENSE IS A COPYRIGHT LICENSE ONLY, AND DOES NOT CONVEY ANY RIGHTS UNDER ANY PATENTS THAT MAY BE IN FORCE ANYWHERE IN THE WORLD. THE INTELLECTUAL PROPERTY IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE DO NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE INTELLECTUAL PROPERTY WILL MEET YOUR REQUIREMENTS OR THAT THE OPERATION OF THE INTELLECTUAL PROPERTY WILL BE UNINTERRUPTED OR ERROR FREE. ANY USE OF THE INTELLECTUAL PROPERTY SHALL BE MADE ENTIRELY AT THE USER’S OWN RISK. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR ANY CONTRIBUTOR OF INTELLECTUAL PROPERTY RIGHTS TO THE INTELLECTUAL PROPERTY BE LIABLE FOR ANY CLAIM, OR ANY DIRECT, SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM ANY ALLEGED INFRINGEMENT OR ANY LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR UNDER ANY OTHER LEGAL THEORY, ARISING OUT OF OR IN CONNECTION WITH THE IMPLEMENTATION, USE, COMMERCIALIZATION OR PERFORMANCE OF THIS INTELLECTUAL PROPERTY.

This license is effective until terminated. You may terminate it at any time by destroying the Intellectual Property together with all copies in any form. The license will also terminate if you fail to comply with any term or condition of this Agreement. Except as provided in the following sentence, no such termination of this license shall require the termination of any third party end-user sublicense to the Intellectual Property which is in force as of the date of notice of such termination. In addition, should the Intellectual Property, or the operation of the Intellectual Property, infringe, or in LICENSOR’s sole opinion be likely to infringe, any patent, copyright, trademark or other right of a third party, you agree that LICENSOR, in its sole discretion, may terminate this license without any compensation or liability to you, your licensees or any other party. You agree upon termination of any kind to destroy or cause to be destroyed the Intellectual Property together with all copies in any form, whether held by you or by any third party.

Except as contained in this notice, the name of LICENSOR or of any other holder of a copyright in all or part of the Intellectual Property shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Intellectual Property without prior written authorization of LICENSOR or such copyright holder. LICENSOR is and shall at all times be the sole entity that may authorize you or any third party to use certification marks, trademarks or other special designations to indicate compliance with any LICENSOR standards or specifications.

This Agreement is governed by the laws of the Commonwealth of Massachusetts. The application to this Agreement of the United Nations Convention on Contracts for the International Sale of Goods is hereby expressly excluded. In the event any provision of this Agreement shall be deemed unenforceable, void or invalid, such provision shall be modified so as to make it valid and enforceable, and as so modified the entire Agreement shall remain in full force and effect. No decision, action or inaction by LICENSOR shall be construed to be a waiver of any rights or remedies available to it.

None of the Intellectual Property or underlying information or technology may be downloaded or otherwise exported or reexported in violation of U.S. export laws and regulations. In addition, you are responsible for complying with any local laws in your jurisdiction which may impact your right to import, export or use the Intellectual Property, and you represent that you have complied with any regulations or registration procedures required by applicable law to make this license enforceable.

Table of Contents

1. Subject

This Engineering Report (ER) describes the OGC Testbed-15 Open Portrayal Framework (OPF) Thread requirements, scenario, high-level architecture, and solutions. Main topics addressed in the OPF Thread include style changing and sharing, converting style encodings, client- / server-side rendering of vector- and raster data and data provision in denied, disrupted, intermittent, and limited bandwidth (DDIL) infrastructure situations. The work in the OPF Thread was focused on an OGC Application Programming Interface (API) oriented approach.

2. Executive Summary

This Engineering Report provides a detailed summary of the Open Portrayal Framework (OPF) Thread in OGC Testbed-15, executed from April to November 2019.

The Open Portrayal Framework is a set of emerging specifications that support interoperable portrayal of heterogeneous geospatial data. The Open Portrayal Framework facilitates the rendering of geospatial data in a uniform way, according to specific user requirements. The primary topics addressed in the OPF thread covered supporting style sharing and updates, client- and server-side rendering of both vector- and raster data, and converting styles from one encoding to another; all following a single conceptual style model. In addition, the requirement to render data according to style definitions in a scenario with denied, disrupted, intermittent, and limited bandwidth (DDIL) infrastructure has been addressed.

This Engineering Report describes the Open Portrayal Framework requirements, scenario, high-level architecture, and solutions that were developed. Further details on the work carried out in the OPF Thread are provided in the following ERs:

The shift from traditional Web Services towards Web APIs has strongly influenced the work in the OPF Thread and as a result three draft specification Engineering Reports have been developed:

A high-level summary is available in the following ER:

2.1. Document contributor contact points

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

Contacts

Name Organization Role

Martin Klopfer

Frisia IT

Editor

Jeff Yutzler

Image Matters

Contributor

Joe Jagiella

Image Matters

Contributor

Clemens Portele

interactive instruments

Contributor

Keith Pomakis

CubeWerx Inc.

Contributor

Andrea Aime

GeoSolutions

Contributor

Stefano Bovio

GeoSolutions

Contributor

Jerome St-Louis

Ecere

Contributor

Joan Maso Pao

Universitat Autònoma de Barcelona (CREAF)

Contributor

Jeff Harrison

AGC

Contributor

Matt Sorenson

AGC

Contributor

Carl Reed

OGC

Contributor

Ingo Simonis

OGC

Contributor

2.2. Foreword

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.

3. References

4. Terms and definitions

For the purposes of this report, the definitions specified in Clause 4 of the OWS Common Implementation Standard OGC 06-121r9 shall apply. In addition, the following terms and definitions apply:

Style

a sequence of rules of symbolizing instructions to be applied by a rendering engine on one or more features and/or coverages

Style encoding

specification to express a style as one or more files

Note
In Testbed-15 Mapbox Styles, OGC SLD versions 1.0 and 1.1 are used.
Icons

In computing, an icon is a pictogram or ideogram displayed on a computer screen in order to help the user navigate a computer system. https://en.wikipedia.org/wiki/Icon_(computing)

Layer

A layer is an abstraction of reality specified by a geographic data model (feature, coverage…​) and represented using a set of symbols (Style) to plot it. A layer contributes to a single geographic subject and may be a theme.

Sprites

A sprite is a computer graphics term for a two-dimensional bitmap that is integrated into a larger scene.

Stylesheet

representation of a style in a style encoding.

Style metadata

essential information about a style needed to support users to discover and select styles for rendering their data and for visual style editors to create user interfaces for editing a style.

Coverages API

OGC API-Coverages provides the API building block to access coverages as defined by the Coverage Implementation Schema (CIS) 1.1 on the Web.

Features API

OGC API-Features provides the API building block to create, modify and query features on the Web.

Maps API

OGC API-Maps provides the API building block to describe, build and retrieve web maps.

Styles API

OGC API-Styles is a Web API that enables map servers and clients as well as visual style editors to manage and fetch styles.

Tiles API

OGC API-Tiles provides API building block to describe, build and retrieve tiles from any resource that can be subdivided in a regular set of tiles (e.g., maps, features and coverages).

Web API

API using an architectural style that is founded on the technologies of the Web. [source: OGC API - Features - Part 1: Core]

4.1. Abbreviated terms

API

Application Programming Interface

OGC

Open Geospatial Consortium

SLD

OGC Styled Layer Descriptor

SE

Symbology Encoding

WCS

Web Coverage Service

WFS

Web Feature Service

WMS

Web Map Service

WMTS

Web Map Tile Service

5. Overview

An overview of the major work items of the Testbed-15 Open Portrayal Framework thread is shown in Figure 1.

overviewOPF
Figure 1. Overview of the Testbed-15 Open Portrayal Framework major work items

The scenario for the emerging Open Portrayal Framework is described in detail in the following chapter Open Portrayal Framework Scenario. The scenario discussion explains the driving requirements for the various developments conducted in Testbed-15. Among these developments are a series of draft OGC Web APIs.

The draft OGC APIs are discussed from a more abstract viewpoint, with some of the major discussion items and design decisions being highlighted in the chapter Emerging OGC Web APIs. A detailed documentation of the APIs can be found in the respective ERs that are listed in the Executive Summary.

An enhanced GeoPackage model was developed to facilitate advanced styling in offline situations. The main results are discussed in the chapter GeoPackage.

The ER concludes with the documentation of a number of participant general discussions and design decisions required to complete the OPF Thread. These are reported in the chapter Technical Discussions.

A detailed description of implementation aspects and presentation of the results provided by the participants is presented in Annex A: OPF Implementations.

6. Open Portrayal Framework Scenario

The goal of the Testbed-15 Open Portrayal Framework thread was to implement a data discovery, access, and styled rendering scenario. The scenario included data updates performed as background tasks and support for online/offline functionality. The scenario is illustrated in Figure 2. Conceptually close steps are colored in matching shades of gray (i.e. steps 1-4, 5-6, 7-9, and 10-11). Logically differentiated Users 1-3 in this scenario can be realized as a single physical user.

scenarioOverview
Figure 2. The Testbed-15 Open Portrayal Framework scenario

Step 1: The user discovers API endpoints that provide vector, raster, or tiled vector or tiled raster data, maps, or coverages. The data can be retrieved via implementations of the OGC API – Features standard, or via emerging OGC API specifications for -Tiles and -Maps in addition to traditional OGC Web Services (OWS) such as WMS, WMTS, or WFS/WCS. Corresponding styles are made available at a dedicated endpoint. Links between the two allow understanding which style works with which data, and vice versa.

Step 2: User-1 loads styling instructions from the style server via the Styles API. Requirement: Style information shall be available at a dedicated endpoint that allows users to manage and modify styles.

Step 3: A user can modify any style using Visual Style Editors. These tools allow modifying styles and ideally transform styles from one encoding to another (e.g. from OGC SLD to Mapbox Style or vice versa).

Step 4: Styles are retrieved from the style API endpoint, modified in the Visual Style Editor, and uploaded to the style server again. The modified style is available to other users.

Step 5: Other users (here User-2) discover the same data. The references to the applicable styles have not changed.

Step 6: User-2 follows the reference to the styles and loads these. The rendered data now looks as defined by User-1.

Step 7: A third user or remote system makes new satellite imagery available to an image archive.

Step 8: This process triggers the re-building of individual tiles as served by Web API endpoints (APIs -Tiles or -Maps).

Step 9: Users interested in the changes since a given checkpoint can access the changed tiles (i.e. the change set) exclusively. This would allow large tile stores to be updated incrementally.

Step 10/11: In the future, the full scenario should be available to both online and offline situations. In this Testbed the focus was on adding styles and other data layers to OGC GeoPackages.

6.1. Scenario Details

The following paragraphs show the various implementations that have been created by participants in Technology Integration Experiments (TIEs) conducted in Testbed-15 and provide additional information.

Step 1 The user discovers API endpoints that provide vector, raster, or tiled vector or tiled raster data, maps, or coverages. The user loads the data and finds references to corresponding styles to render the data correctly (or retrieves pre-rendered tiles that apply the stylesheets).

step1
Figure 3. Step 1 & 2: Discover data and styles, load data, display data

Step 2 The references to the applicable styles point to a server that provides access to the styles via the Styles API. The user loads the style and applies the stylesheet to the data. Not happy with the result, the user decides to modify the style.

Three clients have been produced in Testbed-15 that interact with the various service endpoints as illustrated below.

Step 3 A user can modify any style using a Visual Style Editor. These tools allow modifying styles and ideally transform styles from one media type to another (e.g. from OGC SLD to Mapbox Style or vice versa).

step2
Figure 4. Step 3: Load Visual Style Editor, change and update style

Two Visual Style Editors were implemented in Testbed-15. Both are described and illustrated in Annex A: OPF Implementations and illustrated in the videos listed in the section Videos and Outreach Material. Both editors are capable of retrieving a style from a style server, updating the style locally, and re-distributing the style by uploading it to the style server.

Step 4 Once the stylesheet has been adapted to the user’s needs, the user may decide to make the modified style available via the Style API. The Style API provides transactional capabilities for that purpose.

Step 5 In Step 5, another User-2 discovers the same data as User-1. The references in the data to the applicable styles have not changed, since the data server is not aware of any modifications to styles. User-2 retrieves the data via the various API endpoints (API Maps or Tiles) similar to User-1.

Step 6 User-2 discovers references to the applicable styles and loads these similar to User-1 before. Except, that the loaded stylesheets now also contain the styling instructions which User-1 defined before, using the Visual Style Editor.

Step 7 & 8 Other users or systems make new satellite imagery available to an image archive. This process triggers the re-building of individual tiles as served by tile service endpoints.

The steps involve an implementation of the new OGC API - Images draft specification that allows uploading images to an image archive. The API basically functions like a catalog API and is further described in the section API Images. Three implementations of this API have been developed in the Testbed-15 activities.

step4
Figure 5. Step 7 & 8: New sat-scene added to image server and update tiles behind the scene

Step 9 User-1 needs to have the latest data for a given region. To avoid loading the entire data set again, User-1 requests all changed data since the last checkpoint (here: since the last request). Because new imagery data is now available, the data server provides a set of updated tiles.

The step makes use of the draft OGC API - Change Set specification as documented in the section API Changesets.

Step 10 & 11 The Open Portrayal Framework is envisioned to provide full support for online/offline mixed environments. For the offline situation, GeoPackages are used as a data container that supports a draft extension for styles and symbols. The necessary extensions are described in the section GeoPackage.

stepGeopackage
Figure 6. Step 10 & 11: Offline handling using Geopackage

GeoPackage builders ideally load all data using the same API endpoints as the users before.

7. Emerging OGC Web APIs

Testbed-15 required revision of the Web Map Tile Service (WMTS) standard to align the service definition with the emerging OGC API family of standards and specifications that are documented using OpenAPI and to allow for image transactions and style support. Early in the process, the Testbed participants decided to implement these requirements in the form of a set of Web APIs, each API handling specific functionality. Eventually, the Open Portrayal Framework developed the following draft APIs.

  • Styles to manage styles at dedicated style endpoints

  • Maps to handle pre-rendered geospatial data

  • Tiles to handle tiled geospatial data available for rendering

  • Images to allow uploading of images to image archives, and

  • ChangeSets to allow clients to request only incremental changes since a given checkpoint.

The Maps and Tiles APIs as well as Images and Change Sets APIs are documented together in the OGC Testbed-15 Images and Change Sets Engineering Report OGC 19-070. Eventually, the standards vetting and approval process for each API will be handled by a dedicated Standards Working Group within the OGC Standards Program. This work could result in five individual OGC APIs being documented and approved as OGC standards.

This report briefly discusses general aspects of each of these draft API specifications in the following chapters.

7.1. API Styles and Conceptual Model for Style Encoding & Metadata

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 draft API is 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 draft 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). The draft conceptual model provides information for understanding styles intended usage, availability, compatibility with existing layers, as well as supporting style search. The conceptual model defines three main concepts:

  • The style is the main resource.

  • Each style is available in one or more stylesheets - the representation of a style in an encoding like OGC Styled Layer Descriptor (SLD) 1.0, Symbology Encoding (SE) 1.1, Cascading Style Sheets (CSS), or Mapbox GL. Clients can use the stylesheet of a style that fits best based on the capabilities of available tools and their preferences.

  • For each style there is style metadata available, with general descriptive information about the style, structural information (e.g., layers and attributes), and so forth to allow users to discover and select existing styles for their data.

The conceptual model was developed taking into account the knowledge gained in the draft OGC Symbology Conceptual Model: Core part and the Vector Tiles Pilot (VTP) activities. The VTP, conducted just before Testbed-15 started, produced a first prototype of a Styles API independent of the style encoding

Testbed-15 developed the Styles API to allow management, sharing, and usage of styles independently from concrete API endpoints. With the new API, 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 can reference applicable styles served by dedicated Style Web API endpoints.

The Styles Web API proof-of-concept supports full CRUD (create, read, update, delete) and thus features reusability of styles in an unprecedented way. In combination with Visual Style Editors, commonly used styles can be adapted, transformed from one serialization format to another (Testbed-15 experimented with OGC SLD/SE, MapBox GL, CSS, and CNOSIS internal style format) and shared again after modification.

Web APIs implementing the draft OGC API - Maps specification fetch styles and render spatial data (features or coverages) on the server. Map clients fetch styles and render spatial data (features or coverages) on the client.

In order to support styles, data APIs (for example, supporting the OGC API-Features standard and/or the draft OGC API Tiles) require additional capabilities, too. These are:

  • List and manage the applicable styles per feature collection (path /collections/{collectionId}).

  • Add a queryables resource (path /collections/{collectionId}/queryables) to support clients such as visual style editors to construct expressions for selection criteria in queries on features in the collection. "Queryable" means that the property may be used in styling rules or other filter expressions.

The Styles API specification uses OpenAPI 3.0 to specify the building blocks of the API.

7.2. API Maps and Tiles

The OGC Web Map Tile Service (WMTS) implementation standard provides a standard based solution to serve digital maps using predefined image tiles. The standard builds on the Capabilities model, which is common to all OGC Web Service standards from the Key-Value-Pair (KVP) and Simple Object Access Protocol (SOAP) era, to advertise the tiles the service has available through a standardized declaration in the ServiceMetadata (aka Capabilities) document. This declaration defines the tiles available in each layer (i.e. each type of content), in each graphical representation style, in each format, in each coordinate reference system, at each scale, and over each geographic fragment of the total covered area. The ServiceMetadata document also declares the communication protocols and encodings through which clients can interact with the server. Clients can interpret the ServiceMetadata document to request specific tiles.

The new version of WMTS should be better aligned with the emerging OGC API family of standards. These APIs

  • leverage fundamental Web concepts,

  • are documented using OpenAPI, and

  • replace the Capabilities concept with a combination of landing page content and hypermedia controls.

This new family of (emerging) standards reflects the design change from existing Web service standards (W*S) towards Web APIs in order to serve geospatial data more natively on the Web. The Web API OGC API - Maps and Tiles draft specifications were further developed in Testbed-15 in response to these design changes.

As documented in the beginning of this chapter, Testbed-15 participants developed a series of APIs to cover functionality offered by a revised, transactional WMTS. The draft Maps and Tiles APIs, documented in detail in OGC document 19-069 adopt an approach similar to that of the OGC API - Features - Part 1: Core standard. The OGC API - Tiles draft specification describes a service that retrieves data representations as tiles. Tiles are organized into Tile Matrix Sets consisting of regular tile matrices available at different scales or resolutions. The OGC API – Tiles draft specification is described as a building block that can be plugged into an OGC API - Features service to retrieve tiled feature data (sometimes called vector tiles or tiled vector data) or to an OGC API – Maps implementation to retrieve rendered tiles (sometimes called map tiles). Thus, depending on the source data and the behavior of the corresponding service, a client may receive tiled vector data (e.g. as Mapbox, GeoJSON, etc.), or raster data (e.g. TIFF, NetCDF, etc.). In the future, tiles could even support multiple data formats in a single tile container, i.e. raster data and vector data in a single tile. The same concept is applicable to layers. A tile container could contain multiple layers (that can be of different types as well).

The maps part of the draft OGC API - Maps and Tiles specification describes an API that presents some data as maps by applying a style. These maps can be retrieved as tiles (if OGC API - Tiles is also adopted by the implementation) or as maps of any size generated on the fly.

7.3. API Images

The requirement for a Web API to handle new imagery came up in the context of updated tile caches. Basically, a new image becomes available and needs to be added to an image archive. The provisioning of that image then triggers the re-generation of tiles in an adjacent tile store for the area affected by the new image (or even the entire area, depending on tiling concepts and methodologies). So far, a direct connection between the image archive and the tile store is assumed. In a future initiative, this connection can be further analyzed and further decoupled. The Images API is described in full detail in OGC Testbed-15:Images and ChangesSet API Draft Specification Engineering Report (OGC 19-070).

The initial discussion focused on an image specific solution. However, it quickly became clear that the image archive case is nothing more than an asset catalog. An image catalog has just one main difference to most other catalogs: An image catalogue stores the images themselves and not just references, as most other catalogs do. This resulted in the Spatial Temporal Asset Catalog (STAC) being considered for use in the Testbed.

STAC is a Web API-enabled generic catalog solutions for spatio-temporal assets. "The Spatio Temporal Asset Catalog (STAC) specification aims to standardize the way geospatial assets are exposed online and queried. A 'spatiotemporal asset' is any file that represents information about the earth captured in a certain space and time. The initial focus is primarily on remotely-sensed imagery (from satellites, but also planes, drones, balloons, etc), but the core is designed to be extensible to SAR (Synthetic Aperture Radar), full motion video, point clouds, hyperspectral, LiDAR (Light Detection and Ranging) and derived data like NDVI (Normalized Difference Vegetation Index), Digital Elevation Models, mosaics, etc." (STAC).

7.4. API Changesets

The Changeset building block describes a mechanism for partial data updates to maintain synchronization between a server and a client cache that could be applied to any data service. Each retrieval of data from the server has associated a checkpoint identifier that is used in further communications. The Testbed-15 Open Portrayal Framework thread concentrated on updates to imagery stores. The filter mechanisms use checkpoint identifiers to constrain the response to tiles updated for a given target area since a provided checkpoint.

This work on changesets is closely related to the work on Delta Updates as performed in the Testbed-15 "Delta Updates" thread. In that thread, the goal was to develop a general solution to reduce the volume of transferred feature data in Denied, Degraded, Intermittent and Limited (DDIL) Bandwidth environments. Delta Updates explored how servers can decide to further reduce the amount of update data by leveraging classification schemes. Depending on the applied classification schema, the server may only send top priority updates in DDIL conditions and further lower priority updates, once conditions improve. The OGC Testbed-15: Delta Updates Engineering Report describes the delta updates solution and describes how prioritized delta updates can be served using a transactional extension for the OGC API – Features and the WPS standard/OGC API – Processes in front of WFS instances.

Within the OPF thread, the participants decided to keep the classification scheme available, since this approach might prove beneficial in future work. For Testbed-15, all tiles have been part of the same class, i.e. the schema has been ignored at implementation stage.

8. GeoPackage

Testbed-15 contributed in a large extent to the development of the Proposed OGC GeoPackage Enhancements Discussion Paper as published as OGC document 19-047. In this section, the main elements are briefly summarized. Focus is provided on experimentation experiences and lessons learned during the implementation phase of the Testbed-15 Open Portrayal Framework Thread.

8.1. Introduction

The Open Geospatial Consortium (OGC) GeoPackage Encoding Standard was developed for the purpose of providing an open, standards-based, platform-independent, portable, self-describing, compact format for transferring geospatial information. GeoPackage has proven to be an effective "container" mechanism for bundling and sharing geospatial data for a variety of operational use cases. However, GeoPackage stakeholders have observed persistent interoperability issues, particularly with regards to metadata, extensions, and portrayal.

While OGC 19-047 discusses a series of enhancements, this chapter focuses on enhancements directly relevant for portrayal, including enhancements to deal with change sets that are part of the Testbed-15 Open Portrayal Framework scenario.

8.2. GeoPackage Extensions and Profiles

Section 6.1.2 of OGC 19-047 introduces a concept for building metadata profiles. Metadata profiles are an optional agreement on how metadata is to be used in a GeoPackage to meet a particular purpose. Through the GeoPackage extension mechanism, a community of interest may define one or more metadata profiles that specify the encoding, scope, and purpose of a particular type of metadata. Without this mechanism, a GeoPackage client would be forced to inspect all metadata content to respect an out-of-band (non-machine-encoded) agreement to determine how metadata is being used in that file.

The GeoPackage Style Metadata Profile satisfies the need for metadata for styles. The second profile introduces data governance aspects to GeoPackages. The GeoPackage Delta Update Profile allows tracking local updates to a GeoPackage, so that they can be applied to another repository. GeoPackage is a single-user database with no built-in security, so any management of updates beyond version and checksum will rely on the trustworthiness of software and users. With that understanding, the GeoPackage Metadata Extension supports the elements needed to track updates made locally. Please note: The name Delta Update was used in early stages of Testbed-15 development and was only superseded by Change Set towards the end of the initiative.

An important GeoPackage mechanism produced during Testbed-15 was Semantic Annotations. This activity addressed interoperability issues caused by lack of formal semantics in data descriptions. There is an unbounded set of ancillary information that may be operationally relevant to GeoPackage users. Members of the GeoPackage community have periodically proposed adding additional columns to existing GeoPackage tables to address one-off operational needs. This approach does not scale, and adding additional columns to existing tables introduces interoperability risks and does not necessarily meet operational needs due to unclear semantics.

The proposed Semantic Annotations extension allows such information to be placed on any GeoPackage business objects. The schema for a Semantic Annotation is straight-forward, including resolvable URIs and types along with a human-readable name and description. Semantic Annotations are linked to business objects via the Related Tables Extension. Section 6.3.1 explains how the mechanism can be applied to link layers to styles, which is essential to identify appropriate styling rules, symbols, and fonts for data layers. Since the styles that will work for a particular layer are independent of the data (and may be produced by one or more completely different organizations), a loose coupling between layers and styles is preferred. By annotating layers (either conventional or tiled vector data) with known valid styles, a GeoPackage client may provide a user a reasonable set of style options to choose from. Whether the styles are stored directly in the GeoPackage or are accessible through a separate style service, the client will be able to retrieve the styles and apply them to the data in the layer.

The following figure illustrates the Semantic Annotation concept. Based on GeoPackage’s Related Tables Extension, the data content and its organization in a layer is linked to the stylesheets by leveraging the Semantic Annotation concept.

geopackageStylesLayers
Figure 7. Styles linked to layers based on the GeoPackage related table and Semantic Annotation concepts

The same approach can be applied to Stylable Layer Sets. The stylable layer set concept was introduced to group multiple styles that apply to the same data set or schema. For example, a stylable layer set could apply to a theater of operations and could group a set of styles (e.g., "topographic", "satellite overlay", and "night"). The original proposal called for a column to be added to a pair of tables, but the semantic annotation approach would be more flexible and could be applied to both conventional and tiled vector layers. In this latter case, both the layers and the styles could be annotated with one or more stylable layer sets.

geopackageSLS
Figure 8. Styles linked to layers based on the GeoPackage related table and Semantic Annotation concepts

A third practical example for Semantic Annotation is Layer-to-Layer Linking. When a GeoPackage contains a relatively large volume of vector data (either in conventional feature or tiled vector layers), a recommended practice is to pre-render raster tiles that cover a large geographic area. This reduces the need to render extreme numbers of features at run-time. In scenarios where a full OWS Context document is considered to be over-kill for the scenario, a simple semantic annotation can be used to link vector and raster layers that represent the same underlying data.

8.3. GeoPackage to support the Open Portrayal Framework

The longterm goal of the Open Portrayal Framework is to realize smooth online/offline experiences when dealing with high quality maps based on heterogeneous source data. Pre-rendered and raw vector- and raster data needs to be visualized using externally provided and governed styles. Updates in image archives causing re-generation of tile sets are made transferrable to tile caches using tile change-sets in both, online and offline scenarios. These requirements lead to the aforementioned extensions and Semantic Annotation concepts and have been implemented as documented below. In principle, three major challenges had to be addressed:

  1. Conveying the styling rules

  2. Coupling layers with styles

  3. Making the styling rules accessible operationally

8.3.1. Conveying Styling Rules

Styling rules must be encapsulated in a common encoding that can be used by GeoPackage clients to render (draw) the features onto the screen in a prescribed way. Participants in the OGC Testbed-15 Open Portrayal Framework Thread asserted that it is not realistic for the community to select a single encoding for styling rules. There are too many diverse requirements, existing encodings are too entrenched, and introducing a completely new encoding would be too risky and expensive. That said, the GeoPackage community would benefit from a default encoding. An ideal encoding would be standardized, easy to implement and use, and capable of handling the gamut of basic portrayal needs. Unfortunately, no single encoding has all three of these traits. As part of the OPF thread in Testbed-15, participants used two encodings.

  1. OGC’s Styled Layer Descriptor (SLD) is an OGC standard and handles most basic portrayal requirements. However, the use of an XML-based structure is considered by many to be difficult to use. In addition, XML is a poor choice in mobile computing environments, where GeoPackage is commonly used.

  2. Mapbox Styles is not standardized but it does handle most basic portrayal requirements and its JSON-based structure is considered relatively easy to use.

GeoPackage should support other encodings, either explicitly or through the use of extensions. This will allow organizations to innovate as technology evolves.

While allowing multiple style encodings does not maximize interoperability, this is the best solution available at this time. This solution considers the needs of both, the procurement community and the developers, for operating in a more agile environment. Each portrayal engine will have its own internal model for handling styles. The emergence of a symbology conceptual model (currently under development as OGC 18-067) will assist developers in mapping from one or more style encodings to their internal model.

8.3.2. Coupling Layers and Styles

Since styles and data layers are often developed independently, an effective spatial data infrastructure needs a way to couple layers with styling rules that are appropriate for those layers. This is particularly important in GeoPackage, where software capabilities tend to be more limited to support streamlined workflows that are easy to train for. The first requirement for effective style management is to provide a resolvable URI for each style. After that, there is some flexibility.

Independent map views, each with their own sets of layers and corresponding styles, can be encoded in the GeoPackage as OWS Context files using the proposed OWS Context Extension. For example, a topographic map may have no background (or possibly a single-colored base map as a background) and one or more feature layers, each with a specific style (referenced by its URI). A corresponding satellite overlay map may have tiled raster data as a background with the same set of feature layers, but with a different set of styles. The GeoPackage client can then provide a list of available contexts to the operator. This approach is the simplest for the operator, but does not provide the operator any way to customize the display.

Semantic Annotations can be used to couple layers with styles. In this case, it is the GeoPackage client’s responsibility to provide the appropriate list of styles to the operator. The operator can then select the desired style on a layer-by-layer basis.

Semantic Annotations can also be used to couple layers with stylable layer sets. In this case, the GeoPackage client’s and operator’s responsibilities are similar, but the organization of the styles is slightly different.

8.3.3. Making Styles Accessible Operationally

While the previous section describes how to couple layers and styles together, it does not address the challenge of getting the styles to the GeoPackage client, so that they can be used to visualize the data. Since there are a number of operational settings that a GeoPackage client may operate in, the infrastructure needs a number of ways to retrieve style information. Some of these ways include the following:

  • In a connected environment, a GeoPackage client may retrieve a style directly via its URI. In a mature architecture, the service hosting the style would be able to provide the style in more than one encoding so that the service can meet the needs of disparate clients.

  • In a disconnected environment, a GeoPackage client may retrieve a style directly from a GeoPackage via the proposed Styles Extension. When used in conjunction with manifests, a client would be able to discover that the Styles Extension is in use and what specific options (particularly encodings) are supported. The GeoPackage producer would then be responsible for ensuring that the styles are added in all of the necessary encodings and that the manifest fully reflects the GeoPackage’s contents.

  • In a mixed environment, a GeoPackage client may retrieve a style through a style service (i.e., registry) that can resolve a style via its URI. In this scenario, the service decouples the style from where it is stored. This provides flexibility beyond what would be appropriate for a GeoPackage Client to manage by itself.

8.4. Implementations and Lessons Learned

The following section provides an overview of the various participant implementations. The overview is complemented with important lessons learned during implementation and technical interoperability testing exercises. The following figure provides an overview of Testbed-15 Open Portrayal Framework GeoPackage components.

geopackageComponents
Figure 9. GeoPackage components developed Testbed-15 Open Portrayal Framework

Image Matters has developed a GeoPackage Provisioner that receives a JSON-formatted REST request and creates and populates a GeoPackage to meet that request. The Provisioner was originally written to support tile formats such as WMTS, but has been extended to support tiled vector data. The Provisioner supports other GeoPackage extensions in certain cases, but these are not currently handled in the case of vector tiles. Currently, the provisioner supports only the Coordinate Reference Systems (CRS) EPSG:3857 (Web Mercator) and EPSG:4326 (WGS84).

For example, a request could specify a CRS, a bounding box, a service, a layer, and a list of included zoom levels, and the provisioner would fetch all tiles with those specifications that fit within the bounding box, and put them into a GPKG. Optimistically, styling information is also gathered and included, according to the Style extension.

9. Technical Discussions

The following sections present the relevant technical aspects that have been discussed in the Open Portrayal Framework thread during the execution of Testbed-15:

9.1. Background Color

The Testbed-15 scenario required the usage of specific background color: gray. Whereas the MapBox styles technology allows setting background color values, OGC SLD does not. Testbed-15 developed a proposal as to how a background-color parameter should go in an SLD document and how this approach should work. After some discussions, the following solution emerged:

The SLD <UserStyle> element should be augmented to include an optional <BackgroundColor> element, whose value is a hexadecimal RGB color value. Colors in SLD and SE are expressed in the #RRGGBB form. The default value of this element should be "#FFFFFF" (white). This element declares the preferred background color of the style. Change request #620 was submitted against the Styled Layer Descriptor Profile of the Web Map Service Implementation Specification version 1.1.0 (OGC 05-078r4) to add this element.

Further discussion focused on whether the BackgroundColor could also be sensibly placed inside StyledLayerDescriptor for styles that have a list of NamedLayer/UserStyle (which is possible, and GeoServer’s preferred way of handling multi-layer styles, even outside the confines of tiled vector data). At the end, the idea was discarded because the preferred background color is as style-specific as the foreground colors and line thicknesses, etc.

If a tile is requested in a format that does not support transparency (such as JPEG), or if the request is made with TRANSPARENT=FALSE, the server should return the tile with a solid background of the color specified by the <BackgroundColor> element of the style. Change request #621 was submitted against the Web Map Tile Service Implementation Standard version 1.0.0 (OGC 07-057r7) to add this optional TRANSPARENT parameter.

If tiles are cached in an opaque format such as JPEG, clients cannot expect that the server changes the background color on the fly. A server could still conceivably cache PNG and return JPEG, but not all users will want to do this. Still, any server should not be expected to handle the "transparent" parameter (or any query parameter for that matter). A client application can always add parameters to a request, if the client desires the behaviors the parameters are intended to invoke. Services that don’t support or recognize these additional parameters will simply ignore them.

When a client application that is aware of this new mechanism is displaying a map and the bottom-most layer is a WMTS-tile layer, the client should request the tiles of that layer with TRANSPARENT=FALSE (or as a JPEG). This allows the map to be displayed with the background color that is appropriate for the selected style, without the client application having to know anything about the style (other than its ID). This can be done even for WMTS servers that do not declare this profile. This is because earlier WMTS servers will simply ignore the TRANSPARENT parameter and return transparent tiles, which will be displayed on the (presumably white) background of the client application, as it is currently done.

Even if the tile is returned with a transparent background (which is the normal case), the server should - if possible - endeavor to have the background be a fully transparent version of the color specified by the <Background> element of the style. This allows client applications to infer this information out of its cached tiles, if the client decides at a later time to provide an appropriate background color for them.

When a client application that is aware of this proposed mechanism is requesting tiled data and rendering the map, it will presumably have retrieved the style definition by making a GetStyle(s) request. From this, the client will be able to determine the correct background color by looking up the style’s <Background> element in the SLD. Then, the client can simply set the canvas to that background color.

This mechanism alleviates the need for a WMTS server to accept an arbitrary background color in a GetTile request, increasing cache use. The WMTS server could still potentially pre-render all tiles: pre-render a transparent and an opaque version of each.

As an example, the "Night" style in a previous initiative required a blue background. This information was communicated by the MapBox style definitions, but not the SLD style definitions. As a result, any SLD-based client application showing this style

  • either rendered a white background,

  • implemented coding specific knowledge of that background color into the client, or

  • inserted a large blue polygon layer to serve as the background color.

However, with the extension suggested above, the SLD encoding of the "Night" style could include this information as shown in the following example. This example assumes that a separate WMTS Layer is provided for each feature set:

SLD with <BackgroundColor> element, multiple layers
  <sld:StyledLayerDescriptor version="1.1.0" [...]>
    <sld:NamedLayer>
      <Name>AgricultureSrf</Name>
      <sld:UserStyle>
        <Name>Night</Name>
        <BackgroundColor>0x1E193E</BackgroundColor>
        <FeatureTypeStyle>
          [...]
        </FeatureTypeStyle>
      </sld:UserStyle>
    </sld:NamedLayer>
    <sld:NamedLayer>
      <Name>CulturePnt</Name>
      <sld:UserStyle>
        <Name>Night</Name>
        <BackgroundColor>0x1E193E</BackgroundColor>
        <FeatureTypeStyle>
          [...]
        </FeatureTypeStyle>
      </sld:UserStyle>
    </sld:NamedLayer>
    [...]
</sld:StyledLayerDescriptor>

or like this (if a single WMTS Layer contains all feature sets):

SLD with <BackgroundColor> element, single layer with all feature sets
  <sld:StyledLayerDescriptor version="1.1.0" [...]>
    <sld:NamedLayer>
      <Name>Daraa</Name>
      <sld:UserStyle>
        <Name>Night</Name>
        <BackgroundColor>0x1E193E</BackgroundColor>
        <FeatureTypeStyle>
          <FeatureTypeName>AgricultureSrf</FeatureTypeName>
          [...]
        </FeatureTypeStyle>
        <FeatureTypeStyle>
          <FeatureTypeName>CulturePnt</FeatureTypeName>
          [...]
        </FeatureTypeStyle>
        [...]
      </sld:UserStyle>
    </sld:NamedLayer>
  </sld:StyledLayerDescriptor>

The following demo provided by CubeWerx demonstrates the concepts described above. Note that some links may not work any longer at the time of reading, but the URL structure and corresponding figures should still provide valuable information.

Look at the SLD at this link or in this annex.

Notice that the "Topographic" style has a <sld:BackgroundColor>#CCCCCC</sld:BackgroundColor> element (look, gray!) and the "Night" style has a <sld:BackgroundColor>#1E193E</sld:BackgroundColor> element. This specifies the preferred background color for these styles. The "Overlay" style does not have a BackgroundColor element, so the preferred background color defaults to white.

Make a tile request to https://tb15.cubewerx.com/cubewerx/cubeserv/op/wmts/1.0.0/tiles/Daraa_vectors/Topographic/smerc/14/6621/9838.png. Notice that the standard tile still has a transparent background.

c1
Figure 10. Tile with a transparent background

If one executes the following endpoint https://tb15.cubewerx.com/cubewerx/cubeserv/op/wmts/1.0.0/tiles/Daraa_vectors/Topographic/smerc/14/6621/9838.png?transparent=false. the client will display an opaque tile, where the background color is not the default white, but the color specified by the BackgroundColor element in the style! If a client application always requests the bottommost layer with transparent=false, the client will automatically get the background color that is the most appropriate for that layer.

c2
Figure 11. Tile with a background as defined by the style

The application can also accomplish this same capability by specifying a format that does not support transparency. Try https://tb15.cubewerx.com/cubewerx/cubeserv/op/wmts/1.0.0/tiles/Daraa_vectors/Topographic/smerc/14/6621/9838.jpg.

c3
Figure 12. JPEG tile

As an experimental extension (not proposed as part of the API Tile specification), the Cubewerx tile requests also accept a BackgroundColor parameter that can be used to specify an arbitrary background color. Executing the following endpoint service https://tb15.cubewerx.com/cubewerx/cubeserv/op/wmts/1.0.0/tiles/Daraa_vectors/Topographic/smerc/14/6621/9838.jpg?BackgroundColor=red allows various color syntaxes to be accepted.

c4
Figure 13. Tile with red background
c5
Figure 14. WMS response with background as defined by style

Cubewerx created a short demonstration, available at https://tb15.cubewerx.com/cubewerx/demos/BackgroundColorDemo.html to illustrate the final effect. In addition to the gray background of the Topographic style, check out the blue background of the Night style! Also note that when the "Daraa Mosaic 2019" imagery is selected, the imagery becomes the background. The following figures show the client in action:

c6
Figure 15. Different map representations. Upper left: gray background, upper right: overlay with white background; lower left: night style; lower right: overlay with satellite image tiles as background

9.2. Styleable Layer Set

The Styleable Layer Sets concept was introduced to group multiple styles that apply to the same data set or schema. For example, a styleable layer set could apply to a theater of operations and could group a set of styles (e.g., "topographic", "satellite overlay", and "night"). The concept was originally developed as part of the Vector Tiles Pilot and is described in detail in the OGC Engineering Report 18-101 with the concept’s definition and a corresponding UML diagram.

Styleable layer sets allow defining bi-directional data layer to style and style to data layer associations. In this context, please note that a styleable layer set is necessarily constrained to vector data.

GeoPackage has support for styleable layer sets as well. This capability is described in section GeoPackage: Coupling Styles and Layers. The recommended approach uses the semantic annotation model. Here, the original proposal called for a column to be added to a pair of tables. However, the semantic annotation approach would be more flexible and could be applied to both conventional and tiled vector layers. In this case, both the layers and the styles could be annotated with one or more styleable layer sets.

9.3. Conversions Between style Encodings

9.3.1. GeoSolutions

The Visual Style Editor component implementation allowed experimenting with some rendering and style conversion JavaScript libraries. Tests focused mainly on vector layers representing the urban area of Daraa, including points of interest, polygon surfaces and lines connections. The implementation focused on simple styles to get a good match between parameters of different encodings, in particular SLD and Mapbox Style. The following symbolizers and properties were considered in the GeoSolutions implementation:

  • Point

    • Image source.

    • Scale/size of marker.

  • Line

    • Stroke color.

    • Stroke width.

    • Stroke opacity.

  • Polygon

    • Outline color.

    • Outline width.

    • Fill color.

    • Fill opacity.

GeoStyler, a JavaScript library for encoding and translation, was integrated in MapStore, and results were displayed in both an OpenLayers and a MapBox Client. Figure 16

geoSolutionsConversionStyleComparisonTopOLClientBottomMapboxGLClient
Figure 16. MapStore Client Demo - testing conversion and rendering of styles on the client side. (Top: OpenLayers Client, bottom: Mapbox GL Client)

It is also worth considering the GeoServer server side conversion. GeoServer rendering engine is based on a style object model mapping one to one the SLD 1.0 structures, with a few extensions. A user is however allowed to enter a style description in multiple encodings, including SLD 1.0, SE 1.1, GeoCSS, Mapbox Styles, YSLD. Each style encoding support includes:

  • A parser for the encoding, able to parse the whole syntax, for most encodings, or just partially, for example, for Mapbox GL styles.

  • A translator from the encoding structure to the GeoServer style object model, which always allows a complete encoding in SLD 1.0 (with extensions).

  • An optional encoder, from the GeoServer style object model, back to the encoding. Currently only YSLD supports this functionality.

Given this structure, the ability to translate between languages is often offered in a single direction, towards GeoServer extended SLD 1.0, but normally quite complete, and limited only by the plugin ability to parse the source structure. It is however important to notice that most of the encodings discussed above have the same expressive power as SLD 1.0, and differ only by syntax and rule mechanics, both of which can be bridged down to SLD with some effort.

Outside of the Testbed-15 GeoSolutions also had experiences with QGIS style translation to SLD. In that case, there is a wide variety of styling ability, symbolizers in particular, that simply cannot be translated to standard SLD. Some examples follow:

  • Layer compositing (alpha masking and color blending).

  • Z-ordering (within layer, or cross layer, e.g., between roads, rails and lakes).

  • Gradient fills.

  • Shapeburst fills.

  • Inverted polygon rendering (coloring the outside of the polygon, instead of the inside).

  • Advanced raster color stretching, such as cutting values outside of a given range, and/or stretching the colors to a given range.

Summarizing, style conversion limitations could be due to:

  • Incomplete parsing of the source.

  • Incomplete translation between the styling models.

  • Lack of concepts in the target encoding, or mismatch of the same.

  • Different mechanics requiring actions outside of the mere style (e.g. translation of source scalable SVG resources, or marks, to a sprite with the exact images required, feature by feature).

  • Incomplete encoding of the target.

9.3.2. Ecere

Ecere implemented styles conversion from scratch between SLD/SE, Mapbox GL and GNOSIS Cascading Map Style Sheets (CMSS).

The functionality was developed as importing and exporting capabilities for the SLD/SE and Mapbox GL styles encodings to and from GNOSIS’s native CMSS. The conversion process can also convert between SLD/SE and Mapbox GL through CMSS acting as a bridge.

This functionality was used and demonstrated in three different ways:

  • using a simple command-line tool;

  • on the Ecere’s Styles API service where a style can be supplied in one or two formats and automatically be made available in the missing formats;

  • as well as within GNOSIS Cartographer’s Visual Style Editor, where styles can be imported and exported, either simply from local files, or from styles accessed from GNOSIS data stores, GeoPackages or OGC API - Styles.

A major distinction of CMSS is that the order of rules defines the order of overrides, rather than the drawing order of layers.

These rules overrides allow for easily specializing symbology through nested rules. The rules overrides also allow for defining complex multi-dimensional styling where flattening the rules would result in a very large number of negative rules. These negative rules do not have to be expressed with support for overrides (e.g. see styling Thermokast map from OGC Arctic Spatial Data Platform initiative). To convert CMSS to SLD/SE or MapboxGL, the rules must be flattened and these negative filters must be generated (except for the top-level ElseFilter in SLD/SE). To import the styles back to CMSS, the parser must attempt to deduct the nesting and overrides from the selectors in an attempt to simplify the styles.

With CMSS, all enabled layers are rendered by default with default styles (e.g. black strokes and white fill), whereas in MapboxGL and SLD/SE a layer is not rendered, unless explicitly specified in the style.

In CMSS, ordering is specified explicitly using a zOrder property, which allows for example to change the z-ordering property within the layer or across different layers.

Another important distinction is how CMSS explicitly defines lines casing as a property of the stroke, rather than defining a separate rule for rendering a separate line on top. This allows, for example, to render the line in a single pass, and allows defining a casing width in pixels while using real-world units such as meters for the thickness of the stroke. For 3D views, this in turn enables smooth strokes across different zoom level transitions. Importing the stroke and casing widths from the other encodings was a challenge, especially as different styles definitions sometimes use different mechanism. The parser attempted to identify multiple line symbolizers as stroke and casing. MapboxGL offers the 'step' function which was used to encode real-world widths based on zoom level. SLD/SE supports specifying of units of measure, but does not support specifying a casing width in pixels while the main stroke is defined in meters.

STROKEARTIFACTS
Figure 17. Example of rendering artifacts in 3D with fixed pixel stroke and casing widths