Publication Date: 2018-10-09

Approval Date: 2018-06-08

Posted Date: 2018-05-17

Reference number of this document: OGC 17-094r1

Reference URL for this document:

Category: Public Engineering Report

Editor: Jeff Yutzler, Rob Cass

Title: OGC Portrayal Concept Development Study

OGC Engineering Report


Copyright © 2018 Open Geospatial Consortium. To obtain additional rights of use, visit


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 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.


Permission is hereby granted by the Open Geospatial Consortium, ("Licencor"), 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 sub license 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 LICENCOR.


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 sub license 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 LICENCOR’s sole opinion be likely to infringe, any patent, copyright, trademark or other right of a third party, you agree that LICENCOR, 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 LICENCOR 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 authorisation of LICENCOR or such copyright holder. LICENCOR is and shall at all times be the sole entity that may authorise you or any third party to use certification marks, trademarks or other special designations to indicate compliance with any LICENCOR 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 LICENCOR 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

Abbreviated terms

NOTE: The abbreviated terms clause gives a list of the abbreviated terms and the symbols necessary for understanding this document. All symbols should be listed in alphabetical order. Some more frequently used abbreviated terms are provided below as examples.
  • AML Additional Map Layers

  • API Application Programming Interface

  • APP-6 Allied Procedural Publication 6

  • ASDI Arctic Spatial Data Infrastructure

  • CAFF Conservation of Arctic Flora and Fauna

  • CITE Compliance Integration and Testing Environment

  • CDS Concept Development Study

  • COM Component Object Model

  • COTS Commercial Off The Shelf

  • CQL Common Query Language

  • CR Change Request

  • CRS Coordinate Reference System

  • CRUD Create Read Update Delete

  • CSS Cascading Style Sheet

  • CSW Catalogue Service for the Web

  • DCAT Data Catalogue Vocabulary

  • DCE Distributed Computing Environment

  • DCOM Distributed Component Object Model

  • DGIWG Defence Geospatial Information Working Group

  • DNC Digital Navigational Chart

  • ebRIM electronic business Registry Information Model

  • ENC Electronic Navigational Chart

  • ESRI Environmental Systems Research Institute

  • FES Filter Encoding Specification

  • FGP Federal Geospatial Program

  • FPS Feature Portrayal Service

  • GIS Geospatial Information System

  • GPU Graphics Processing Unit

  • GSC Geological Survey of Canada

  • GWG Geospatial Working Group

  • HTML Hypertext Markup Language

  • HTTP HyperText Transfer Protocol

  • IDL Interface Definition Language

  • IHO International Hydrographic Organisation

  • ISO The International Organisation for Standardisation

  • JSON JavaScript Object Notation

  • KML Keyhole Markup Language

  • NATO North Atlantic Treaty Organisation

  • NGA National Geospatial Intelligence Agency

  • NRCAN Natural Resources Canada

  • OWS OGC Web Services

  • PNG Portable Network Graphics

  • REST Representational State Transfer

  • RFC Request for Comments

  • SDI Spatial Data Infrastructure

  • SDO Standards Developing Organisation

  • SE Symbology Encoding

  • SIDC Symbol Identification Code

  • SLD Styled Layer Description Language

  • SQL Structured Query Language

  • STANAG Standardisation Agreement

  • SVG Scalable Vector Graphics

  • SWG Standards Working Group

  • SWOT Strengths, Weaknesses, Opportunities, Threats

  • TDL Topographic Data Layer

  • URI Universal Resource Identifier

  • URL Uniform Resource Locator

  • WKT Well Known Text

  • WMS Web Map Service

  • WMTS Web Map Tile Service

  • XML eXtensible Markup Language

  • YAML Yet Another Markup Language

  • YSLD YAML Styled Layer Descriptor

1. Summary

Digital cartography, even in today’s technology age, remains a fine art. As digital maps are increasingly used in urban development, disaster relief, and mission planning activities, inaccurate and inconsistent map generation are potentially detrimental to the success of those activities. The goal of this concept development study (CDS) is to advance the standards and guidance that will allow production of high-quality digital maps over the web from existing vector data. In this Engineering Report, the CDS Team has done this through the following three activities.

  1. Assessing the current state of feature portrayal. This was done through a high-level overview (see SWOT Analysis), reviewing the existing workflows that support the capability (see [WorkflowsClause]), reviewing relevant technologies, standards, and research papers (see Styled Layer Descriptor and Symbology Encoding), and by conducting two case studies (see Case Study 1 - Arctic Spatial Data Infrastructure (SDI) and Case Study 2 - Canadian Federal GeoSpatial Platform).

  2. Establishing a vision for a set of capabilities that will meet the long-term goals of the geospatial community in this area (see Vision).

  3. Providing a roadmap for achieving the set of capabilities identified in the vision (see Roadmap).

