OGC Portrayal Concept Development Study

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.

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.

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.

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

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

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.

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.

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.

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.

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:

Experiences from Arctic SDI are summarized below:

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.

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:

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.

In each country, OGC Web Map Services (WMS) have been developed from data at 1:250,000 scale. The eight national WMSs support a common symbology based on the EuroRegionalMap specification to provide consistent cartography. All layers are served using several Lambert Azimuthal Equal Area coordinate reference systems to provide regional views centered on the North Pole. National map data includes the territorial sea, defined as a 12 nautical mile buffer into the sea or ocean. An OGC Web Map Tile Service (WMTS) is being created to provide a rapid-access cached tile view of the Arctic. OGC Web Feature Services are also being investigated as companions to the WMS to enable download of selected map features and data for further GIS analysis.

The current background map process involves harmonizing existing data to comply to a standard cartographic product based on a standardized set of symbology. This harmonization process is mostly manual, though the particulars depend on the GIS tools available in that country. Each member nation uses a different method to symbolize the features, depending on the software available locally. Ideally users would have more flexibility to customize the base map beyond the projections and two color palettes (color and black/white) but this is not possible today.

SLD is not currently a required part of this workflow. Some countries use SLD to portray maps, but it is not used as a shareable resource. The main reason for this is a lack of interoperability, specifically, the lack of consistency between implementations. For SLD to be a part of the picture, implementers need to be sure that SLDs are portrayed consistently. There are also secondary concerns relating to a) the different vendor implementations which are not optimized for SLD and therefore make SLD harder to use, b) reduced performance, and c) the security implications of opening up web services to arbitrary SLDs. While SLD editing is a complex process, this complexity seems reasonable relative to the complexity of the map product being produced.

Once the maps for each nation are produced, they are served together by a Cascading WMS. To improve performance, the maps are also pre-tiled and served as a WMTS. The tiling process is complicated by the fact that 7 map projections are commonly used as part of the Arctic SDI.

There is general consensus that SLD is not capable of fully meeting the needs of the Arctic SDI today. A number of the capability gaps identified in the SLD/SE Review (see: Styled Layer Descriptor and Symbology Encoding) apply here. Thankfully, the emerging SLD 2.0 conceptual model has the potential to meet many (if not all) Arctic SDI needs.

The CDS Team recommends that the SLD SWG establish a "basic" profile for SLD 2.0 that is released along with the initial encoding of the standard. This profile should be aligned with the mandatory elements in the Arctic SDI Cartography Data Model so that Arctic SDI members will be able to produce minimally compliant maps as quickly as possible. This profile must include the following extensions:

The CDS Team recommends that the Arctic SDI establish a profile for SLD 2.0 that extends the "basic" profile and includes all of the optional elements in the Arctic SDI Cartography Data Model. Representatives of the Arctic SDI will need to work with the SLD SWG to ensure that the necessary extensions are developed in a timely manner. The profile must include the following extensions:

The server technology employed at NRCAN uses fonts to define graphic point symbols and glyphs for point features and ticks along lines and polygon borders. This technology provides a mechanism for displaying symbols in a "sharp" non-pixelated manner at different symbol sizes. However, there is some overhead in designing and implementing a font for this purpose. More flexibility would be possible with support for external vector symbols such as SVG.

The currently available technology employs a mechanism for styling using a bitmap-based image instead of font glyphs. This approach provides custom map symbols for the map maker without the overhead of constructing a font. However, close inspection of the rendered symbol reveals that the bitmap-based mark can be pixelated. There are additional cases where the glyph size is tied to ground units and using a bitmap-based glyph is impossible due to pixel blurriness caused by scaling. These requirements illustrate a need to support multiple methods for drawing symbols.

Legend generation using the current technology cannot support advanced requirements such as those for geological map legends. Geological maps are information heavy and are precise in their symbology and interpretation. The Geological Survey of Canada Phanerozoic map legend has requirements which are best delivered in a matrix cross-referencing age and rock type. This legend would probably never be automatically generated by a map server, but there is no mechanism in the LegendGraphic concept in WMS to support anything other than an image of particular height and width. In a web-based client, this legend could provide "click-through" functionality to provide more information. A legend for a map layer that could also be an interactive mini-application would be useful in this case. This case presents an online mapping challenge. Are there implications for web mapping protocols to extend the legend declaration approach.

When considering the function of a map to communicate a particular theme or message, labelling is equally, if not more important than symbology choices. The nature of digital mapping, especially on the web, presents labelling challenges to any cartographer.

