Publication Date: 2018-03-15

Approval Date: 2018-12-13

Submission Date: 2018-11-28

Reference number of this document: OGC 18-029

Reference URL for this document:

Category: Public Engineering Report

Editor: Sara Saeedi

Title: OGC Testbed-14: Symbology Engineering Report

OGC Engineering Report


Copyright (c) 2019 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, ("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 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. Summary

The portrayal and visualization of geospatial information is a critical task for facilitating decision making, situational awareness, and spatial analysis. However, despite its importance, various local, national, and international agencies continue to use different symbols and terminology for the same event, feature, or entity. This approach prevents interoperability from being extended to the semantic level, which in turn makes it difficult to share, reuse, and mediate unambiguous portrayal information between agencies.

This Engineering Report (ER) captures the requirements, solutions, models, and implementations of the Open Geospatial Consortium (OGC) Testbed-14 Portrayal thread. This effort leverages the work of the Portrayal Ontology development and the Semantic Portrayal Service conducted during Testbed 10, 11, 12 and 13. Thus far the emphasis for developing the portrayal ontologies (Testbeds 12 and 13) has been on modeling and representing portrayal information for feature data. The objective of Testbed-14 is to extend the portrayal ontology to accommodate more complex symbols (e.g., composite symbols) and to provide clear recommendations on how to best proceed with portrayal information encodings.

1.1. Requirements and Research Motivation

A detailed description of the requirements that have been addressed – alongside the fundamental questions of our motivation for addressing this topic – is documented in Chapters 5 to 9 of this ER.

1.2. Prior-After Comparison

The Styled Layer Descriptor (SLD) specification was introduced in 2001 as a part of version 1.1.0 of the Web Map Service (WMS) Implementation Specification (OGC 01-047r2). Currently available in version 1.1, the OpenGIS Styled Layer Descriptor Profile of the Web Map Service Implementation Specification was published in 2007 with the aim of extracting the symbology instructions and turning them into the dedicated Symbology Encoding standard (SE 1.1). Consequently, while the SLD profile remains closely related to the WMS service, the symbology instructions can now be used by any styling software component.

Over the past ten years, SLD and SE have not been enthusiastically adopted although they remain the underlying method for styling layers for many geospatial software products. Furthermore, visualization tools have taken symbology requirements far beyond those envisioned in 2001, not only because 2.5D (2.5-Dimensional) and 3D (3-Dimensional) data have become common, but also because these tools are available to a broader community of map makers taking over and pushing the boundaries of 2D (2-Dimensional) visualization.

The objective of Testbed-13 was to identify and complete the gaps in the latest version of the portrayal ontology defined in Testbed-12, complete the implementation of the Semantic Portrayal Service by adding rendering capabilities and perform a demonstration of the portrayal service that showcases the benefits of the proposed semantic-based approach. The Portrayal Concept Development Study (CDS) undertook the following activities: assessing the current state of feature portrayal, establishing a long-term vision for portrayal standardization and providing a roadmap for capabilities identified in the vision [1].

Testbed-14 has extended the portrayal ontology to accommodate more complex symbols (e.g., composite symbols) and provide recommendations on how to best proceed with portrayal information encodings. One motto used for Testbed-14 for portrayal was "the time for convergence" or "on the path to convergence." However, the end of the path has not been reached, whether for Testbed-14 or for the previous testbeds which only gathered the logical and relevant pieces about portrayal interoperability points being pursued which were in line with the CDS.

As planned, Testbed-14 began an assembly of many visions on various requirements from linkable portrayal information (inherited from previous testbeds) to multiple-pass rendering symbolizer composition. Visions, requirements, expectations and experiences came from work done in previous testbeds, in the SLD/SE Standards Working Group (SWG) and from existing encoding formats used by geospatial cloud platforms and server solutions.

1.3. Recommendations for Future Work

With the experience gained, and analysis of existing encoding formats, the Testbed-14 team was able to extract useful lessons for improving the portrayal conceptual model, mainly as a set of ontologies and micro-theories that had already been built by previous testbeds. Nonetheless, this is just a start. For example, considering CartoCSS or GeoCSS opens up so many possible and relevant visual properties that another iteration is required to refine the details of each implementation (e.g., labeling properties to control deconfliction and optimize label rendering). Some of these issues are effectively part of a basic profile, while others are part of specific profiles.

Furthermore, supporting multiple community symbology use cases using the same data encodings is required for both military and non-military responders to the same incident or event. It is recommended in the way forward that a feature be added to the Portrayal Registry construct that enables a federation of sharing or getting styles and support for a React (JavaScript library) framework.

More importantly, some key issues are highlighted for consideration for the general Open OGC roadmap for portrayal. There are two possible directions it can take:

  1. Using the rich material from all these testbeds and stabilizing the conceptual work with a default encoding for a core (please refer to OGC 18-067) and a basic profile for 2D vectors (or even a super simple profile as discussed in this testbed). Perhaps this may be internal work that can be carried out by a SWG or finalizing work (which expects the specification of standards) for a future testbed.

  2. Preventing the internal standardization work within the current working groups and continuing with more testbeds according to the future deliverables. Before returning to the standardization work that is focusing on the definition or consolidation of the conceptual model, exploration of raster and 3D (Augmented Reality, etc.) could be very useful for an extensible core standard.

Moreover, there is a requirement to support the usage of multiple symbology sets against the same data encoding. The recommended use case for a future testbed would be along the lines of Counter-IED (improvised explosive devices) event where both military and non-military responders are responding to the same incident. In this case, military responders would use Mil-Std-2525 or Allied Procedural Publication 6 (APP-6) whereas civilian first responders would use a symbology set such as ANSI 451.

The following tasks can be considered for the future work:

Conceptual model, abstract specification, ontology

There is a requirement to define the "conceptual model" term for clarity with regards to the use of the term for future testbeds, use cases, and standards documents about portrayal. Note that some recent OGC discussions relating to the definition of a conceptual model slip into specific details about implementation. For other OGC documents, conceptual models are an abstraction (used to represent abstract ideas). There are some examples of a conceptual model as an abstraction with no specified implementation details or encoding formats, such as Simple Features Architecture, GeoSciML (Geoscience Markup Language), and OWS (OGC Web Services) Context. There may also be confusion regarding the relationship of "conceptual model" and OGC "abstract specs." See the tentative definition in the Terms and definitions section of this ER and the note in Chapter 5 that also discusses the ontological approach.

There can also be further discussions as to whether a core conceptual model is required to define symbology and other extensions to it. However, without a conceptual model, there will be no agreement on semantics (terms and definitions). A conceptual model is helpful for the following tasks:

  • Facilitating collaboration between all team members;

  • Helping to update, change, and reuse the model easily;

  • Representing the abstract concepts and explaining basic entities and their relationships using both visual and written forms of diagrams;

  • Defining relevant terms; and

  • Minimizing the likelihood of incomplete, unclear, inconsistent, and wrong scopes, requirements, and validation.

From modular specifications to best practices

The idea may arise that portrayal standards stemming from the current process might lead to complex tools and concepts only for specialized users. This point is especially valid when comparing the OGC approach with current geospatial cloud platforms or web server solutions. These are often implementations which do not refer to anything else apart from the usual business needs from the "web mapping market." However, remember that the targeted audiences for OGC portrayal standards are Information Technology (IT) teams in charge of the implementations that require interoperable portrayal systems and the indirect final users whose lives are made easier by interoperable features between the systems deployed on the market. This case is very similar to the original Web Mapping use case that led to the development of the OGC WMS standard, which has been adopted by the International Organization for Standardization (ISO) as ISO 19128:2005. Even if implementations hide the underlying complexity from the final users, it is important to favor the adoption of these portrayal standards by the IT strategist and developer teams. In other words, it should also make their lives easier. Modularity may help to favor such an adoption. If modularity is not an essential requirement for the above platforms and solutions, it is for the design of standards if their widespread adoption is desired and also to address interoperability requirements.

With modularity in mind, the following tasks are anticipated for the relevant SWGs to discuss and define portrayal standards:

  • First, the currently defined core that has gone to public comment (Symbology Conceptual Core Model: OGC 18-067) must be evaluated in terms of the Testbed-13/14 findings and recommendations.

  • Then, using that core, define extensions that provide additional details using the main extension principles proposed in OGC 18-067 (also notice the Testbed-14 reverse engineering section (Lessons from CARTO and Mapbox underlying encoding formats) which is a methodological attempt to extract some natural extensions from the underlying model of Cartographic Cascading Style Sheets (CartoCSS); it should be continued).

  • Next, these extensions have to be documented in relation to requirement classes and requirement identification (as defined in the OGC modular spec OGC 08-131r3) and illustrated in OGC 18-067 appendix.

  • Finally, provided that the three previous points have been reached, the conceptual definition of the various profiles and/or extensions can be documented accordingly.

Moreover, we may notice that Field [2] points out that the current demand from internet users (not in the discipline of cartography) is for quantity, not quality, of symbology. To counteract this situation or evolution, and to favor the adoption of OGC portrayal standards to be considered standards of reference for the market, best practices (BPs) should support those portrayal standards. These BPs can highlight the importance of cartographic design and its relationship with portrayal standards. That is in the OGC defined best practices documents containing a discussion of best practices related to the use and/or implementation of an adopted OGC document for release to the public.

Rendering sequence and ordering considerations

Ordering (also called Z-order) is a sorting capability of overlapping graphics, such as polygons or lines in a vector dataset. For example, as it is mentioned in chapter 9, Mapnik uses the painter’s algorithm when drawing objects, meaning that items are drawn from bottom to top, with items defined earlier in the source layer list being drawn first. Consequently, stylesheet developers should consider what features should appear over other features, such as roads over land uses, points of interest over buildings, and so on.

There are more complex situations, such as "spaghetti" road junctions, where multiple highways may intersect other multiple highways. A map should accurately portray the vertical topology of overlapping roads. This topic needs to be further developed concerning the following issues:

  • To what extent ordering considerations (and abilities) have to be included in the basic profile, given that the elaboration of an OpenStreetMap (OSM) style is highly dependent on such abilities, but is not presumably the basic use case (instead, some of these abilities are part of an advanced profile).

  • The ability to sort features in the same layer by their vertical topology requires the attributes that define a feature’s "relative" or "absolute" vertical position in the source data. More descriptions on the relative or absolute vertical position are discussed in chapter 9.

Default values

Default values remain a topic that needs future work, as raised in the section Default values and color definition in Chapter 5, which also relates to the definition of a first and default encoding.

Raster symbology requirements

Testbed-13 recommended work on raster symbology. Based on those discussions, Testbed-14 suggests a new generation of "Symbology Encoding" for raster. This is in part because the Symbology Encoding Implementation Specification 1.1.0 discussed both 2D vectors and also raster. Accordingly, the next step would be to evaluate the raster abilities of the conceptual model which would be CoverageStyle with a specific symbolizer, according to a clear definition of the related raster data model(s) for future testbeds.

3D symbology requirements

Another future direction is to keep the testbed work oriented towards vectors (2D or 3D); in other words, future testbeds can be dedicated to symbology for 3D requirements. Confronting the conceptual model with the 3D use case is essential for identifying 3D requirements and other specific extensions. Being clear about the idea of "confrontation" will challenge the initial global structure and its extensibility.

From a reference encoding to translators

Testbed-14’s effort in writing an encoding specification document that is compliant with the conceptual specification document can be extended to including a reference encoding of the conceptual model. Following this, a couple of translators or encoders from an implementation (Mapbox, CartoCSS, Geoserver, SLD/SE, etc.) can be created for that reference encoding.

Based on the results and discussions made for Testbed-14, the following deliverables are suggested for deployment for testing and demonstrating the above functionalities and for documenting the results.

  • Default reference encoding format specification for the vector 2D basic profile (based on propositions from Testbed-14).

  • Extending the conceptual model with the idea of reusable "symbolizer templates" (in relation to the ParametrizedSymbolizer of OGC 09-016 and considering sharing principles from Testbed-13).

  • Defining raster symbology abilities as extensions (and package for one or more dedicated profiles).

  • Defining 3D symbology abilities as extensions (and package for one or more dedicated profiles).

  • Rendering engine compliant with the default reference encoding format (with the expectation that it is compliant with a finalized conceptual model).

  • Controlling the rendering engine with a map-building user interface.

1.4. Document Contributor Contact Points

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


Name Organization

Sara Saeedi (Editor and Contributor)

University of Calgary

Olivier Ertz

Media Engineering Institute, HES-SO // University of Applied Sciences Western Switzerland

Thibaud Chassin

Territorial Engineering Institute, HES-SO // University of Applied Sciences Western Switzerland

Stefano Bovio

GeoSolutions S.A.S.

Simone Giannecchini

GeoSolutions S.A.S.

Andrea Aime

GeoSolutions S.A.S.

Gate Jantaraweragul

ImageMatters LLC

Jeff Yutzler

ImageMatters LLC

Jérôme St-Louis


James Badger

University of Calgary

Soroush Ojagh

University of Calgary

Steve Liang

University of Calgary

Carl Reed

Carl Reed and Associates

Greg Buehler


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


    CARTO is a Software as a Service cloud computing platform that provides GIS and web mapping tools for display in a web browser.
  • CartoCSS

    It is an open-source Mapnik stylesheet which is similar to Cascading Style Sheets (CSS) syntax inspired by Cascadenik and developed by MapBox to render static maps.
    The reference parser is written in JavaScript and optimized for large stylesheets.
  • Conceptual Model (CM)

    ISO defines a "conceptual model" as "a model that defines concepts of a universe of discourse" in[ISO 19101].
    In the field of computer science, CM is a particular case of a general conceptual model which is also called a domain model.
    In this ER, CM is an abstract model to represent the abstract concepts, relevant term, basic entities, their behavior (or attributes) and their relationships used by domain experts.
    A CM is explicitly chosen to be independent of a specific design, encoding or implementation concerns.
  • Feature

    Representation of some real-world object or phenomenon, _e.g._ a building, a river, or a person.
    A feature may or may not have geometric aspects.
  • GeoDataBase

    A geodatabase is an Esri spatial data format to store GIS information in one large file,
    which can contain multiple points, polygon, and/or polyline layers.
    It is an organization of multiple shapefiles in multiple folders.
  • GeoJSON

    GeoJSON is an open standard format designed for representing simple geographical
    features, along with their non-spatial attributes. It is based on JSON, the JavaScript
    Object Notation. The features include points, line strings, polygons, and multi-part collections of these types (source:
  • GeoServer

    It is an open-source server written in Java that allows users to share, process and edit geospatial data.
    It publishes any major spatial data source using open standards and renders hundreds to thousands of vector/raster map layers (source:
  • Interoperability

    The capability to communicate, execute programs, or transfer data among various
    functional units in a manner that requires the user to have little or no knowledge
    of the unique characteristics of those units (source:[ISO 19119]).
  • HTML Canvas

    The canvas element is part of HTML5 and allows for dynamic, scriptable rendering of 2D shapes and bitmap images.
    It is a raster-based, low-level, procedural model that updates a bitmap in a browser.
  • Layer

    The basic unit of geographic information that may be requested as a map from a server.
  • Map

    A pictorial representation of geographic data.
  • Mapbox

    An open-source mapping platform for custom designed maps. The technology is based on Node.js, Mapnik, GDAL, and Leaflet.
  • Mapbox GL

    Mapbox GL is a suite of open-source libraries for embedding highly customizable and responsive client-side maps in Web, mobile, and desktop applications (
  • MapCSS

    MapCSS is a CSS-like language for map stylesheets. MapCSS is used to define stylesheets for map rendering in the[OpenStreetMap] project.
  • Mapnik

    Mapnik is an open source mapping toolkit for desktop- and server-based map rendering, written in C++. It supports a variety of geospatial data formats and provides flexible styling options for designing many different kinds of maps.
  • Model

    Abstraction of some aspects of a universe of discourse[ISO 19109].
  • Ontology

    A formal specification of concrete or abstract things, and the relationships among them, in a prescribed domain of knowledge[ISO/IEC 19763].
  • Portrayal

    Portrayal presentation of information to humans[ISO 19117].
  • Semantic interoperability

    The aspect of interoperability that assures that the content is understood in the same way in both systems, including by those humans interacting with the systems in a given context.
  • Shapefile

    A Shapefile is an Esri vector data storage format for storing the location, shape, and attributes of geographic features. It is stored as a set of related files and contains one feature class.
  • Style

    Determines the appearance of geographic data
  • SVG

    Scalable Vector Graphics (SVG) is an XML-based vector image format for two-dimensional graphics with support for interactivity and animation. The SVG specification is an open standard developed by the World Wide Web Consortium (W3C) since 1999.
  • SVG Tiny 1.2

    The Tiny profile of SVG 1.2 consists of all of the features defined within this specification which is widely adopted in the cellphones industry.
  • Symbol

    A bitmap or vector image that is used to indicate an object or a particular property on a map.
  • Symbolizer

    It defines the visual representation of geographic objects.
  • Symbology Encoding

    It specifies the format of a map-styling language that can be applied to digital feature and coverage data to produce geo-referenced maps with user-defined styling.
  • Z-order

    'Z-order' is an ordering of overlapping two-dimensional objects, such as windows
    in a stacking window manager, shapes in a vector graphics editor, or objects in a 3D application (source: Foley et al. (1987)).

3.1. 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.
  • 2D 2-Dimensional

  • 2.5D 2.5-Dimensional

  • 3D 3-Dimensional

  • AGC Army Geospatial Center

  • API Application Program Interface

  • BLOB Binary Large OBject

  • CartoCSS Cartographic Cascading Style Sheets

  • CDS Concept Development Study

  • CMSS Cascading Map Style Sheets

  • CRS Coordinate Reference System

  • CSS Cascading Style Sheets

  • DISA Defense Information Systems Agency

  • EPSG European Petroleum Survey Group

  • Esri Environmental Systems Research Institute

  • FGDC Federal Geographic Data Committee

  • FME Feature Manipulation Engine

  • GeoJSON Geospatial JavaScript Object Notation

  • GeoSciML Geoscience Markup Language

  • GIS Geographic Information System

  • GL Graphic Library

  • GML Geography Markup Language

  • IGN Institut National de l’information geographique et forestiere

  • IT Information Technology

  • JSON JavaScript Object Notation

  • MIL-STD-2525 Military Standard 2525

  • NAPSG National Alliance for Public Safety GIS

  • NAS NSG Application Schema

  • NGA National Geospatial-Intelligence Agency

  • NSG National System for Geospatial Intelligence

  • OGC Open Geospatial Consortium

  • OSM Open Street Map

  • OWL Ontology Web Language

  • OWS OGC Web Services

  • PNG Portable Network Graphics

  • POI Points of Interest

  • QGIS Quantum Geographic Information System

  • RDF Resource Description Framework

  • SDP Spatial Data Pilot

  • SE Symbology Encoding

  • SIDC Symbol Identification Codes

  • SLD Style Layer Descriptor

  • SPARQL SPARQL Protocol and RDF Query URI Uniform Resource Identifier

  • SQL Structured Query Language

  • SVG Scalable Vector Graphics

  • SWG Standard Working Group

  • TIE Technology Integration Experiment

  • TDS Topographic Data Store

  • URI Unique Resource Identifier

  • URL Uniform Resource Locator

  • W3C World Wide Web Consortium

  • WKT Well Known Text

  • WMS Web Map Service

  • WMTS Web Map Tile Service

  • XML eXtensible Markup Language

4. Overview

This Engineering Report (ER) discusses the following sections:

Section 5 introduces the background on "D160 Portrayal Ontology" and extends the portrayal ontology developed in previous testbeds and describes it as a "Portrayal Conceptual Model" to represent a common reference to drive the implementations.

Section 6 describes the demonstration scenarios, technology integration experiments, datasets, guidelines and requirements set by the sponsors.

Section 7 presents the solution developed in this testbed to address "D163 WMTS with Portrayal Support" and implements a Web Map Tile Service (WMTS) instance based on the portrayal conceptual model. In this section, SLD and Cascading Style Sheets (CSS) encodings have been used for styling vector data, and GeoServer has been used for rendering.

Section 8 analyses two other encoding formats for styling vector data and rendering them with two platforms based on free and open source solutions: CARTO online builder (CartoCSS code generator) and Mapbox studio (data oriented with JavaScript Object Notation (JSON) filtering).

Section 9 presents the solution developed in this testbed to address "D162 WMS with Portrayal Support" and implements a WMS instance based on the portrayal conceptual model. In this section, the CartoCSS encoding has been used for styling vector data and Mapnik has been used for rendering.

Section 10 summarizes the findings, design approaches, and workflows used for "D161 GeoPackage with Portrayal Support" to implement and support the GeoPackage feature portrayal on mobile devices.

Section 11 provides a summary of the main findings and discusses links to forward-looking recommendations.

The following figure (Figure 1) describes the portrayal work items executed in Testbed-14 and how they are mapped to the ER sections.

Figure4 1
Figure 1. Testbed-14 portrayal thread work items

"Appendix A" presents the portrayal conceptual model expression constructs: Primary Expressions, Identifiers, Operators and Functions which are referred to in Section 5 of this ER.

"Appendix B" provides code snippets that illustrate the encoding of the conceptual styling model as a GNOSIS CMSS (Cascading Map Style Sheets) file which is described in Section 5 of this ER and shall help to implement similar technology.

"Appendix C" and "Appendix D" provide style encodings in GeoCSS and CartoCSS that illustrates the demonstration scenario. These style encodings are described in Section 7 and 9 of this ER and will help to implement similar encoding languages.

"Appendix E" shows the GeoPackage JSON-based Style Encoding for the styles derived from the source encoding that illustrates the demo scenario. This style encoding is described in Section 10 of this ER.

5. Portrayal Conceptual Model

This section summarizes the findings, design approaches and changes in work item D160 related to portrayal ontologies.

5.1. Background

The formalization of portrayal ontologies started in OGC Testbed-10, where the focus was on representing point-based symbologies related to Disaster and Emergency Management. The initial implementation of the Semantic Portrayal Service during the OGC Testbed-11 focused on defining styles, portrayal rules, point-based symbols and graphics to enable a Web Processing Service (WPS) to produce an SLD document [3, 4]. The initial ontology was heavily based on the ISO 19117, Geographic Information - Portrayal standard.

However, the results from the implementation of the style renderers and graphic ontology development during Testbed 12 proved that ISO 19117 was mostly designed for runtime implementation (for example, use of a portrayal function) rather than for a declarative approach. It was concluded that the OGC 05-077r4, OpenGIS Symbology Encoding Implementation Specification (SE 1.1) standard provides a declarative approach based on eXtensible Markup Language (XML) encoding that is better aligned with modern Application Program Interface (API) renderers (Java Canvas, HTML Canvas, Scalable Vector Graphics (SVG), MapCSS, Environmental Systems Research Institute (Esri) Map Renderer, etc.). An update of the portrayal ontologies was then done by introducing a symbolizer microtheory aligned with SE 1.1 and graphic ontology based on SVG constructs. The scope of the portrayal ontologies was limited to vector feature-based representation.

In Testbed-13, the gap between the current portrayal standards (SLD and SE) and the portrayal ontologies developed during Testbed-12 was only identified in the vector data. For this analysis, a round trip conversion from these standards to Linked Data Representation and vice versa was conducted to show that portrayal ontologies were at least as expressive and able to support rendering tasks.

This chapter raises new findings and recommendations that are especially useful for the OGC SLD/SE SWG to complement the material on Portrayal Ontology provided by Testbed-13 that targeted the Geosemantics DWG. The focus of Testbed-13 on the subject was on the ability to "share, reuse and mediate unambiguous portrayal information between agencies". The goal then was to make the portrayal ontologies being developed during Testbed 12 as expressive as the current portrayal standards (especially Symbology Encoding, aka SE) and to test its application to Linked Data representation. Therefore, concern for identification was key, allowing for referenceable global unique identifiers to represent the different portrayal information, and making it easier to reuse and link to other artifacts expressed in the other portrayal documents.

Thus, we understand that the motivation of Testbed-13 participants for using "ontology technologies" ( e.g., OWL (Ontology Web Language) and RDF) is related to the strong need to "share information on the web" (according to Colin Atkinson, Models versus Ontologies - What is the Difference and where does it Matter?). In contrast, the work for Testbed-14 is dedicated to extending the portrayal conceptual framework and favors the use of "modeling technologies" based on the Unified Modeling Language (UML) for an intuitive and expressive graphical notation of a conceptual styling model. It is relevant because it better reveals some considerations related to rendering aspects – especially when it is about the composition of symbolizers, rendering order and the important requirement to visualize the same cartographic image from one rendering system to another. This does not mean that the formal semantic model (ontology), the set of classes and properties, and the diagrams and tables of Testbed-13 are no longer valid. On the contrary, Testbed-14 takes a simplified view of the Testbed-13 materials in order to better focus on its goals. For instance, SymbolSet or PortrayalRuleList (among others) continue to be important for the purpose of sharing information with referenceable global unique identifiers but become less important for (re)focusing on for Testbed-14.

On a side note, ontology technologies used in Testbed-13 come with a default encoding, which whilst nice to have, must be put into perspective with the idea of "one conceptual model/many encodings" that might require an "encoding neutral" conceptual framework. It is up to the related SWGs to decide whether to use the "ontology technologies" developed by previous testbeds that would be beneficial for their ability to "share, reuse and mediate unambiguous portrayal information between agencies". Behind the scenes, the hypothesis for Testbed-14 is as follows:

  • given a styling document X encoded in conformance with the conceptual model, and the related rendering engine producing map X;

  • given a styling document Y encoded in conformance with conceptual model, and the related rendering engine producing map Y;

  • then, map X is "very similar" to map Y with a narrow preservation of the cartographic message.

A conceptual model in the field of computer science is a special case of a general conceptual model. To distinguish from other types of models, it is also known as a domain model. Conceptual modeling should not be confused with other modeling disciplines such as data modeling, logical modeling and physical modeling. The conceptual model is explicitly chosen to be independent of design or implementation concerns, for example, concurrency or data storage. The aim of a conceptual model is to express the meaning of terms and concepts used by domain experts to discuss the problem, and to find the correct relationships between different concepts. The conceptual model attempts to clarify the meaning of various, usually ambiguous terms, and ensure that problems with different interpretations of the terms and concepts cannot occur. Such differing interpretations could easily cause confusion among stakeholders, especially those responsible for designing and implementing a solution, where the conceptual model provides a key artifact of business understanding and clarity. Once the domain concepts have been modeled, the model becomes a stable basis for subsequent development of applications in the domain. The concepts of the conceptual model can be mapped into physical design or implementation constructs using either manual or automated code generation approaches.

As a consequence, in line with the above note, the goals described in the following are about a portrayal conceptual model with the idea that it be mapped into implementation constructs that are here encoding formats.

5.2. Goals on Portrayal Conceptual Model for Testbed-14

The goals for the work on Testbed-14 D160 reflect common portrayal conceptual framework concerns:

  • Update the conceptual model taking into consideration lessons learned from existing; rendering engine implementations and encoding formats such as, CARTO CartoCSS, GeoServer GeoCSS, MapBox GL (Graphic Library) Style, and GNOSIS CMSS;

  • Emphasize expressiveness of the conceptual model in relation to symbol composition;

  • Make recommendations for developing the ideas of (1) one conceptual model, many encoding formats; (2) core/extensions organization; and (3) basic profile definition.

As Testbed-14 is an extension of Testbed-13, both share top-level elements, namely, a declarative approach for the continuation of Symbology Encoding (SE) and the scope limited to vector based (feature-based) representation.

The intent was also to explore the idea of reusable "symbolizer templates" in relation to past ideas such as the ParametrizedSymbolizer of OGC 09-016. Due to time constraints, this ER is unable to delve deeper into this subject except to point out that the implementations studied do not show any obvious progress in this direction.

Chapter 8, which brings some lessons from CARTO and Mapbox Style underlying encoding formats, and CMSS encoding format appendix of this ER provide some details to support the below findings and recommendations.

5.3. About the Symbolizer Concept

SE 1.1 has a symbolizer to describe how a feature appears on a map and Testbed12 has introduced a symbolizer microtheory as well. Previously Testbed-11 was only able to control point-based symbols and graphics. CartoCSS also uses the term "Symbolizer", but it carries a different meaning.

SE defines four symbolizers (for vector-based features) which are: Line, Polygon, Point and Text. The PolygonSymbolizer describes how a polygon geometry type feature appears on a map, based on styling parameters to both stroke the polygon outline AND fill it. Whereas the CartoCSS Polygon Symbolizer only allows control over filling the polygon, there is a Line symbolizer for controlling the outline of the polygon, and thus by extension everything with a linear part in its geometry to be drawn. This is applicable also for line type geometry.

Following the CartoCSS approach:

  • The Polygon symbolizer is used to Fill the area part of a geometric shape, specifically the interior of a polygon;

  • The Line symbolizer is used to Stroke the linear part of a geometric shape, which is the outline of a polygon or a line;

  • The Point and Marker symbolizers are for marking a point geometric shape which may result from the transformation of a polygon or line into a point (e.g., centroid or vertices);

  • The Text symbolizer is for labeling point geometric shapes which may result from a similar transformation.

Therefore, the Testbed-14 conceptual styling model offers four categories of symbolizers, to Fill, Stroke, Mark and Label. The model defines the four classes as abstract concepts representing points of extension to define concrete ways to Fill, Stroke, Mark and Label.

An interesting point to note is that OGC 09-016, OWS-6 Symbology Encoding (SE) Changes ER suggested renaming PolygonSymbolizer to AreaSymbolizer, probably with the idea in mind of dedicating it to control how to fill the area of a geometric shape. However, the OGC 09-016 did not elaborate on the idea (i.e., the AreaSymbolizer still described how to stroke AND how to fill).

Also, a symbolizer may or may not apply depending on the geometric type, so it is up to the standard to specify the default behavior for applying each type of symbolizer to each type of geometric shape. For example, "What happens when a Fill symbolizer is applied to a point geometric shape?", or "What happens when a Mark symbolizer is applied to a multipoint geometric shape?"

Our recommendation is to disable any default behavior for the application of a Fill symbolizer for line or point geometric types, and to do the same with a Stroke symbolizer for point geometric types.
The Text symbolizer is the only symbolizer that can move the top label to avoid overlapping, whereas the Marker symbolizer always shows a marker at the exact visualization point, and may thus hide, but not move, the marker when overlapping occurs.

5.4. A Symbolizer to Compose

Testbed-13 introduced the concept of the CompositeSymbolizer which is especially, but not only, useful when a geometric shape has to be drawn multiple times with the same symbolizers (e.g., marking a point geometry twice). Given the multiple cardinality from Rule to Symbolizer, having some styling parameters of the same type of symbolizer multiple times in a Rule does not mean drawing multiple times. Rather, the overriding mechanism happens in such instances (see next section). Thus, a symbolizer to control the rendering of a composition is required to finely control the drawing of composite symbols. The model conceptually reveals the importance of the ordering of the components of the composition. Also, each component has a name and pass type to define its membership for a particular symbolizer. The default type is a simple pass which means a composition case in which each feature is drawn multiple times in the same layer’s rendering pass.

As an example of encoding using CartoCSS, a simple pass composition with two mark symbolizers is presented:

  • Each styling parameter is prefixed with a symbolizer name to define its membership in a particular symbolizer (using the separator slash);

  • The natural sequence of instructions defines the order of rendering (from top to bottom; with marksymbolizer1 first, then marksymbolizer2)

#station {
  marksymbolizer1/marker-width: 40;
  marksymbolizer1/marker-type: ellipse;
  marksymbolizer1/marker-fill: #000000;
  marksymbolizer1/marker-allow-overlap: true;

  marksymbolizer2/marker-width: 30;
  marksymbolizer2/marker-type: arrow;
  marksymbolizer2/marker-fill: #FFFFFF;
  marksymbolizer2/marker-allow-overlap: true;
  marksymbolizer2/marker-transform: rotate(-45);

The second pass type is said to be a multiple-pass, which refers to a composition case in which each layer is drawn multiple times in separate rendering passes.


This ability is quite common in cartography software:

  • CartoCSS introduces it;

  • GeoServer GeoCSS uses a z-index property, which maps back to multiple SE 1.1 -FeatureTypeStyle, each one painted as a separate rendering pass;

  • It is also found in QGIS (Quantum Geographic Information System) under the name "symbol levels".

As an example of encoding using CartoCSS, a multiple-pass composition with three stroke symbolizers (old symbology of the French Institut National de linformation geographique et forestiere (IGN) "irregularly maintained narrow road") is presented:

  • Each symbolizer has a prefix name starting with a double colon to identify the group of styling parameters affected by a new pass symbolizer (in CartoCSS, the separator slash stands for simple pass compositions, whilst the double colon stands for multiple-pass compositions);

  • The natural sequence of instructions defines the order of rendering – from top to bottom, with a pass for strokeleft first, followed by a pass for strokerightdash, before finally a pass for strokemiddle.

#ignroads {
  ::strokeleft {
    line-color: #000000;
    line-width: 2;
    line-offset: -5;

  ::strokerightdash {
    line-color: #000000;
    line-width: 2;
    line-dasharray: 15,10;
    line-offset: 5;

  ::strokemiddle {
    line-color: #FFFFFF;
    line-width: 10;

Note that a style has a default rendering pass applying all the defined rules according to the rule interpretation algorithm. Thus, each insertion of a multiple-pass composition into a rule allows control over other extra relevant passes. As illustrated by the above example, multiple-pass composition is especially useful for drawing connected roads (also called casing, or roads with a border).

Note that the line casing use case, for example, could be considered on its own for its specific purpose (with properties specific to casing for the PenStroke). The rationale to define line casing specifically without resorting to multiple passes is two-fold. First, in hardware accelerated real-time visualization clients, passes can be very costly, and specific use cases can benefit from such a "fast-track" symbolizer, which do not require the level of flexibility that can only be defined through multiple passes. Secondly, there is a conceptual advantage to having the model correspond more directly to how someone thinks about the style being described, in terms of expressiveness, ease of making modifications, facilitation of conversion between encodings, but sometimes it can also facilitate the renderer’s task to produce the desired result. For line casing in particular, the actual width of the casing is what is specified, as opposed to specifying a width larger than the inner line in order to get the desired thickness for the casing. This also enables specifying the casing in pixel sizes, while the size of the line itself is specified in real-world units. This in turn enables better visual in 3D views where the ratio between pixels and real-world distance varies considerably.

Certain situations may require these symbolizers intended for a specific purpose, either for performance reasons or when it becomes too complex to compose a specific symbol (e.g., Military Standard 2525 for military map symbols or windbarbs for meteorologists). Cascadenik (Cascadenik implements cascading stylesheets for Mapnik) does the casing by extending its stroke symbolizer with outline parameters (see The same applies to specific parameters for adding a center line ( Nevertheless, according to Tom MacWright, Cascadenik now supports multiple-pass drawings, which are called attachments (see

5.5. About the Importance of Ordering

The model reveals some ordering constraints that have an impact on the final visual aspect of the symbols:

  • Style → Rule is {ordered}

A Style is built on a list of styling rules. The order of the rules matters in relation to the overriding mechanism, i.e., the order in which visual properties are being applied, so that if the same visual property is defined again from a rule later in the list, it is overridden by the new value. This means that repeating a rule with different values for the same visual properties does not result in different things being rendered the second time round.

With an example of encoding using CartoCSS considering both situations #1 and #2, when both rules with a rule condition have the same specificity, a feature that falls into both of these rule conditions does not look like the same thing.

Situation #1
#layer {

#layer[name = 'highway'] {
  line-dasharray: 10,5;

#layer[num = 10] {
  line-width: 1;
Situation #2
#layer {

#layer[num = 10] {
  line-width: 1;

#layer[name = 'highway'] {
  line-dasharray: 10,5;

Notice that this also applies to the Testbed-13 PortrayalRuleList concept as it is a list with a certain order.

  • Symbol → Symbolizer is {ordered}

Generally, CSS adds styles to a document model, whereas for maps, we tend to use the painter’s model which gives importance to ordering. This affects how ordering in the language works. Indeed, from the example of encoding with CartoCSS, both rules below do not produce the same results (in other words, fill + stroke <> stroke + fill):

#layer {
  line-width: 6;
  polygon-fill: #aec;
  polygon-opacity: 0.8;

#layer {
  polygon-fill: #aec;
  polygon-opacity: 0.8;
  line-width: 6;

Note that we may also use the SVG paint order (see by defining normal behavior with the fill painted first, then the stroke, then the markers with the labels always on top (even having their own rendering pass). Specific parameters would then be required to specify a different paint order.

  • Compose → Symbolizer is {ordered}

When doing composition, the order is obviously important, with the rendering pass being simple or multiple. Using opacity to simulate the visibility of a component behind the scene is not a feasible option. Instead, we can play with the ordering. In the above #station example, the marksymbolizer1 is drawn before marksymbolizer2, with the intent of having the first one in background.

5.5.1. Future Work on Ordering

GeoServer also recognizes another kind of ordering issue called the sortBy Z-ordering (see This has an impact on the ordering of the flow of features coming from the layer to visualize. The idea of such parameters for a rule is similar to the ORDER BY part of an Structured Query Language (SQL) query. Such an ability is relevant for different use cases:

  • The OpenStreetMap dataset extensively uses a Z_order attribute to model the above/below relationships between elements in the real world;

  • In thematic mapping, when proportional symbol representation is used, e.g., on a population attribute, features may need to be sorted by the specific attribute controlling the variation of the symbol size (avoiding the problem of bigger symbols hiding smaller ones).

QGIS introduces a layer rendering ability called "Control feature rendering order". CARTO with CartoCSS goes further, allowing for control through an explicit preliminary step of using a complete SQL query to select the features to render, before reordering them. The OSM Carto Editing Guidelines ( clearly show the complexity of this preliminary step for preparation of the geodata flow.

The following questions needs to be answered:

  • How desirable is it to have abilities in the cartographic language itself to control the ordering?

  • Is it a separate responsibility not belonging to the styling conceptual model?

Due to time constraints, these types of ordering issues will require further investigations in future work.

5.6. Rule Interpretation with Cascading

Given the popularity, power and simplicity of the World Wide Web Consortium (W3C) Cascading Style Sheets (CSS) as a language for adding style (e.g., fonts, colors, and spacing) to Web documents, it is worth considering some of the underlying CSS concepts for inspiring a language for the presentation of geospatial data. Specifically, the fundamental concept of cascading that is used by CartoCSS and Mapbox styles as well as GL Style, GeoCSS, and Cascadenik. Cascading may actually reduce the number of rules for complex styles such as the "Circumpolar Thermokarst Landscape" from the Arctic SDP (Spatial Data Pilot) project (see

Currently, SE 1.1 interprets multiple rules for rendering features multiple times. The idea of cascading is different, rather than overriding one rule over another. The cascading focuses on how something should be styled and refers to an algorithm finding the styling parameters to apply for each feature (from

  • By locating all the rules with rule conditions matching the current feature;

  • Sorting them by specificity (e.g., number of attributes in a rule condition), from less specific to more specific;

  • Having more specific rules that add to and override styling parameters with less specific rules.

Finally, depending on the feature attributes, a specific rendering rule is built for the feature which mixes all the applicable rules. By setting the common bits with less specific rules, and overriding them by specifying the exceptions to the norm with more specific rules, the core of the algorithm allows for the preparation of succinct style sheets for otherwise very complex rule sets.

Consequently, rather than the SE 1.1 ElseFilter concept, one can simply have a first Rule without any Filter. Note that the overriding follows the composition prefixes.

Lastly, cascading for maps is often associated with nesting for better cartographic code structuring. However, we suggest that this ability not be part of the conceptual view, but instead be a responsibility of the encoding. As an example using CartoCSS, this encoding with nesting is similar to the above situation #1.

#layer {

  [name = 'highway'] {
,line-dasharray: 10,5;

  [num = 10] {
  ,line-width: 1;

Hence, one could think that cascading has only benefits and that cascading is the core of rule interpretation. Nonetheless, we may moderate such a radical position. Indeed, having cascading at the core could lead to a concept difficult to understand:

We may add the fact that automatic legend generation then becomes complex, as all possible cases must be generated, and some might not be relevant to the cartography at hand. Also, it is difficult to control order of symbol appearance in the legend (probably the reason why separate tooling to do legends are used in some setups).

Therefore, we may find it instead easier to have a simplified version of CSS with no cascading, but with eventual rule nesting for expressing localized overrides (Cascadenik like, also implemented by GeoCSS). Such interesting contributions in terms of formatting may solve most of the above issues.

As a consequence, while cascading is powerful, its usage is probably best left as an option for the cartographer to choose from- or provide a way to turn the cascading feature off.

5.7. Styling Model

This section describes some details of the styling model elaborated during Testbed-14 (Figure 2). This model complements previous Testbed results and therefore, it is important to be read in relation to the ontologies described especially in the Testbed-13 Portrayal ER [5]. In other words, some elements of understanding are not repeated in this section and, they are described with Testbed-13 (e.g., tables).

T14 styling model diagram v3
Figure 2. UML diagram of Testbed-14 styling model

5.7.1. FeatureTypeStyle Modeling and Vector-based (Feature-based) Representation

A FeatureTypeStyle describes the styling instructions to apply on features coming from a DataLayer so as to render a MapLayer as an output. The input is a DataLayer built of an ordered list of DataSource each containing a single feature type. As an example, given DataSource A has linear feature for roads, DataSource B has polygon features for urban areas, DataSource C has point features for gas stations, and DataLayer Z built of {B, A, C} gives the rendering engine to first process B, then A, then C.

This is in line with what is mentioned in Testbed-13 (§ 6.3.5):

"The OGC SLD standard defines the concept of "layer" as a collection of features
that can be potentially of various mixed feature types."

and also:

"The WMS interface uses the LAYER parameter to reference named layers as in the example parameter: `LAYERS = Rivers, Roads, Houses`".
The ordering of the list has importance; this is the behavior of MapBox (old Mapbox Studio for desktop) and CARTO (online editor) with CartoCSS.

Also, SE 1.1 defines the FeatureTypeStyle concept as the styling that is to be applied to a single feature type. The FeatureTypeName property allows identifying the specific feature type that the feature-type style is for. In other words, the idea for Testbed-13 and Testbed-14 is that a FeatureTypeStyle is associated to a specific feature type that has to be identified in the case of a DataLayer with many feature types (in "Table 4" of the Testbed-13 Portrayal ER [5], this is presented by the featureType table attribute).

In consequence, the present styling model shares a common understanding of the Style concept being a central concept and especially the FeatureTypeStyle concept being a style applied for a specific FeatureType. Similar to Testbed-13, the scope of the Testbed-14 is limited to vector-based (feature-based) representation.

5.7.2. PortrayalRule

The main difference with Testbed-13 is related to the interpretation by the rendering engine of a set of rules (see the Testbed-13 Portrayal ER [5] chapter Rule interpretation with cascading).

Table 1. Properties of PortrayalRule
Name Definition Data type and value Multiplicity


An Optional set of Selectors which determine whether the rule should be applied or not




Scale range to which the rule applies






The symbol associated with the rule



Z-order may be added as an optional integer typed property to specify the visual rendering priority of elements within a single layer or the ordering of the layers themselves

5.7.3. ScaleRange

The ScaleRange concept is just an extraction of the properties related to the special filter allowing to restrict the styling of a PortrayalRule to a certain range of map scale.

Table 2. Properties of ScaleRange
Name Definition Data type and value Multiplicity


The minimum scale denominator to which the rule applies




The maximum scale denominator to which the rule applies



5.7.4. RuleCondition

RuleCondition is similar to the concept presented in the Testbed-13 Portrayal ER [5]. Like ScaleRange, it is a concept used by PortrayalRule to "define conditions of application of associated symbolizers" (from OGC 08-067, Symbology Conceptual Core Model), hereby related to feature attributes. In other words, it is to identify a subset of features from a collection of features whose property values satisfy a set of logically connected predicates (constraint according to the Testbed-13 Portrayal ER [5]). If the attribute values of a feature satisfy all the predicates, then that feature is considered to be part of the resulting subset a given Symbol.

Table 3. Properties of RuleCondition
Name Definition Data type and value Multiplicity


Constraint defining the condition of application of the rule in relation to attributes of the feature type data model (similar to the WHERE clause of a SQL statement)



Discussion: Whether to specify the scaleRange separately from the ruleCondition is still being debated. In an earlier version of the conceptual model, the min and max scale range specifiers were simply defined as comparison expressions between constant numerical values, and the view scale denominator, that generic expressions allowed to define (see also section on Expressions below). The advantage is that the ruleCondition then completely encompasses whether a rule should be applied or not. A potential reason for separating it is to somehow highlight the scale condition as opposed to other selectors, but the encoding could still opt for doing this while keeping it within the ruleCondition for the conceptual model. The concept of expressions is to have a consistent generic approach, which would apply as well to rules conditional on time range for example; or allow the comparison of attribute values in comparison with the current view scale.

5.7.5. Expression and Binding

The concept of "Expression" allows different types of values, both static and dynamic, that can represent feature attributes, geometry, layer identifier, properties of the current view such as scale, visualization time, and more. In addition to primary expression constructs, more complex expressions can be built through operators evaluating a relation between operands, performing arithmetic, function calls and more. Depending on the expressions complexity supported, expressions can offer a level of flexibility almost comparable to a miniature programming language.

Testbed-13 adopted an approach with expressions as literals and associated to a standard URI (Unique Resource Identifier) for the query language of the expression (OGC Filter or SPARQL (a recursive acronym for SPARQL Protocol and Resource Description Framework Query Language)). Also, Testbed-13 introduced the idea of "Binding" which is a good conceptual definition of the binding to symbolizer attributes.

In the conceptual model introduced for Testbed-14, expressions are used both for specifying the conditions for a rule to apply, as well as for specifying any value for a given style or symbolizer property. When wondering if a symbolizer attribute can be manipulated, it is generally just a matter of time to find a use case to confirm that yes, it has to be (notice it is also the approach of desktop tools like QGIS).

Moving away from an "encoding approach", the model may better try to specify the extent of the abilities. We can distinguish between different types of primary expression constructs: Literals (textual, numeric, lists), Identifiers, Variables (application controlled), Operations (with Function calls as a particular type of operation) (see the Conceptual Model Expressions appendix of this ER).

While pre-built functions used in portrayal are required (text formatting functions, transformation functions already available in SLD/SE such as recode, categorize, interpolate, etc.); the expression model stays extensible, allowing the definition of advanced portrayal profiles with an enriched set of functions (geometry manipulation functions like start/end of line, etc.). See also GeoServer filter function reference:

5.7.6. Symbol and Symbolizer Extension Points

Introducing a Symbol concept between the PortrayalRule and Symbolizer concepts, as suggested by the Testbed-13 Portrayal ER [5] symbolizer microtheory, makes sense within the context of the[Testbed-13 Portrayal ER] (B.12.4.4): "Allow the retrieval of a Symbol instance in the frame of a Semantic Portrayal Registry. As a consequence, it is the Symbol that holds the various Symbolizers to draw to create a cartographic representation (and not the Rule as it is for SE 1.1). That is why the cardinality of a _PortrayalRule has one mandatory Symbol."

In other words, a Symbol instance "describes how a feature is to appear on a map" utilizing the concept of Symbolizer which details the various styling information to apply given a drawing order.

Testbed-13 states that a "Symbolizer is obtained by specifying one of the sub-classes of Symbolizer and then supplying parameters to override its default behavior". Testbed-14 keeps as a base this vision of the Symbolizer concept coming from SE 1.1 as a top class of all the possible types of symbolizers and provides properties that are inherited by all. Also, all these types of symbolizers also share the multiple common cardinalities with the Symbol concept.

Nonetheless, in Testbed-14 the possible types are seen as categories of symbolizers, adding an intermediate level of specialization. For instance, as opposed to SE 1.1 se:PolygonSymbolizer, the Fill class inherits from Symbolizer but is also defined as the parent class of all the different and conceivable types of area filling abilities. As a consequence, a container does not define how to draw the linear border of an area which rather a concern of one Stroke class specialization (versus se:PolygonSymbolizer which did include this information). Notice, this may call into question the logic of separation between Symbolizer ontology and Graphic ontology defined in Testbed-13.

Finally, there are two levels of extension points: Either at the Symbolizer top level to define a new category of symbolizers (e.g., might be for raster data) or at the intermediate level to define specializations belonging to a given category because of a common styling intent (Fill is to fill, Stroke is to stroke, Label is to label with deconfliction, etc.).

As a consequence, from the Testbed-13 Portrayal ER [5] symbolizer microtheory, while we keep the Symbolizer concept definition (name, title, description, unit of measure, list of bindings to apply), we redefine the sub-classes as presented in the following section.

Fill Extension Point

The Fill abstract class is the parent class of all the different and conceivable types of area filling abilities (e.g., to draw a polygon-typed feature geometry or any shape with an area to fill).

Table 4. Properties of Fill class
Name Definition Data type and value Multiplicity


Used to specify the geometric attribute from the data model associated with the symbolizer or process each geometry before drawing (e.g. ST_Buffer)




If true the drawn area will be considered an obstacle for labels so no label will overlap it



Fill behavior according to geometry type (may be redefined by Fill sub-types):

  • (multi)point feature: does not apply.

  • (multi)line feature: does not apply.

  • (multi)polygon feature: relative to the inside surface of the polygon (all polygons when multiple geometries).

Stroke Extension Point

The Stroke abstract class is the parent class of all the different and conceivable types of linear drawing abilities (e.g., to draw a line-typed feature geometry or any geometric line).

Table 5. Properties of Stroke class
Name Definition Data type and value Multiplicity


Used to specify the geometric attribute from the data model associated with the symbolizer or process each geometry before drawing (e.g. ST_EndPoint)




Offset distance between original geometry and the drawn line stays equal




If true the drawn line will be considered an obstacle for labels so no label will overlap it



Stroke behavior according to geometry type (may be redefined by Stroke sub-types):

  • (multi)point feature: does not apply.

  • (multi)line feature: relative to the line (all lines when multiple geometries).

  • (multi)polygon feature: relative to the outline of the polygon (all polygons when multiple geometries).

Mark Extension Point

The Mark abstract class is the parent class of all the different and conceivable types of point marking/drawing abilities (e.g., to draw a point-typed feature geometry or to hang a mark on a geometric point).

Table 6. Properties of Mark class
Name Definition Data type and value Multiplicity


Used to specify the geometric attribute from the data model associated with the symbolizer or process each geometry before drawing (e.g. ST_GeometricMedian)




Defines a list of transform definitions that are applied (among Translate / Scale / Rotate according to SVG transform definitions)




Defines the level of opacity to apply when rendering the mark




If true the drawn point symbol will be considered an obstacle for labels so no label will overlap it



Mark behavior according to geometry type (may be redefined by Mark sub-types):

  • (multi)point feature: relative to the point (all points when multiple geometries)

  • (multi)line feature: relative to a centroid of the geometry or any similar representative point (set of centroids when multiple geometries)

  • (multi)polygon feature: same as previous

Label Extension Point

The Label abstract class is the parent class of all the different and conceivable types of feature labeling abilities. One main ability is related to the control of deconfliction resolution to avoid the overlapping of labels between them and with other features (see also labelObstacle properties of the other symbolizers). In other words, using Label symbolizers may hide the labeling of some geometries in some circumstances, whereas using Mark symbolizers guarantees the display of the marking of all geometries to be rendered.

Table 7. Properties of Label class
Name Definition Data type and value Multiplicity


Used to specify the geometric attribute from the data model associated with the symbolizer or process each geometry before drawing (e.g. ST_GeometricMedian)




If true the labelling is performed according to a deconfliction algorithm




Specifies an expression to use in determining which features to prefer if there are labelling conflicts




Defines the visual properties of the label to write on the map




A mark to display behind the label such as a highway shield



Label behavior according to geometry type is similar to the Mark behavior (may be redefined by Label sub-types).

5.7.7. Composition of Symbolizers

The idea of symbolizers composition allows drawing each feature several times according to different symbolizers to create a symbol in itself. Often, it is used to compose two descriptions of the same symbolizer type. As an example, the Harmonica index is built of two Mark symbolizers, a triangle over a rectangle ( Another example, to draw an alternation of a dash (PenStroke) and symbol (PatternStroke) on a line feature (

Notice that there is a given order which is essential to consider, a different order producing a different rendering.

Table 8. Properties of symbolizers composition
Name Definition Data type and value Multiplicity


List of symbolizers applied according to a given order (each feature is drawn multiple times even for repeating several times a same type of symbolizer)




Composition operator (e.g. src-over / dest-out / dest-over)



For each item, a pass level may be used to define the belonging of the Symbolizer to a separate rendering pass. This means each layer is drawn multiple times (versus each feature is drawn several times). For more details, please refer to section "A symbolizer to compose".

Table 9. Properties of Pass
Name Definition Data type and value Multiplicity


Define the belonging of the Symbolizer to a rendering pass (zero is the default rendering pass)



5.7.8. Styling Model Fill Extensions


The SolidFill class is a concrete implementation of the Fill symbolizer class and allows to formulate an area filling according to color and its opacity.

Table 10. Properties of the SolidFill class
Name Definition Data type and value Multiplicity


Represents a color in a given color space




Represents a percent of opacity




The PatternFill class is a concrete implementation of the Fill symbolizer class. This class repeats a mark according to a rectangular tiling pattern over an area (i.e., mosaic). A mark can be defined very informally as "a little picture". The appearance of the mark is defined according to the related mark sub-type to be used.

Table 11. Properties of the PatternFill class
Name Definition Data type and value Multiplicity


The mark to repeat within the area




Define the X gap of an empty space to put between two consecutive tile




Define the Y gap of an empty space to put between two consecutive tile



5.7.9. Styling Model Stroke Extensions


The PenStroke class is a concrete implementation of the Stroke class. This class defines drawing a line analogously to how a pen is used with ink. That is to say by filling the area formed by the thickness of the line with a color and optionally considering a pattern of dashes and gaps.

Table 12. Properties of the PenStroke class
Name Definition Data type and value Multiplicity


Represents a color in a given color space




Represents a percent of opacity




Thickness of the line which gives form to an area to fill with the given color




Similar to the SVG definition




Similar to the SVG definition




Defining the pattern of dashes and gaps used to draw a linear part

List of Decimal



Defining an offset on the rendering of the associated dash array (shifting the start of the dash array computation)



We may also introduce a StippleStroke case to fill the area formed by the thickness of the line with the repetition of a Mark, similar to PatternFill (to be done, evaluate the relevancy of the term stipple introduced by OGC 09-016).


The PatternStroke class is a concrete implementation of the Stroke class. This class is about one graphic repeated along a line. This is very similar to the SE 1.1 definition of GraphicStroke. The Length property specifies the linear length to reserve along the line for one of the repeated marks to plot. By default, the linear length is equal to the Mark natural length (which depends on the view box of the Mark). This has the effect to perfectly juxtapose the repeated marks all along the line. Zero-length value means the mark is not repeated within all the available linear space. Notice that a single Mark is not plotted if the size of the available linear space smaller than the Length.

Table 13. Properties of the PatternStroke class
Name Definition Data type and value Multiplicity


The mark to plot along the line

Graphic data type



Linear length to reserve along the line to plot a single mark (by default it is the mark natural length)



A renderer MAY apply some aesthetic embellishments like trying to bend a graphic around corners or avoid a graphic to be cut at the start or at the end.

5.7.10. Styling Model Mark Extensions

On many points, the conceptual model defines these mark extensions in line with the Testbed-13 Portrayal ER [5] Graphic Object Hierarchy.


The Image class is a concrete implementation of the Mark class. This is the simplest point marking ability, by referencing a bitmap image resource (e.g., portable network graphics (PNG)).

Table 14. Properties of the Image class
Name Definition Data type and value Multiplicity


Reference to resource from which a bitmap image can be obtained




Expected content format of a successful fetch (MIME type)




Indicates the width of the image




Indicates the height of the image




The Graphic class is a concrete implementation of the Mark class. This class allows the referencing of a vector image resource (e.g., in particular SVG). The main difference from the Image class is related to the optional ability to override the styling properties of the linear and area parts inside the graphic. By default the properties defined inside are used and 100% black if no inside properties are defined.

Table 15. Properties of the Graphic class
Name Definition Data type and value Multiplicity


Reference to resource from which a graphic can be obtained




Expected content format of a successful fetch (MIME type)




Indicates the width of the graphic




Indicates the height of the graphic




Override the styling properties of the linear part inside the graphic




Override the styling properties of the area part inside the graphic



The overriding of the stroke and fill styling properties is inspired from CartoCSS which makes this difference between what is called the Point and the Markers symbolizers. The latter offers marker-line-color, marker-line-width, marker-line-opacity, marker-fill, marker-fill-opacity visual properties as PenStroke and SolidFill offers in this conceptual model.


The Shape abstract class extends the Mark class to allow to define a geometric figure to use a customized shape marker. There is one common property to all markers of this type, the stroke so as to draw the linear part of the shape, being it an open or closed shape.

Table 16. Properties of the Shape class
Name Definition Data type and value Multiplicity


The stroke visual properties to use to draw the linear part of the shape



Notice, as described in Testbed-13, we consider the following sub-types of Shape: ClosedShape, Line and Arc. The intent here is to conceptually define these sub-types, whereas Testbed-13 proposed an "encoding approach" to describe the geometry of the shape (e.g., Scalable Vector Graphics (SVG) path definition or Well Known Text (WKT), Geography Markup Language (GML)):

We may argue it is important to keep the SE 1.1 well-known names, but such an ability is similar to referencing a registry of predefined shapes to avoid specifying the points forming a little square every time such a simple shape is used. Precisely, a portrayal registry is the kind of ability that is described in Testbed-13.


The ClosedShape abstract class extends the Shape class as one of the types of Marker which allows to use a customized and especially closed shape marker to hang on the reference point to draw. Therefore, there is one more common property to all markers of this type, the fill so as to draw the area part of the shape, because it is closed.

Table 17. Properties of the ClosedShape class
Name Definition Data type and value Multiplicity


The fill visual properties used to draw the area part of the shape



The intent here is to define conceptually only the concrete sub-types to describe closed shapes (in comparison to Testbed-13, Circle and Polygon are concerned, whereas Line is rather a "simple" Shape):

  • Circle: may be defined according to center and radius

  • Rectangle: may be defined according to two corner points

  • Polygon: may be defined according to a list of connected points and joining start and end points

  • ClosedArc: may be defined similar to the arc definition while joining start and end points


The Text class is a concrete implementation of the Mark class. It allows to defines a mark consisting of a text built of one or many characters. It may be used to reference a specific glyph in a font.

Table 18. Properties of the Text class
Name Definition Data type and value Multiplicity


Text label associated with the symbolizer




Font visual properties




Halo visual properties applied to the background of font glyphs (color or radius)



Shortly, Font and Halo definition is as follow:

  • Font: may be defined according to font family, color, font style, weight and size

  • Halo: may be defined according to radius and color

5.7.11. Styling Model Label Extensions

The extensions described in this section are inspired by the OGC Engineering Report OGC 09-016 [6] which defines labeling specializations on the base of a shared Label abstract class.


The PointLabel class is a concrete implementation of the Label class. This class defines specific visual properties to draw a text label relative to a point placement:

  • for 0-dimensional geometry, it is the geometry itself;

  • for 1 or 2-dimensional geometry the semantic is to compute and use a representative interior central point as the point placement (i.e., guaranteed to lie on the line or the surface interior).

Notice that for a collection of geometries the label is just repeated at each part.

Table 19. Properties of the PointLabel class
Name Definition Data type and value Multiplicity


Defines a list of transform definitions that are applied (among Translate / Scale / Rotate and according to SVG transform definitions)




The minimum distance between the next text label (defines a kind of exclusion zone)




The LineLabel class is a concrete implementation of the Label class. It defines specific visual properties to draw a text label relative to a line. In particular, it draws an aligned text label relative to a placement line:

  • for a 1-dimensional geometry, it is the line itself

  • for a 2-dimensional geometry, it is a line following the shape of the geometry

Table 20. Properties of the LineLabel class
Name Definition Data type and value Multiplicity


Makes the label be parallel to the line at the given distance (by default the label is displayed so as the line crosses the center point of the label)




If true then repeat labels by inserting the given gap values between each label along a line




Defines the gap value between each label repeated along a line (only relevant when the repeat property is set true)




How far away the first label will be drawn relative to the start of the rendering line (only relevant when the repeat property is set true)



5.7.12. Default Values and Color Definition

For the conceptual model presented in this document, default values still need to be considered, also in relation to the specification of different encodings. In particular, all visual properties with 0..1 multiplicity may have a default value (e.g., what is the default color for a PenStroke?). Pushing the "one conceptual model, many encodings" further, it would be interesting to allow each encoding specification to define its default values.

Please note that CartoCSS needs at least one visual property to be set to activate the symbolizer (e.g., setting only line-width = 2 implies line-color = black, whereas setting only line-color = red implies line-width = 1).

Moreover, concerning the definition of colors, Testbed-13 suggested using a CSSColorLiteral datatype that uses the same syntax as CSS and SVG. This may be questioned given a more conceptual definition (e.g., tuple of numbers according to a color model).

Also, we should consider the possibility that an encoding can define its own named colors. This may be acceptable as soon as the encoding specification takes care to document the converting into the root definition of a color, that is a tuple of numbers according to a color model.

5.8. Towards a Basic Profile

The above conceptual model has the objective of defining the core structure and organization of a styling model with explicit extension points. In contrast, although the intent for Testbed-14 was not to define an exhaustive set of symbolizer abilities, those described above might be a good set to become a basic profile, including especially composition abilities.

We may wonder if a "super-basic" profile would be interesting for the elaboration of really simple cases. That profile would be set only with one specialization of Fill (SolidFill), one of Stroke (PenStroke), one of Mark (Image) and one of Label (PointLabel) and no composition.

Also, we may think to other profiles, for instance in relation to thematic mapping. Indeed, while choropleth and proportional symbols are made possible by the basic profile defined above (and the availability of transformation functions like categorize and interpolate defined by SE), some advanced abilities are useful.

We may think to specific Fill sub-types:

Or even specific Mark sub-types:

Finally, we may wonder if the ability of sharing identifiers introduced by Testbed-13 has to considered part of the basic profile.

5.9. Towards Encoding Specifications

The idea for Testbed-14 was not to define a complete default encoding, but rather to start the definition of good practices to elaborate an encoding specification document.

The main point to underline here is related to the organizing of such a document. Indeed, given a conceptual model which describes styling abilities with the definition of explicit requirements for each table and rendering characteristics, an encoding shall describe a syntax mapping for all the related classes and properties in the conceptual model.

For instance, considering the below Requirement related to composition abilities:

The GeoCSS syntax mapping would explain how all properties may have multiple values separated by commas. The specification document would import content explained in the documentation with some relevant examples (

The CartoCSS syntax mapping would explain how it is possible to create multiple symbols of the same type using named instances. The specification document would import content explained in the documentation with some relevant examples (

6. Portrayal Demonstration

This section summarizes the workflows used for Portrayal Thread demonstration and Technology Integration Experiments (TIEs).

The Goal of the Portrayal Challenge
Given the same data and symbols, provide the same (or as similar as possible) portrayal in each user’s computing environment.

The Portrayal demo tries to link symbols and features, and help different users quickly understand the Daraa region in their computing environment (Figure 3). Interoperable geospatial portrayal still is challenging across multiple environments such as:

  • Web/mobile/desktop (computing)

  • Server-side, client-side (rendering)

  • Connected/disconnected/intermittent/limited (communications)

  • Aerial/imagery/hillshade/gray/night backgrounds (display)

Figure 3. Portrayal Challenge: Given the same data and symbols, provide the same (or as similar as possible) portrayal in each user’s computing environment

6.1. Daraa Test Dataset

To demonstrate the robustness and flexibility of the portrayal model to accommodate different data models and formats, we have implemented and tested the following formats and protocols to build map layers.

6.1.1. Shapefile

The Shapefile format is a legacy data format for sharing 2D vector data between geospatial software systems. Esri developed the Shapefile format as an open specification for data interoperability among Esri and other geographic information system (GIS) software products. The Shapefile format can spatially describe vector features: points, lines, and polygons, representing simple feature data. A geospatial dataset encoded in Shapefile format is composed of multiple files. However, many services distribute Shapefiles in a ZIP compressed file form so that they can be bound together as a coherent set of files. For this reason, the implementation of the portrayal service supports creation of a Shapefile that is wrapped in a ZIP file that can be accessed remotely via a simple uniform resource locator (URL) for the demonstration (Figure 4). These data files are available in the OGC Portal.