The CDS Team determined that existing capabilities are insufficient to meet industry needs. While the existing Styled Layer Descriptor (SLD) and Symbology Encoding (SE) standards were designed to support interoperable mapping, they have a number of issues as described in Limitations of SLD and SE. Revising these standards will lead to a more flexible, adaptable, and powerful standard that is capable of meeting the broad needs of the industry. However, portrayal standards by themselves are not sufficient to manage the complexity caused by multiple data sources, multiple potential styling rules, multiple map production stacks, and multiple client needs. The emerging concept of Semantically-Enabled Portrayal is designed to mitigate this complexity. Ideally this technology will allow producers to maintain their logical workflows, but not restrict physical implementations based on any one particular GIS system.

The CDS Team believes that these technologies working together will enable the geospatial industry to meet its long-term goals in this area. As these are emerging technologies, they will need to be built incrementally in conjunction with interoperability experiments and other activities. These activities will require both funding and engineering support. OGC is well-positioned to lead and supervise these activities, but ultimately the activities will only be as successful as the support they get from the broader geospatial community. The next challenge is to establish a coalition of geospatial community stakeholders who are willing and able to support these activities.

1.1. Background

As vector maps moved into the digital age, domain models and schemas were developed to store, re-use, and disseminate feature information for production. Examples of these models are the National Systems for Geospatial-Intelligence (NSG) Application Schema (NAS), US Army’s Ground-Warfighter Geospatial Data Model (GGDM), and the US Geological Survey’s (USGS) Geological Map Schema (GeMS). They provide standardized attribution and relationships of feature data to unify production, simplify visualization logic, and increase overall utility from its hard-copy predecessor. While these models were designed to be independent of any physical implementation, to ensure consistency, existing map generation workflows are generally aligned with a specific Geographic Information System (GIS). This is not sustainable in a modern environment where geospatial maps are created by people all over the world using the wide variety of tools that are available in the market.

Robinson (et. al.) in The Elements of Cartography ([Elements-Carto]) states, “in order to represent the chosen characteristics of spatial data in meaningful fashion, we must make use of variations in the graphic qualities, analogous as communicative media to the sounds of speech, have been called the visual variables. These are the perceptual dimensions of graphic character that can be systematically modulated to convey meaning.” Robinson lists the visual variables in map making: position, shape, size, color, value, pattern and direction. The current domain of web-based map driven display often ignores the fundamental concepts of basic cartography. The developers of the web-based map tools are often programmers with little cartographic experience or training. Representation of similar features with arbitrary use of colors, symbols, patterns, shapes and sizes can cause major problems.

One attempt to help resolve this gap of understanding was to develop a pair of Open Geospatial Consortium (OGC) standards that developers could “plug in” and use, called Styled Layer Descriptor (SLD) and Symbology Encoding (SE). These standards could be used to establish a preset list of styles and symbols that digital cartographers could use to ensure the ensuing maps use appropriate for their intended use. The operational use of these standards has been limited for a number of reasons. Various OGC testbeds over the years have attempted to make them more usable but very little tangible progress has been made. As a result, common styling and symbology is not being used in scenarios that would benefit. The OGC Architecture Board (OAB) has identified the renovation of SLD as a key issue in OGC.

1.2. Document contributor contact points

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

Table 1. Contacts
Name Organisation

Jeff Yutzler

Image Matters LLC

Rob Cass

Compusult Ltd.

Adam Parsons

Compusult Ltd.

Terry Idol


Luis Bermudez


1.3. 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.

2. References

3. Overview

The main goal of this CDS is to advance the standards and guidance that will allow production of high-quality digital maps over the web from existing vector data.

3.1. Document Layout

The document is organized into the following sections.

Section 4 (SWOT Analysis) presents strengths, weaknesses, opportunities, and threats relevant to this CDS.

Section 5 ([WorkflowsClause]) presents a review of the two main workflows (conventional and semantic) that are available for producing maps.

Section 6 (Case Study 1 - Arctic Spatial Data Infrastructure (SDI)) presents a case study for the Arctic Spatial Data Infrastructure.

Section 7 (Case Study 2 - Canadian Federal GeoSpatial Platform) presents a case study for the Canadian Geospatial Platform.

Section 8 (Vision) presents a vision of a set of capabilities that together will allow the geospatial community to realize the goals presented in the case studies.

Section 9 (Roadmap) presents a roadmap for future work, including pilots, testbeds, interoperability experiments, and standards development work that will advance to required capabilities.

Appendix A (Supplemental Information) presents additional information that was deemed relevant to an overview of the standards process.

Appendix B (Styled Layer Descriptor and Symbology Encoding) presents a detailed review of SLD and SE, including change requests that have been issued to the SLD standard.

Appendix C (Terms and definitions) presents terms and definitions.

Appendix D (Revision History) presents revision history.

Appendix E (Bibliography) presents a bibliography.

4. SWOT Analysis

In the beginning stages of the project, the CDS Team performed a Strengths, Weaknesses, Opportunities, and Threats (SWOT) analysis with regards to the current state of the feature portrayal capabilities.