Labelling in cartography is a painstaking process. In the "single-view" paper and document map, labels can be carefully re-aligned, rotated, scaled, kerned, and translated. They can be omitted altogether, prioritized, given leader lines - all through manual manipulation. In digital mapping environments that provide a continuous scale, and dynamically rendered maps, labelling is an exercise in compromise between quality and effectiveness.

Labeling is difficult due to a number of issues:

There is no understanding at the client platform level of what is being labelled when the information is most often delivered as raster data from a multitude of different services.

End-users often combine layers from different map servers in a single map view. It was the original intent of web-based WMS clients to enable the "sandwiching" of layers from different servers. The standard client used by the FGP does not support the interleaving of individual layers from different servers. Other OGC standards based servers present their own issues. The traffic and load experienced by some FGP map servers prevents the use of WMS as a solution. A tiling solution is implemented to support the map.

A modular design of the ontologies follows the principle of making a minimal ontological commitment to the nature of concepts and of relationships between concepts. As explained by Thomas Gruber [Gruber] an ontology should require the minimal ontological commitment sufficient to support the intended knowledge sharing activities. An ontology should make as few claims as possible about the world being modeled, allowing the parties committed to the ontology freedom to specialize and instantiate the ontology as needed (which is often called ontology or application profile).

Opting for such a minimal approach is made dramatically easier by the vocabulary extension mechanisms offered natively by Semantic Web technology. Applications that require more constrained behavior may define compatible extensions to OWL or SKOS. For example, modelers may coin sub-classes and sub-properties of OWL or SKOS properties, or associate those properties with specific formal axioms. By making a minimal ontological commitment, the ontologies can be applied and reused across multiple Communities of Interests (COIs), thus increasing the rate of wide-spread adoption.

Quoting Stuckenschmidt and Klein [Stuckenschmidt04], “ontologies that contain thousands of concepts cannot be created and maintained by a single person.” Modularization helps designers manage complexity by reducing the size of the design problem [6]. Ideally designers design modules of a size that they can manage, and later either integrate these modules into a final repository or build up the relationships between the interoperable modules (this is a typical application of the divide-and-conquer principle).

Modularization also provides a way to keep performance of ontology-based services at an acceptable level. Performance concerns may be related to query processing techniques, reasoning engines, and ontology modeling and visualization tools. The reasoners that are currently available perform well on small-scale ontologies, but performance degrades rapidly as the size of the ontology increases. Keeping ontologies small is one way to avoid the performance loss, and modularization is a way to replace an ontology that tends to become oversized by smaller subsets. Modularization fulfills the performance goal if, whenever a query has to be evaluated or an inference to performed, this can be done by looking at just few modules, rather than exploring the whole ontology [Stuckenschmidt09].

Re-usability is a well-known goal in software engineering. Reuse is most naturally seen as an essential motivation for approaches aiming at building a broader, more generic repository from existing, more specialized repositories. However, it may also apply to the inverse approaches aimed at splitting an ontology into smaller modules. In this case, the decomposition criterion should be based on the expected re-usability of a module, i.e., how well can a module fill the purpose of various applications. Re-usability emphasizes the need for rich mechanisms to describe a module in a way that maximizes the chances for modules to be understood, selected, and used by other services and applications.

An obvious prerequisite is the ability to use an ontology to understand the concepts and properties it conveys. Whether the content is shown in visual or textual format, understanding is easier if the ontology is small (a module). Small ontologies are undoubtedly preferable if the user is a human being. However, size is not the only criterion that influences understandability. The way it is structured contributes to improving or decreasing understandability.

In light of the criticisms of the existing SLD and SE standards, there is broad agreement that a new symbology and portrayal standard is required. An updated standard must have a core and extensions model, support multiple encodings, and have a useful default or basic implementation that is suitable for use by a large percentage of the potential user base. A draft standard document describing the portrayal conceptual model (PCM), as presented in Vision, will serve as a starting point for further activities. The PCM will address the limitations of SLD and SE as identified in Limitations of SLD and SE and will ultimately lead to a new OGC standard.

The PCM has no new dependencies, but it does build on prior work from the SLD SWG and Semantic Portrayal activities from recent OGC testbeds.

At the time of writing, the PCM development is currently in progress. A draft specification has been produced and is currently under review by the SLD SWG. It still needs to be harmonized with the Portrayal Ontology that was produced during OGC Testbed 13. The default profile has not yet been established. A candidate standard should be available by the second half of 2018.

