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.