4.1. Strengths

The first step identified the following strengths.

  • Current technologies exist that can serve as a starting point.

    • SLD

    • Semantic Portrayal

  • There is interest/motivation/energy in solving the problem.

    • The OGC Architecture Board (OAB) recently identified the renewal of SLD as a key priority. The OAB took an action to promote a Portrayal ad‐hoc meeting during the June 2017 Technical Committee (TC) meetings. The agenda included a range of use cases from simple to complex. The need for a conceptual model was identified as a method to move forward.

    • Symbology / Styling was identified as the top priority for GeoPackage as part of a survey conducted in 2015 (

4.2. Weaknesses

The second step examined the major weaknesses.

  • Existing services and cartographic libraries are too tightly coupled due to security provisions and internal architectures.

  • Currently there is a perception that the existing portrayal standards are complicated to use.

  • The implementation of portrayal capabilities is not consistent from vendor to vendor so the expected interoperability is not realized.

  • The current portrayal standards are not extensible so there is no clear way to add additional capabilities without a burdensome standard revision process.

  • The current portrayal standards lack test suites.

4.3. Opportunities

The third step looked at possible opportunities.

  • There is emerging portrayal standards work. This consists of an ongoing effort underway to revise the SLD and SE standards to correct flaws in those original portrayal works. This work is likely to culminate in a useful standard.

  • Semantic Portrayal is an emerging technology that has the potential to allow diverse datasets to share common portrayal rules.

  • GeoPackage can be an excellent portrayal incubator. The relatively fast adoption of the GeoPackage Encoding Standard gives the community a platform to experiment with new portrayal capabilities.

4.4. Threats

The final portion of the analysis was to examine possible threats.

  • There are closed solutions that rely on unique technologies. These closed solutions create barriers to broad implementation of capabilities as it is unrealistic to expect every organization to be willing and able to use the same underlying technology stack. Even worse, these technology solutions do not necessarily follow the same cartographic methods. This often means that there is no straightforward way to incorporate a new technology into the workflow without completely eliminating another part of it.

  • The cost/benefit of standardizing portrayal is an issue. Many organizations have expressed a desire for the capabilities described here but the desired capabilities may require moderate or expensive engineering work. Some of these organizations lack the funding to support the effort. Other organizations have the funding but do not have the business case to prioritize this effort over others.

  • Becoming too encoding-oriented can cause misplaced effort. As of today, there is no ideal format for exchanging portrayal information. Organizations have tried a number of different formats over the years, with middling results. Each new format further fragments the industry and makes it harder to achieve interoperability. == Digital Mapping Workflows This section presents two workflows for producing and using digital maps. The Conventional Workflow is more closely aligned to what it is done in most environments today. Many organizations have attempted to implement the Conventional Workflow with varying degrees of success. The approach has been proven to be insufficient when confronting a scenario with multiple data sources, styling rules, or technology stacks.

In response, a new Semantically-Enabled Workflow is under development. This workflow is specifically designed to mitigate the lack of scalability (in multiple dimensions) demonstrated by the Conventional Workflow. The Semantically-Enabled Workflow, while substantially more complex than the Conventional Workflow, shows promise for its ability to seamlessly integrate elements with disparate origins.

4.5. Conventional Workflow

In the Conventional Workflow, digital maps are produced in a linear process that takes base feature and raster data, applies styles to those data, and produces digital maps which can then be shared and displayed. There are two variations on this workflow. In the first (server-side portrayal), the portrayal occurs on the server-side and the resulting maps are shared. In the second (client-side rendering), the portrayal engine is present on the client. However, the preceding operations occur in a similar way and the resulting capabilities have similar limitations.

Figure 1. Conventional Workflow

The following subsections describe each phase of this workflow in detail. The phases are presented in reverse order because this roughly corresponds to the order in which they were developed and their level of maturity. The discussion also presents the phases in order of distance from the consumer of the final map product.


This section is heavily influenced by the four use cases for sharing maps as part of a Spatial Data Infrastructure (SDI) that are presented in [Bocher-Ertz]. These four use cases are discover, author, catalog, and collaborate.

4.5.1. Digital Map Display

In this phase, a digital map is presented on the user’s display. There are generally two ways in which this is done, server-side portrayal and client-side rendering.

Server-Side Portrayal

In server-side portrayal, a map is portrayed by a server and transmitted in a graphical format to the client. This can be done beforehand or in a just-in-time manner. While the just-in-time approach has the advantage of ensuring that the most up-to-date data is used, the server processing costs may be problematic so often maps are produced beforehand (see Map Portrayal below).

The following subsections describe the large number of enabling technologies that have emerged to support this need.

Web Map Service

WMS ([WMS]) is an OGC open standard that allows a client to use a GetMap operation to request a map from a server based on a narrow set of criteria such as extents, CRS, layer name, and pre-defined style. Typically the maps are produced during run-time. This has the advantage of ensuring that the resulting map is based on the most current underlying data available. Also, when supported by the server, the ability to provide a style allows the client a great amount of flexibility in customizing the resulting map. However, WMS requires robust servers and network infrastructure that make it a poor fit for many operational environments.

Styled Layer Descriptor and Symbology Encoding

To date, OGC’s efforts to standardize portrayal have focused on two complementary standards, Styled Layer Descriptor (SLD) and Symbology Encoding (SE). The OpenGIS Styled Layer Descriptor Profile of the Web Map Service Implementation Specification ([WMS-SLD]) allows SLD and SE to be used in conjunction with WMS to enable just-in-time map portrayal.

For a detailed review of SLD and SE, see Styled Layer Descriptor and Symbology Encoding.

Web Map Tile Service

WMTS ([WMTS]) is an OGC open standard that allows a map to be accessed as a set of raster map tiles. Unlike WMS, map tiles are generally stylized and produced in advance. This lowers the processing burden on the server and in effect the performance of a GetTile operation depends almost completely on the speed of I/O operations. In addition, since tiles are discrete, clients can cache them, reducing the I/O burden even further. However, clients have limited flexibility in customizing the ensuing views.

Tile Matrix Set

Tile Matrix Set is an emerging OGC candidate standard for defining a way to index the space based on a set of regular grids defining a domain in a CRS (tile matrix) at a limited list of scales. The model is drawn from what is currently in WMTS. This candidate standard has not yet been released for public comment. If it is adopted by OGC, other standards, including but not limited to WMTS, will be able to reference it and use its model in a consistent way, allowing tiles to be shared across different underlying technologies. While this does not affect portrayal directly, it does simplify the use of shared tiles (vector or raster) across systems.

Client-Side Portrayal

Implementers who develop browser-based and mobile-based applications have found that SLD/SE-based approaches are a poor fit for their environments. Today’s applications use technologies such as Scalable Vector Graphics (SVG) and WebGL to aid in rendering operations. These technologies allow the Graphical Processing Unit (GPU) to aid in rendering, which improves performance (both speed and battery use) on web and mobile clients.

The uptake of client-side portrayal has been driven by the use cases most often encountered in the deployment of online maps. Client developers are typically only interested in a focused portrayal of similar, and often single datasets, such as retail store locations. An efficient method for accomplishing this is to access a well-known 3rd party mapping platform such as OpenLayers, Mapbox, or Google Maps that provide an interactive base map over which the client focused data is overlaid. The client-side implementor does not need to construct a rendering back-end, base set of styles, reference mapping data, or a means to interact with the data. Instead, introducing the new layer of interest involves providing a source of GeoJSON or vector tiles, then using JavaScript to integrate with the map client overriding basic styles using JavaScript interfaces. Extending renderers involves one JavaScript method to interact with the imported API.

Developers participating in these use cases see mapping as a small part of their set of requirements and are not typically geospatial specialists or cartographers. It is no coincidence that both Mapbox and OpenLayers provide this approach in their distribution and support for online maps. The similarity between these two systems underlines their effectiveness in the hands of the modern web developer and supports the development of a tool that can use the same interface to style data for MapBox or OpenLayers frameworks [maputnik].

Vector Tiles

Since raster data tends to be denser than vector data, in many operational environments, it is more efficient to deliver the vector data to the client (for example, as vector tiles) and to portray the data locally. Vector tiling is a technique for splitting vector data (as opposed to raster data) into appropriately sized segments. The encoding of vector tiles into a transport format allows this data to be transmitted to the client so that it can be analyzed and/or portrayed in a map client. Since vector data is less dense than raster data containing the same information, the I/O demands are reduced. This improves performance in many operational environments.

The vector tiling approach supports both analysis and visualization in a more storage/bandwidth-efficient way than server-side approaches, but until recently the costs of client-side rendering have been prohibitive. SLD and SE are poorly suited to client-side rendering. The encoding style of SLD and SE is not as efficient as JSON. Some required portrayal functionality is not properly supported in SLD/SE including portrayal concepts related to 3-dimensional portrayal such as lighting, camera position, pitch, etc.

In response, implementers have looked for alternatives to SLD/SE that directly support these technologies and are more conducive to client side rendering. The Testbed-12 Vector Tiling Engineering Report ([VectorTilesTB12ER]) notes that there are a wide range of aspects and possible approaches related to implementing vector tiling and that there is currently no open standard for vector tiles. Since there is currently no open standard for vector tiles or portrayal thereof, interoperability of this capability cannot be assured.

Mapbox Vector Tiles

Mapbox has produced a specification ([MapboxVectorTiles]) based on Protocol Buffers. The Testbed-12 Vector Tiling Implementation Engineering Report ([VectorTilesImpTB12ER]) presents a competing approach to the Mapbox approach using GeoJSON ([GeoJSON]). At this time, the Protocol Buffers-based approach is only used in Mapbox Vector tiles, so GeoJSON is more interoperable. However, Protocol Buffers are a more efficient storage mechanism than JSON.

Mapbox Style Specification

The Mapbox Style Specification ([MapboxStyles]) is a JSON encoding for styles that is specifically designed to work with Scalable Vector Graphics (SVG), WebGL, and vector tiles. Mapbox styling supports some 3d portrayal concepts. The JSON encoding is intended for client side interpretation and portrayal. Boundless is researching the use of this format as an alternative to SLD or YSLD. The implementation provided by Boundless converts Mapbox styling directives to SLD on the server.

Open Layers Style Specification

The Open Layers Style Specification ([OLStyles]) is a Javascript API that supports most of the same concepts as MapBox and SLD/SE. It supports the same paradigm as Mapbox styles.


GeoPackage ([GeoPackage]) is an open, standards-based, platform-independent, portable, self-describing, compact format for transferring geospatial information. The GeoPackage Encoding Standard describes a set of conventions for storing geospatial data and information within an SQLite database. Since a GeoPackage is a database container, it supports direct use. This means that data in a GeoPackage can be accessed and updated in a "native" storage format without intermediate format translations. GeoPackages that comply with the standard and do not implement vendor-specific extensions are interoperable across all enterprise and personal computing environments. GeoPackages are particularly useful on mobile devices such as cell phones and tablets and in communications environments where there is limited connectivity and bandwidth. Since GeoPackage uses the same underlying data models for geospatial data, the data can be shared across computing environments and portrayed using the same techniques described throughout this paper.

OWS Context

OWS Context ([OWS-Context]) is a set of OGC open standards describing an open format linking geospatial web services and information. The structure is a hierarchical set of offerings, which may be heterogeneous. OWS Context supports a number of use cases including a map view. For example, an OWS Context document may include a base map from a WMTS, overlays from a WMS, and feature data as GeoJSON styled with SLD.

OGC has adopted the OWS Context conceptual model and two encodings, ATOM and JSON (a third encoding for SQLite is currently under consideration). OWS Context uses a "core and extensions" model that makes it straight-forward to incorporate other resources into a document, either inline or via reference.

While OWS Context was adopted by OGC in 2014, adoption by the geospatial community has been limited. However, there is no clear limitation preventing OWS Context documents from being used to share a map portrayal as long as the underlying components are able to express that portrayal fully and completely.


KML (originally Keyhole Markup Language) is now an OGC open standard ([KML]) describing an XML language focused on geographic visualization, including annotation of maps and images. While KML was a popular format when it was released by Google last decade, interest in it has waned. Its styling model, while clever for supporting level of detail, is not well-suited to high-quality digital map products. This is because it has limited styling for two-dimensional geometries. KML does not use selectors, but binds the symbol instance directly to the geometry via reference, or embedding the style directly. There is no open KML method of processing a feature when its attributes change to render a different style.


MapML ([MapML]) is a draft community specification for encoding map information for the World Wide Web. The objective of MapML is to allow Web-based user agent software (browsers and others) to interact with web servers by relying only on publicly defined Web standards (e.g., URI, HTTP, HTML), and not on URL recipes/templates, with the goal of displaying modern interactive Web maps. According to the draft specification, MapML elements should be style-able with CSS rules supplied by the MapML author. For example, the MapML author should be able to link to a stylesheet from a MapML document. However, neither the draft specification nor the Testbed 13 MapML Engineering Report ([MapMLTB13ER]) give any guidance on how this can be done.

The Testbed 13 ER also reviewed the draft MapML specification in detail and made a number of recommendations. There is no known timeline for MapML to become a standard that can be recommended to meet the needs identified in this study.

4.5.2. Digital Map Sharing

Map Layers are accessible today from specialized web services such as OGC Web Map Service (WMS), OGC Web Map Tile Services (WMTS), or ESRI ArcGIS Map service. A layer is defined as a rendering of geospatial data (raster or vector) using a given portrayal style. A layer can be rendered dynamically by using web map services and can be downloaded from a distribution (KML files, feeds) to be rendered on the client side.

By providing enough metadata description about the layers, it is possible to catalog layers and enable search and discovery of relevant layers and usage for federated composition for federated composition of layers from multiples sources to create maps. Example of metadata include layer classification (defined in controlled vocabularies), theme, function, audience, geographic extent, temporal extent, keywords, thumbnails, styles, supported formats, and APIs.

Unfortunately, most map layers published on the web have poor metadata description, making it difficult to discover relevant map layers for use in map composition. There is a need to define a set of metadata for describing geospatial map and layer. Current industry efforts are focused on describing dataset metadata (DCAT) to enable search and discovery of datasets. Similar efforts are needed for layer and map metadata.

Catalog Services

Catalog Services ([CAT]) is an OGC open standard that provides a model and protocol bindings for cataloging and discovering resources such as web services and styles. This potentially allows clients to discover these web services and styles for use in their own maps and other applications. However, while many SDIs offer catalog services, internally they tend to use their own specialized models and interfaces that are easier to integrate with their client applications.

Work developed on Testbed 12 provided findings related to the Semantic Portrayal, which extends a catalog for registering and finding styles ([SEMPORTB12ER]).


As [Bocher-Ertz] notes, the deprecated 1.0 version of the SLD Profile of WMS includes a GetStyles operation. This constitute the minimum level of capability needed to share styes that could subsequently be used for just-in-time server-side portrayal. However, the results of a GetStyles operation do not provide any context for the results so it is difficult for a user to determine which style or styles are fit for any particular purpose.

4.5.3. Map Portrayal

In this phase, digital map products are produced using existing data. The CDS Team identified a number of ways that this is done operationally, but they share the same basic workflow of portrayal rules and vector data being fed to a graphics engine, which then produces raster data.

  • The SLD Profile for WMS ([WMS-SLD]) allows a client to submit an SLD to the server as part of a GetMap request.

  • Many geospatial servers include a feature portrayal server that allows a client to define a custom map layer that includes a feature layer and a custom style.

  • Tools such as TileMill produce map tiles by applying styles to an existing vector data store.

Most vendors have developed their own graphics engines to meet their requirements. These engines are generally not based on standards like SLD or SE because those standards did not meet their requirements[1]. The general approach is to map standards like SLD and SE into the internal graphics engine. No matter what is done on the standards front, those engines are unlikely to be rewritten to map to a new model.

SLD and SE have a number of limitations that currently prevent it from being a complete portrayal solution (including lack of interoperability, extensibility, and capability see Styled Layer Descriptor and Symbology Encoding).

4.5.4. Style Collaboration

In this phase, multiple Spatial Data Infrastructure (SDI) users work together in the authoring process. This requires making styles available as sharable, updatable objects. However, there is little evidence that this phase is actually performed in most workflows. Instead, each map producer develops the styles independently using GIS, desktop publishing, or paper tools. For example, as part of the Canadian Federal Geospatial Platform, styles are developed internally by government data production shops using Esri software. These styles are only shared internally and are generally only compatible with other Esri products such as Esri REST services (see Case Study 2 - Canadian Federal GeoSpatial Platform for more information).

There were some early attempts to support standards-based style collaboration. The deprecated 1.0 version of the SLD Profile of WMS includes a PutStyles as well as a GetStyles operation. This approach did not prove to be popular. It may be a better approach to separate the management of style documents from the map service and make it available as part of the catalog solution for the same reasons listed in the previous subsection. To date, there is not a standard way of doing this, but it is being explored as part of Semantic Portrayal Registries (see next section).

4.6. Semantically-Enabled Workflow

As the two case studies will illustrate, the Conventional Workflow fails to fully meet the needs of the digital mapping community. Limitations of SLD and SE are only a part of this failing. The more serious issue is that the workflow does not scale to handle multiple sets of styling rules, portrayal engines, or data sources. This concept becomes more important when organizations have the requirement to produce competing map views using the same data (e.g., Electronic Nautical Chart (ENC) vs. Digital Nautical Chart (DNC)) or when they have to produce maps using the same styling rules on disparate data sources.

Semantically-Enabled Portrayal is a set of capabilities that are emerging to improve on each of the phases of the Conventional Workflow. The target architecture for this approach is currently being researched. The Testbed-12 Semantic Portrayal, Registry, and Mediation Engineering Report ([SEMPORTB12ER]) describes a need for the following services.

  • Semantic Registry Service, which allows discovering and search of geospatial assets (e.g., datasets, services, schemas, portrayal information, and layers). It is based on the W3C Data Catalog Vocabulary (DCAT).

  • Semantic Mediation Service, a hypermedia-driven REST API that provides the ability to perform transformation of data from one schema to another.

  • Semantic Portrayal Service, which provides the ability to render datasets to multiple output formats (e.g., SVG and PNG) and generate different styling encoding (e.g., SLD, MapCSS, and CartoCSS). It is based a set of portrayal ontologies for styles, symbols, and graphics.

In this workflow, the above services are integrated into a new workflow that is more flexible, robust, and capable.

Figure 2. Semantically-Enabled Workflow

4.6.1. Portrayal Ontologies

Current portrayal standards such as OGC SLD and SE are document-centric and are forced to adhere to an XML schema. This causes a lot of duplication of portrayal elements between documents due to the lack of globally addressable identifier mechanism. Testbed 11, 12, and 13 activities explored the use of linked data and ontologies to tackle the issue of addressability and defining common portrayal vocabularies that enable search and discovery of portrayal information. SLD documents were converted to a common linked data representation to make their content addressable. The export of SLD from this Linked Data representation was also demonstrated.

During Testbeds 11, 12, and 13, Image Matters developed a set of portrayal ontologies aligned with the OGC Semantic Registry Information Model (SRIM), OGC SLD, OGC SE standards, and SVG. The ontologies were encoded with the Web Ontology Language (OWL). The portrayal ontologies are composed of extensible modules that can be reused in different contexts. The models were used as baseline for performing semantic mediation of symbology for transnational incident representation (Testbed 11) and as the core model for Semantic Portrayal Registry and Portrayal Service using REST API with hypermedia links. In Testbed 13, a client demonstration using these services was performed to demonstrate the creation of custom styles and layers on heterogeneous data sources (WFS, GeoJSON, Shapefile).

The primary focus of the development of these ontologies was on developing a portrayal model for rendering feature data. Future extensions will be needed to describe coverage portrayal and describe useful metadata for style and layers to enable a better search and discovery experience.

4.6.2. Semantic Portrayal Registries

In this phase, a cartographer uses a catalog/registry to search and discover portrayal related artifacts such as styles, symbol sets, symbols, symbolizers, graphic elements, or rules to be used for customization of user-defined layers. Each portrayal element is addressable, so it can be referred to and linked to other entities (such as user defined layers or user-defined styles). Each portrayal element should also have enough metadata for machine and human interpretation so they can discovered easily. The indexing of addressable portrayal elements favor reusability and interoperability of portrayal information.

Early efforts in this area included the addition of a portrayal electronic business Registry Information Model (ebRIM) profile for Catalogue Services for the Web (CSW). The Defence Geospatial Information Working Group (DGIWG) advanced an approach to the Catalog use case. In 2013, an interface specification for such a catalog was published (see [DGIWG_PORT_REG]). The main part of this specification provides an interface-independent information model for a Portrayal Registry. Annex A specifies how the information model can be mapped to the CSW ebRIM registry interface. Annex B specifies a RESTful interface to the model. The basis of the this service is a service oriented interface. The registry stores rules, symbols, fonts, and sets of these artifacts based on known application schemas. The service provides discovery mechanisms for searching and retrieving these items. The information model of this profile addresses only a subset of the portrayal elements expressed by SLD and the portrayal used in Testbed 11, 12, and 13. Furthermore the use of custom user-defined query extensions prevents users from performing more advanced query search and requires upgraded ebRIM clients to support the profile. There are very few implementation of ebRIM clients today due to the complexity of the model and query language.

In response, Testbed 11, 12, and 13 portrayal activities explored the definition of a Semantic Registry Information Model (SRIM)-based Portrayal Profile to support the registration and search of portrayal information and the use of that information to support user-defined layer creation in the Semantic Portrayal Service. The generic search capability of an SRIM-based semantic registry is more suitable for use in downstream services.

4.6.3. Map and Layer Authoring

With the emergence of better search and discovery of geospatial datasets (enabled by the DCAT-related efforts and Open Data policies from governments), users want to represent these data as map or map layers to convey geospatial information to a target audience. In this phase, a cartographer composes a map or layer by applying user-defined or shared styles (discovered from a portrayal catalog, for example) to existing geospatial data (independently of its format), gets a rendering of map/layer from a portrayal service or portrayal client application, and saves the context of map/layer to a portrayal/map service.

The Testbed 13 Portrayal activity has defined a RESTful Portrayal Service that provides the ability to manage and render user-defined layers with custom styles or styles discovered from the Semantic Portrayal Registry. The Application Programming Interface (API) supports JSON-LD, Linked Data encoding, and Hypermedia Application Format (HAL). The service supports Create Read Update Delete (CRUD) operations for layers, symbolizers, and styles. It provides a rendering endpoint for layers, maps (using the WMS GetMap operation), legend, symbol, and symbolizers as raster formats. More work is needed to define the description of layer metadata useful for search and discovery, in particular by aligning it with the SRIM and DCAT standard. The REST API of the service was successfully integrated with an off-the-shelf client map viewer (Leaflet) and the rendering of user-defined styled layers from different formats (Shapefile, GeoJSON, WFS) was demonstrated. This demonstration aimed to showcase the viability of the use of linked data, its extensibility to accommodate different data models, addressability of portrayal information and integration with other sources of information (datasets and services).

Another approach uses the OGC WMS ([WMS]) standard, which allows a client to use a GetMap operation to request a map from a server based on a narrow set of criteria such as extents, CRS, layer name, and pre-defined style by name. The most recent versions of WMS provides the ability to define as user-defined layer or styles using SLD/SE encoding with data coming from WCS or WFS and having the rendering done on the server side. However, WMS specification does not provide an API to manage custom styles and layers.

4.6.4. Symbology Mediation

In Testbeds 11 and 12, the challenge of symbology mediation was addressed in the context of the Law Enforcement and Public Safety (LEAPS) domain. There are various Symbology Best Practices available for LEAPS used in the context of Emergency Management (e.g., US FGDC ANSI 415-2006 INCITS Homeland Security Map Symbol Standard, Canadian Emergency Management Symbology (EMS), etc.). Since in house-symbols are preferred, few of these best practices have been widely adopted. In the case of multi-institutional activities, the lack of a common set of symbology can be problematic. Semantic Mediation of Symbology provides a viable solution that allows the representation of an incident information using symbology of a given community to a target incident information model using symbology of another community. To address these symbology mediation challenges, a knowledge-centric approach was adopted. The knowledge-based approach employs a standards-based formal, sharable framework (RDF, OWL, SPARQL) that provides a conceptual domain model to accommodate various business needs. Among these standards, there are Resource Description Framework (RDF), RDF Schema, OWL, and SPARQL. Using these standards, a set of ontologies were developed during this testbed to represent incidents, portrayal information and semantic mediation mappings. A Semantic Mediation Service was developed in Testbed 11 and Testbed 12 to perform the transformation from one application schema to another in order to support the symbology mediation.

5. Case Study 1 - Arctic Spatial Data Infrastructure (SDI)

5.1. Description

The Arctic Council, consisting of the 8 participating National Mapping Agencies of Canada, Finland, Iceland, Norway, Russia, Sweden, USA, and Denmark (including the administrations of the Faroe Islands Home Rule and the Greenland Self-Government), sponsors the Arctic Spatial Data Infrastructure (Arctic SDI) ([ASDI-Framework]). The aim of this formal cooperation is to provide politicians, governments, policy makers, scientists, private enterprises, and citizens in the Arctic with access to geographically related arctic data, digital maps, and tools to facilitate monitoring and decision-making. The Arctic SDI has two basic requirements with regards to portrayal. The first is the background map, which they can produce with great difficulty. The second is thematic maps, which are mostly beyond their capabilities today.

5.2. Methodology

To perform this case study, the CDS team contacted Arctic SDI members and discussed their existing Arctic SDI map production workflows. While each member does things differently, common concepts emerged. From there, the team explored the possibilities for producing the desired map products. This was a critical input to the Vision and Roadmap sections of this document.

Since a new version of SLD is being developed concurrently with the development of this CDS, the CDS team reviewed the Arctic SDI Cartographic Data Model ([ASDI-Carto]) and crosswalked the model with the capabilities evident in the emerging SLD draft specification. This gave CDS members valuable information which was then provided to the SLD Standards Working Group (SWG) to ensure that the emerging standard met Arctic SDI needs.

5.3. Stakeholders

5.3.1. Producers

  • National mapping agencies

5.3.2. Clients

  • End-users from agencies and departments at all levels of government

  • Private end users

  • Arctic SDI CAFF Working Group

5.4. Use Cases

5.4.1. Background Maps

To provide a seamless background map of the entire Arctic cross borders, reference data (a least common multiple of map layers) are provided by the involved mapping organizations, covering the arctic region as defined by each organization. This data includes coastline, hydrography, road networks, topography, geographical names, and bathymetry ([ASDI-Manual]).

The process that has been used for setting up Arctic SDI services is as follows:

  1. Find the correct data - the data that best corresponds to the scale of 1:250000;

  2. Define the layers and the order of them in the WMS tool;

  3. Implement the cartography on the layers according to the Arctic SDI cartographic specification ([ASDI-Carto]);

  4. Adjust the size (width and height) depending on the specific tool used in the country; and

  5. Test and compare the service with WMS’s from neighboring countries.

Experiences from Arctic SDI are summarized below:

  • When setting up a WMS there have been two main challenges:

    • to find dataset of the same level of detail in each country - a correct set of data; and

    • the size of the objects, width and height of point, lines and symbols;

  • Different tools have different interpretations of the map size which affects the cartography;

  • All tools seems to support SLD but some tools (i.e., ArcGIS) only support it partially, which can cause issues; and

  • Performance needs to be investigated when using SLD.

SLD could be a possible solution if an SLD was created that works for each of the tools used in the Arctic Countries (MapServer, GeoServer, ArcGIS) but currently this is not done.

5.4.2. Thematic Maps

Thematic Data are spatial datasets of interest in the Arctic region, organzsed as thematic layers. Dataset providers could be governmental or interested organizations, companies, etc. These datasets and metadata could be delivered and harvested using the same service alternatives as described for the reference data. Examples of thematic data that are relevant to the Arctic SDI include:

  • Permafrost

  • Land cover

  • Treeline

  • Biodiversity

  • Tourism

  • Urban environments

  • Energy and Mining

  • Shipping routes

  • Forestry

  • Geology

  • Conservation areas

  • Ice cover

  • Weather

  • Ecologically and Biologically Significant Areas (EBSAs)

  • Local communities and local knowledge

For end users, Arctic SDI Applications provide access to discover and view the underlying datasets. Different applications with different Graphical User Interfaces (GUIs) could present the datasets in numerous ways, according to independent needs and hardware/software platform. One of the roles of the Arctic SDI is to ensure that this information is available in an interoperable way.

In the example thematic map shown in the figure below, complex styling rules are implemented with rule-overriding capabilities.