In this task, software will be built to demonstrate features which are styled using semantic portrayal, encoded in a GeoPackage, and displayed on a mobile / handheld device. As part of this effort, a GeoPackage encoding for semantic styling information will have to be developed. This work will demonstrate that Semantic Portrayal is a viable technique for client-side rendering of feature data.

This activity builds on activities from recent OGC testbeds. Separate previous activities in recent OGC testbeds have demonstrated the ability to display (render) feature data stored in a GeoPackage on a mobile-handheld device and the ability to execute Semantically-Enabled Portrayal capabilities on a mobile-handheld device. This effort would combine these two capabilities, implementing Semantically-Enabled Portrayal on GeoPackage-hosted data on a mobile-handheld device.

If available, the draft PCM should be used as an input.

This work is scheduled as part of OGC Testbed 14 which will be conducted during the 2018 calendar year.

An Interoperability Experiment (IE) will determine whether multiple implementations of the portrayal conceptual model can be used by producers and consumers to share portrayal information and produce compliant maps.

Primary focus will be on the basic implementation of the PCM, but organizations should be free to introduce other profiles. There is a benefit to experimenting whether a portrayal with one or more extensions works properly (sans extensions) in software that is not aware of those extensions.

This is dependent on a stable draft of the PCM and a default implementation (including encoding and mandatory extensions). It is permissible to develop the default implementation as part of the IE but the draft PCM should be developed first and at least be feature-complete before the IE starts. It is normal to revise and refine both the PCM and default implementation during the IE.

This is a new proposal that could be executed in late 2018 or early 2019.

Once the PCM is proven as a viable candidate standard as a result of a successful IE, it should be adopted by OGC as a standard. There are likely to be multiple standard documents, one for the core and one for each encoding. In general, the following activities will need to occur:

While not technically required, an executable test suite should also be produced. In addition, proof of multiple implementation is strongly desirable.

Adoption as a standard would be a strong signal to the market that this specification is ready for use. It would also enable organizations to include the technology in procurement language as a requirement.

Standardization is dependent on successful completion of the PCM Interoperability Experiment.

This is the natural culmination of the work currently being done on the PCM. OGC adoption could realistically occur in mid-to-late 2019.

A pilot project will explore the emerging Semantic Portrayal capabilities and evaluate them for use as part of the Arctic SDI. The pilot project team will consist of one of the Arctic SDI members, a group of geospatial software engineers, and an OGC representative.

In the first phase of the pilot, a semantically-grounded map representation (containing references to both the feature types required to compose the Arctic SDI basemap and the Arctic SDI semantic portrayal rules) will be produced and stored in a Semantic Registry. The basemap production workflow will be modified so that the Semantic Portrayal Engine runs against the Semantic Registry, reaching out to the vector data stores where needed and applying the appropriate portrayal rules as needed. This will demonstrate that Semantic Portrayal is capable of producing a complex, cartographically accurate map product.

In the second phase of the pilot, one or more thematic maps will be produced using the same workflow. This will demonstrate a complete Semantic Portrayal workflow where multiple semantically-grounded maps can be produced on top of the same data and processed to create multiple diverse, cartographically accurate map products.

The Pilot is dependent on the completion of the PCM Interoperability Experiment.

This is a new proposal that could be executed in 2019 or 2020.

An Interoperability Experiment will determine whether multiple producers and consumers will be able to share and discover map layers and styles and combine them together to produce compliant maps. Unlike the previous interoperability experiment (focusing on the PCM), this IE will focus on the semantic services (semantic registry, mediation server, and portrayal server) that allow resources to be shared in an intelligent way.

Both Arctic SDI and Canadian Geospatial Platform members should use this opportunity to prove that the Semantic Portrayal ecosystem is capable of meeting the need of supporting user-defined thematic maps. Styles and map layers will be developed independently and stored in a Semantic Registry. Users will be able to discover this information and compose maps from it. The Semantic Mediation Server will transform resources as needed for submission to a client-side Portrayal Server. The Portrayal Server will reproduce the maps on a wide variety of local devices.

A Semantic Portrayal IE is dependent on a stable draft of semantic portrayal APIs and the PCM. It should probably occur after the Arctic SDI Semantic Portrayal Pilot which addresses similar challenges but in a much more controlled environment.

This is a new proposal that could be executed in late 2019 or early 2020.

Once the different components of Semantic Portrayal have been proven, their interfaces must be standardized so that they are implementable by different software vendors. The process and benefits are similar to PCM standardization.

Standardization is dependent on the completion of the Semantic Portrayal Interoperability Experiment. Other interoperability experiments and/or pilots may also be needed.

This is a new proposal that could be executed around 2020.

In this activity, Semantic Portrayal as envisioned in this document is implemented by each Arctic Council member. The Arctic Council has a single set of workflows that can be executed by each member organization to produce basemaps and thematic maps.

Such implementation is dependent on the Arctic SDI Semantic Portrayal Pilot and the implementation of the Semantic Portrayal standards in software usable by each member of the Arctic Council.

This is a new proposal that could potentially be executed in the early 2020s.

MIL-STD-2525 is a military symbology standard; a graphics library of military objects and the uses, capabilities, and status of those objects. It is a visual language that provides a rapid and cognitive understanding of an object, activity, event, task, etc. to DoD service members. This library could very well be a significant contribution to a symbology repository as envisioned by the Geospatial Intelligence Standards Working Group (GWG). MIL-STD-2525 is NOT a military messaging or information exchange standard.

The purpose of the standard is to provide systems with a universal language that enables the capability to visually identify (symbolize) an object, event, task, etc., based upon the Standard Identity reported in tactical data link (TDL) military messages. In MIL-STD-2525, marker symbols are composed of several levels of information (for example, StandardIdentity1, Status, Icon, and so on). Each level’s options are represented by a unique set of one or more digits. These codes are concatenated into a unique Symbol Identification Code (SIDC) that will determine the look of the final symbol. The role of the 2525 SIDC is to enable a system to uniquely identify, acquire, assemble, and depict a military object, event, etc. The 30-digit SIDC enables that capability by using a language that computers understand best: numbers.

The NATO Allied Procedural Publication 6(APP-6) is another military symbology standard developed directly from MIL-STD-2525. Though the standards have changed at different paces, both organizations involved are working together to develop a common comprehensive joint military symbology.

An interoperability experiment [OG-13-080r3] was submitted to the OGC in 2013. One of the experiments was to demonstrate the implementation of the latest draft version of 2525D/APP6C symbolization for a land and maritime based scenario. The report notes that the changes for 2525D specification were an improvement over previous versions of the standard making it easier to support, specifically changes to the binary identifier and the simplification of symbol rules.

[AML] are a set of geospatial data product specifications defined by NATO STANAG 7170. The Portrayal Specification defines symbols and rules for the display of vector AML datasets and supports AML 1.0, 2.1, and 3.0 vector products. It builds on the IHO ([S-52]) Edition 6.1 standard and the Preslib 4.0. Where appropriate, other symbology specifications have been used as the source for symbols and rules, resulting in a comprehensive and interoperable symbology repository. These specifications include IHO S-411, NATO APP-6, MIL-STD-2525, and MIL-DTL-89045A.

The SLD/SE standards are tightly coupled with the OGC Feature Model and its XML encoding in GML. XML is a poor language for describing information in a concise manner. The implementation of the standards in an OGC Web Map Service (WMS) assumes typically that vector data is provided by OGC Web Feature Service (WFS). Some short notation based on CQL has been introduced to try to bridge the gap, but it is mostly used as syntactic sugar.

There are many formats that are not based on XML such as GeoJSON, Linked Data formats (Turtle, JSON-LD, NT), and Comma Separated Values (CSV). Each of these standards uses different schema language (JSON Schema, OWL, RDFS, CSV schema). When it comes to enable semantic interoperability of portrayal information with a feature model, there needs to be a way to represent the feature model semantically and map it to the different schemas encoding existing for each of the format. There is also a need to have an extensible addressing framework that can accommodate different data models.

Another challenge is the ability to identify feature types in unified way that is independent of the data model used. Most of the OGC standards use XML schema and GML to represent feature type definitions. In Linked Data (such as in GeoSPARQL), Feature types are represented through an OWL class Uniform Resource Identifier (URI). Property Binding in SLD uses XPath to represent paths in XML structure. In Linked Data, properties are typically defined globally and defined as URI. SPARQL Protocol and RDF Query Language (SPARQL) and the Shapes Constraint Language (SHACL) provide a mechanism to define RDF Path. A unified approach is needed to define property paths on different data models (JSON, XML, Linked Data, CSV, etc.).

One of the main challenges with the SLD/SE standards is the lack of a global unique identifier for representing the different portrayal information expressed by SLD/SE. The identifiers are identified within the scope of the SLD document and make it hard to reuse and link to other artifacts expressed in other SLDs documents or knowledge base such as feature dictionary. As a result a single SLD/SE file cannot be used to style a map comprised of multiple layers. In addition, because any rule whose criteria matches is immediately a candidate for rendering, it offers no opportunity to further tweak (override) the styles based on additional criteria. Because it does not enable rules overriding, it is also impossible to cascade multiple style sheets so as to customize map styling at multiple levels.

The OGC SE standard uses OGC Filter Encoding standard [OGC 09-026r2] to express portrayal rules conditions and binding expressions to symbolizer attributes. The OGC Filter Encoding standard describes an XML and Key-Value Pair (KVP) encoding of a system-neutral syntax for expressing the projection, selection and sorting clauses of a query expression. The intent is that this neutral representation can be easily validated, parsed, and then translated into some target query language such as SPARQL or SQL for processing. The OGC SE standard extends the expression model with some pre-built functions commonly used in Portrayal (categorization, formatting functions). While the goal of the OGC Filter Encoding standard is to define a system-neutral syntax, it suffers of many drawbacks.

All the parameter attribute values for the symbolizers defined in the OGC SE standard XML encoding require an OGC expression based on the OGC Filter specification. This makes the encoding very verbose in case a user wants to assign a simple value such as stroke-width to a number. It also makes it difficult to validate the expression as the actual types of parameter attributes are not strongly typed.

SLD/SE defines two properties to refer to FeatureType information.

These properties are not well adapted to accommodate different schema languages and do provide mechanisms to indicate where to get additional information about the feature types. For example, an OpenStreetMap Feature could be encoded in GML, JSON, or XML and would require one to define a different SLD encoding for each of these schemas. It would be useful to define the feature type at the conceptual (semantic) level and then provide links to different encodings and distributions of the schema. Having a global unique identifier for each feature type will enable the integration/linking of the feature type dictionary with styling information and minimize duplication.

It is not unusual for systems to suffer from interoperability defects in terms of rendering quality. These problems may occur for any of a number of reasons.

The OGC Compliance and Interoperability Testing Initiative (CITE) was designed to be a clearinghouse for executable tests but that work has not been done in this case. As a result, implementers do not have repeatable, certified processes for verifying compliance.

SLD and SE were not developed with extensibility in mind. There are no explicit extension points defined in the underlying models. This means that there is no mechanism for meeting new capabilities other than creating new versions of the standards. These standards have not been revised in approximately a decade. Failure to standardize basic elements such as stroke width, color, etc. resulted in different vendor extensions for very basic styles (e.g., SVG and CSS parameters).

Geometry styling requires compliant producers to add appropriate style extensions and compliant consumers to apply styling rules when rendering geometries. The TENET Report ([TENET]) enumerates limitations of the OGC SE in portraying military Alternative Military Layers ([AML]) and hydrographic layers compliant with International Hydrographic Organization (IHO) [S-52].

These limitations include the following.

GeoServer is a well known and widely adopted web service platform that implements OGC service protocols including the mapping services WMS and WMTS, FPS, and CPS. As a response to real demands for styling functionality, the GeoServer team developed an extension mechanism[GeoServer] to support these evolving styling requirements. Many of the recommendations from the change reports have made their way into GeoServer’s SLD/SE extension as well, but have not fed back into the appropriate standards.

In 2011 a Change request for SE (11-023) was issued highlighting the SE extensions created for GeoServer.

The following SLD extensions are implemented in GeoServer.

SLD and SE only have XML encodings and their models are strongly linked to XML modeling principles. As there is a long-term trend for disliking XML, particularly in web-based operations, implementers have looked to other data formats.

While these formats have proven to be more convenient to work with than XML, they have failed to gain long-term support.

If a client wants to fully control the styling, the process of creating an XML document and sending it to the server is a little complex. In response, ncWMS (https://reading-escience-centre.github.io/ncwms/) created a scheme using using URL parameters (https://reading-escience-centre.gitbooks.io/ncwms-user-guide/content/04-usage.html#getmap). This is non-standard and a bit less flexible, but is easier on client developers and has been quite successful. Recently, GeoServer has implemented the same scheme (http://docs.geoserver.org/latest/en/user/community/ncwms/index.html).

A report [OGC17-059] was submitted to the OGC by DGIWG in 2017. The report provides the results of an investigation into the usability of SLD/SE for styling of "military-specific topographic feature vector datasets within a number of software products." The paper claims to have found a number of deficiencies in SLD/SE. These reported issues are presented as a barrier to interoperability.

The report re-iterated the concerns of other past change requests and pointed out that certain attributes such as rotation are interpreted differently from application to application. This implies that the specification needs to be more explicit.

Proposed enhancements for SLD are also included in the paper. Deficiencies and requested enhancements are outlined in the accompanying change request, and are listed in Appendix A [SLDChangeRequests]). This change request also acknowledges that GeoServer implements the missing functionality identified in the paper through vendor-specific extensions.

[Bocher-Ertz] recommends the creation of a new standard for symbology that encapsulates what was previously in SLD^[2] and SE. The overall purpose of the effort is to make the standards dedicated to cartography more attractive. The candidate standard will incorporate the recent change requests to SLD and SE (these are summarized in Appendix A [SLDChangeRequests]). In addition, it will implement a modular structure with a core and many extensions. Finally, it will feature a single encoding-neutral conceptual model and many encodings. (XML may be the first or default encoding but this has not been confirmed at this time.)

The paper makes some additional recommendations for this candidate standard:

Finally, the paper identifies OrbisGIS as a candidate reference implementation for the emerging standard.

The OGC SLD Standards Working Group (SWG) has reconvened and is in the process of producing a new draft candidate standard consistent with the proposals in [Bocher-Ertz] and the portrayal ontologies developed by Image Matters during Testbed 11, 12, and 13.

This Change Request (CR) recommends a method for selecting graphics for graphic symbolizers using the data attributes of the feature. This use an se:ParameterValueType as an option for se:ExternalGraphic providing a method to get the external online resource for the graphic. Implementing this would allow an expression that incorporates the feature data to generate a URI for an external graphic.

The motivation for this CR was to provide a mechanism to reach out to a Portrayal Registry to retrieve a style definition. An SLD user style is inline and not by reference. The implication for this extension is that providers/consumers will be able to exchange customized extensions for style elements to support domain or use case specific applications that are not covered by an accepted SLD version. The comparison in the change request is to the _ExtendedCapabilities element in the WMS capabilities schema.

This CR addresses a symbology shortfall in SE. Hatching is a common fill method in cartography and using the current implementation in SE, must be done with raster fills. This often produces less-than-ideal visual results where raster seams are visible. The CR proposes using a new element se:HatchedFill, with stroke, angle, distance, and reference point to support this cartographic need.

Cartograms are a thematic mapping tool that enables cartographers to emphasize some characteristic of a theme such as population density using distortion of features. This CR proposes a CartogramSymbolizer to distort features using a feature attribute and distortion level. The background for this CR is a paper by the author that provides a reasonable overview of the shortcomings of SE/SLD related to thematic mapping and the efforts of some developers and researchers to address these shortcomings.

The purpose of this CR was to support the addition of a method to nest rules. This nesting supports the selection of multiple rules to style a feature. The example this change request provides is the addition of multiple geometries that may or may not be required to render the primary feature being styled. This change request also proposes that filter clauses within the rules be tagged to function as if/else rules. The inclusion of if/else will prevent the need to have "a condition that is the inverse of the conditions of the other rules." A further change request, 11-148, Symbolizer for styling of nested child objects, separates the child symbolizer idea from the composite rule, but is essentially one half of this change request. As the author points out:

When repeated stroke patterns are applied to lines or boundaries, the length of line between patterns often causes strokes/ticks etc at the closure of lines to interfere with each other. Rapport is scaling the distribution of the pattern symbolizers on the line to be cartographically correct. The distance between patterns placed on the line must be adjusted from the supplied value to one that generates a more aesthetically correct result. This CR proposes a modification to se:Stroke to toggle rapport.

This CR claims that the description of how to interpret scale based on pixel size in the SE specification is confusing and misleading. Scale in the specification is based on a pre-determined pixel size. At issue is the reality that pixel sizes in different mediums such as computer monitors and paper are variable. If interpreted according to the specification, a styling engine will select different rules from medium to medium when those rules are based on scale. The example given in the change request is the different results using the pixel size of printer output vs. the pixel size of monitor output.

The current version of SLD/SE is dependent upon OGC Filter Encoding Specification(FES) 1.1.0. FES is at 2.0 and supports the idea of an AbstractQueryExpression which can include query expressions that include newer components of WFS queries. This change request is a solution to extend the SLD query mechanism to accommodate new changes in WFS. If implemented, this solution would align Web Feature Processing Services with the some WFS 2.0 enhancements.