OGC Testbed-13: Portrayal Engineering Report

Layers and Maps of geospatial data are very commonplace, but there is no consistent and standard way to describe their metadata. While Layer and Map entities are derived from a Dataset entity, they have their own specific metadata. We propose for the next testbed to investigate a profile for Layer and Map concepts that extends the Registry Item and relates to Datasets, Services and Portrayal Information developed for the Semantic Registry and Semantic Portrayal Service.

So far, the emphasis on developing the portrayal ontologies has been on modeling and representing portrayal information for feature data. The proposal is that the next testbed focuses on addressing portrayal information for coverage data (in particular grid coverage). This will close the gap of expressiveness of the portrayal ontology with SLD and SE standards.

For the next Testbed, we propose to extend the ontology to accommodate more complex symbols such as composite symbols and symbol templates to describe more advanced symbology standards such as the family of MIL-STD-2525D symbols. It is proposed to also extend the portrayal ontology to represent composite symbols and symbol templates. Investigation should also include other renderer outputs such as JSON encoding of the portrayal information, so they can be handled on the client side in HTML5 Canvas or other rendering libraries such as D3.js.

The SLD/SE standards are tightly coupled with the OGC Feature Model and its XML encoding in GML. 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.

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.

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

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 a 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, OpenStreet 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 an minimize duplication.

The OGC SLD standard defines the concept of “layer” as a collection of features that can be potentially of various mixed feature types. A named layer is a layer that can be accessed from an OGC Web Server using a well-known name. For example, the WMS interface uses the LAYER parameter to reference named layers as in the example parameter:

The SLD standard defines the concept of NamedLayer to represent map layers that can be referred to by name by a different service. The name that is defined locally to the document is not a global identifier. This is an issue when one wants to refer a layer to other concepts that are defined outside the document, such as a dataset used by the layer (which could be defined by a DCAT Dataset instance).

The NamedLayer element in the SLD standard is defined by the following XML-Schema fragment:

The LayerFeatureConstraints element is optional in a NamedLayer and allows the user to specify constraints on what features of what feature types are to be selected by the named-layer reference. It uses OGC Filter as the filter language, which is mostly designed for data that are mappable to XML.

A named styled layer can include any number of named styles and user-defined styles, including zero, mixed in any order. If zero styles are specified, then the default styling for the specified named layer is to be used. A named style, similar to a named layer, is referenced by a well-known name. A particular named style only has meaning when used in conjunction with a particular named layer. One of the issues with this approach is that the name of the layer is defined locally. It does not define a globally unique identifier that is referenceable, so it can be reused by other layers defined outside the document.

A UserLayer is defined as a subclass of NamedLayer for representing a user-defined layer to be built from WFS and WCS data only, and inline features encoded as GML FeatureCollection only. This is too restrictive as it does not allow UserLayer leveraging other data sources such as GeoJSON, Linked Data sources accessible from a SPARQL endpoint or other popular formats such as CSV or Shapefile. UserLayer is defined by the following XML-Schema fragment:

A user-defined style allows map styling to be defined externally from a system and to be passed around in an interoperable format. The XML-Schema fragment for the UserStyle SLD element is defined as follows:

A UserStyle can contain one or more FeatureTypeStyles or CoverageStyles which allow the rendering of features of specific types. These are described in OGC Symbology Encoding. These styles can either be provided inline within the SLD document or they can be referenced using an OnlineResource containing a OGC SE document with a FeatureTypeStyle or CoverageStyle root element. This organization allows the more convenient use of feature-style libraries.

There is no standard that allows the management of user-defined layers and enables global referencing of layers to enable the reuse of the layers in different maps. There is a need for an API and global referencing of layers, as well as the need to create and describe the concept of a layer in multiple data models and APIs.

Legend plays a central role in the interpretation of map. Legends are typically included with maps to indicate to the user how various features are represented in the map or on the layer. It is therefore important to be able to produce a legend on a map display client. Generating a legend on the client side may involve a significant amount of processing. The client will need to examine the selected style and determine which rules apply at the currently used map scale. While this would save some interactions between the client and server and would allow the viewer client to present consistent sample shapes (across remote map servers from different vendors), the legend graphics might look different from the graphics actually rendered in the map since the viewer and server may have different rendering engines and different graphical capabilities. A better approach is either to associate the legend with a given rule or style or to provide API endpoints to generate legend for a style and legend item glyphs for a given rule or symbolizer.

There are currently three OGC specifications that are relevant to represent Legends: OGC Symbol Encoding (SE), OGC Style Layer Descriptor 1.0 and 1.1, and OGC Web Map Service (WMS) specifications.

In the OGC SE specification, a Rule can be associated with a LegendGraphic element referring to a Graphic Symbolizer. The Graphic Symbolizer can refer to an external graphic using a URL or defined as a Mark. LegendGraphic only has a limited role in building legends. For vector types, a map server would normally render a standard vector geometry (such as a box) with the given symbolization for a rule. But for some layers, such as for Digital Elevation Model (DEM) data, there is not really a “standard” geometry that can be rendered to get a good representative image. This is what the LegendGraphic SE element is intended for, to provide a substitute representative image for a Rule. For example, it might reference a remote URL for a DEM layer called “GTOPO30”:

The OGC SLD specification defines the operation GetLegendGraphic to generate a legend as an image from an SLD style, rule and feature type with flexible legend options to render the layout and labels of the legend on the server side. An SLD-WMS operation request for GetLegendGraphic can look like this encoded in KVP:

This would produce a 16x16 icon for the Rule named “highways” defined within layer “ROADL_1M:local_data” in the SLD. The list of available formats for legend graphics and exceptions can be assumed to be the same as are available for a map in the WMS GetMap request.

In OGC Web Map Service 1.3 specification, a Style may contain a LegendURL that provides the location of an image of a map legend appropriate to the enclosing style. A Format element in LegendURL indicates the MIME type of the legend image, and the optional attributes width and height state the size of the image in pixels. Servers should provide the width and height attributes if known at the time of processing the GetCapabilities request. The legend image should clearly represent the symbols, lines and colors used in the map portrayal. The legend image should not contain text that duplicates the Title of the layer, because that information is known to the client and may be shown to the user by other means.

One of the challenges encountered today by web developers if the display of legends for map. In many instances, legends are returned as bulk images containing multiple items for different symbolizers. Most of the modern web applications today are using Responsive Web design, an approach that suggests that design and development should respond to the user’s behavior and environment based on screen size, platform and orientation. This implies that the client needs to have the ability to layout legend items in a flexible way with positioning of their labels depending of the screen formats. The use of an image for the whole legend is well adapted for responsive design. A more flexible mechanism is needed to convey the whole legend of a map by decomposing legend items that can be customized by a REST endpoint. Very often a legend image is also encoded inline using base64 encoding instead of referring to remote URL, which can add overhead when fetching each individual item.

The Portrayal Service should also accommodate the custom rendering of legend items (glyphs) for symbol, symbolizers and rules to provide visual cues when searching these items in the portrayal service. To address this challenge, an ontology was designed and encoded to describe Legend and Legend Item that can be used in portable way. The full model is documented in Appendix A.

To address the issues related to the encoding of expressions in the previous section, an extensible approach was adopted. It leverages the heterogeneity of the data models, schema languages and query language standards, instead of attempting homogenizing the query language. There are a number of well-defined standards that are used for different data models. In the case of Linked Data, the standard SPARQL and its OGC extension GeoSPARQL are well-established. For XML, XQuery is the W3 standard. Each of these languages has standard mechanisms for defining functions. The advantage of this approach is that the full expressiveness of each language and existing query engines available can be leveraged without requiring a conversion process.

The key idea of the adopted approach is to treat expressions as literals and associate a standard URI for the query language of the expression. A similar approach has been used in OWL-S for representing conditions and parameter bindings in workflow of web services.

A standalone ontology for expression was defined, anticipating that it could be reused in other standards that require query expression in different languages.

The core concept of the ontology is Expression. It has only two properties: expressionBody that captures the expression as a literal and expressionLanguage, which refers to the URI of standard query language. The ontology introduces two convenience subclasses: OGC Expression and SPARQLExpression which have a fixed value to a query language (see Figure 1)

The following are URLs for the query languages that have been used:

This ontology was used successfully to convert SLD portrayal rules expression, but not fully tested for the rendering of the feature data. The Expression ontology is documented in Annex A.

In the symbolizer and graphic ontologies, the graphic properties have a range that corresponds to the type of their values. Using expressions directly as values, will invalidate the model against the ontology rules (i.e. if a range for graphic property is defined as a xsd:integer, assigning an expression object will be invalid in OWL). To address the issue of validation of parameter values (SVGParameter) in SE Encoding, a lightweight Binding ontology was introduced. Symbolizer and PortrayalRule are defined as subclasses of Parameterizable. A Binding can be attached to any Parameterizable Object (see Figure 2). It assigns an expression to a property of the Parameterizable instance.

This ontology was used successfully to convert SLD portrayal rules expression bindings, however was not tested for the rendering of the feature data.

The Binding ontology is documented in Annex A.

A Legend plays a central role in the understanding of the meaning of a map or layer. It associates symbols used in a style with its intended denotation (meaning). This meaning is often associated with a human readable label but could also be associated with a machine-processable concept. A layer can have multiple layer styles. For each style, there is a legend associated with it.

A formal model for a legend was designed to enforce best practices that can make it easier for a client to layout legends in a variety of screen sizes automatically. To address this, the legend was broken down into a set of individual items that can be laid out. The model can still represent a legend with different symbolizers as one image using only one item, however it would be preferable to decompose each symbolizer/rule as one legend item to obtain more flexibility in the layout of the legend.

The Legend ontology is documented in Appendix A.

For the Testbed 13, an initial model was developed to represent a map layer that addresses some of the findings described in the previous section. This model was introduced around the end of the implementation phase in order to support the creation, update, cloning and search of map layers. The model may need some refinement in future testbeds.

The layer model is slightly different from the one defined in current OGC services, in the sense that it can accommodate multiple data sources using different models and formats (XML, JSON, CSV, Shapefile, WFS, GML). These data sources are typically accessible from a URL but could be set inline to capture annotations or small datasets (as demonstrated in Testbed with GeoJSON). Each data source can have several parameters that are represented as a set of key value pairs. The description of the parameters should be provided in the capabilities document of the portrayal service or a dedicated endpoint. This aspect has only been partially addressed in this testbed due to lack of time.

The focus of the layer modeling within the Portrayal Service was to capture the information necessary to perform the rendering of the layer. The design was not focused on the capture of metadata to enable search and discovery of layers in a semantic registry, which was investigated in another Testbed 13 Thread related to the Semantic Registry Information Model (SRIM) [11]. While there is some overlap between both models, the focus was to capture the essential metadata needed to render the layer.

Future testbeds will need to investigate the reconciliation of the SRIM profile for layer and map concepts and the layer description of the portrayal service needed to perform its rendering. The role of each service should also be clarified, for example, which service should capture metadata about layers. The definition of Data source needs also to be reconciled with the Distribution defined in DCAT. Coordinating efforts with W3C Spatial Data On The Web Working Group will help to resolve some of these issues.

The Semantic Portrayal Service implementation is accessible through a hypermedia-driven and Linked Data REST-based API to access layer and portrayal information (styles, rules, symbolizers, symbols) from the service. The Semantic Portrayal implements REST API Level 3 and Level 2 of the Richardson Maturity Model (see Testbed 12 ER) and Linked Data API.

The style information is encoded in the following representations: RDF/XML, Turtle, N-Triples, JSON-LD and HAL-JSON. The Semantic Portrayal Service REST API is described in more detail in Annex B.

To import portrayal information, a pluggable, extensible design approach was adopted, so it can accommodate a variety of formats, as standards evolve in the industry. Each importer type provides a list of parameters with name, description, type and cardinality. This information is used to build User Interface (UI) forms to capture value bindings for each parameter. For the OGC Testbed 13 initiative, importers for SLD 1.0, SLD 1.1 and Linked Data formats (RDF, Turtle, NTriples), based on the portrayal ontologies, were implemented. The importers can work with remote URL or file attachment.

The OGC SLD importer was designed to import SLD documents from either a URL or a file attachment. The imported document was parsed and mapped to the updated portrayal ontology and registered in the Semantic Registry implementing the Portrayal Information. A complete mapping of all related feature style information to the portrayal ontology was accomplished successfully by updating the ontology model with expression and bindings micro-ontology. It was found that the mapping was complete and feasible. However, the ontology had more expressiveness than OGC SLD as it could accommodate multiple data models (JSON, XML, RDF) and expression languages.

The Linked Data model provides a powerful integration mechanism to represent any objects, properties and relationships that can be understood unambiguously by machine (to perform inferences for example). The OGC Testbed 12 implementation of the Semantic Portrayal Service provided the ability to perform transactions of portrayal items in a very granular way by using dedicated endpoints for each item type (symbols, styles, symbolizers). While this was a valid approach, the performance to upload a large set of portrayal information was poor. It also limits one of the main benefits of using Linked Data: linking objects of different types in a semantic graph.

For Testbed 13, an importer for Linked Data formats (RDF/XML, Turtle, N-Triples) was implemented to upload any portrayal concepts managed by the portrayal services and expressed by the portrayal ontologies used by the service. The Linked Data Model was processed on the server side by iterating on all instances of resource types supported by the service and indexing them in the semantic registry. URIs of the resources were used to generate internal identifiers consistently. It was observed that significant improvement in bulk upload time compared to the more granular approach taken in the previous Testbed.

A future improvement, that can be addressed in future OGC Testbeds for this endpoint, is to integrate Shape Constraint Language (SHACL) validator to validate the shapes of the objects to make sure they contain the required properties needed by the service to perform their tasks. An investigatigation of the use of Linked Data for exporting all portrayal information managed by the service should also be performed.

Exporting SLD XML from the portrayal service was done through the /export endpoint. Using the portrayal ontologies, the convertion of FeatureTypeStyle ontological concept to a full SLD document with loss was done without loss. However, the export of symbolizers alone was not possible without breaking the XML validation against the SLD document schema.

The Semantic Portrayal Service was using the Portrayal Registry to store style items.The SRIM profile was updated to accommodate the portrayal items by using the portrayal ontologies. An endpoint to the portrayal registry was also added to import Linked Data for portrayal information. The import endpoint of the Portrayal Service was interfaced with the Semantic Registry import by forwarding the request to the registry. The search of portrayal items in the Semantic Portrayal Service was delegated to the Semantic Registry. The following client Figure 3 shows the portrayal information stored in the semantic registry.

For the Testbed 13 initiative, the different types of renderers for the portrayal service were identified:

The details of each renderer design are as follows:

By the end of the implementation phase of the testbed, the need of implementing a mechanism to persist layer specification was identified, so layers can be referenced easily to construct maps composed of multiple layers. The API and Layer Model design are not as mature as other endpoints developed during this testbed but it provides a good starting point for future investigations and refinements.

In order to make it easier to reference the layer and enable the sharing of layer information over the web, a RESTful approach was used to manage layers. Standard CRUD operations using POST, PUT, DELETE and GET were adopted. An initial model was designed to represent Layer information including Data sources, and Styling information (see previous section). The API is anticipated to be changed based on the enhancements needed to the layer model (in particular with the alignment of the SRIM model).

More detailed information of the REST API for Layer Management can be found in Appendix B.

GeoJSON is a format for encoding a variety of geographic data structures. GeoJSON supports the following geometry types: Point, LineString, Polygon, MultiPoint, MultiLineString, and MultiPolygon. Geometric objects with additional properties are Feature objects. Sets of features are contained by FeatureCollection objects. In 2015, the Internet Engineering Task Force (IETF), in conjunction with the original specification authors, formed a GeoJSON Working Group (WG) to standardize GeoJSON. RFC 7946 was published in August 2016 and is the new standard specification of the GeoJSON format, replacing the 2008 GeoJSON specification.

For this testbed, GeoJSON as data sources for making layers was used in two ways. The first way was to access GeoJSON from a remote URL. For the demonstration, a Github repository of GeoJSON data for countries, states and New York City roads and Police Precincts (see Figure 5) was used.

The use of GeoJSON inline was also tested in the Layer descriptions as a way to capture annotations in web-based applications. To perform this task, two sets of layers were created: the first set retrieved data remotely using a URL, the second set was defined the same layer using inline GeoJSON.

The shapefile format is a popular geospatial vector data format for geographic information system (GIS) software. It is developed and regulated by Esri as a (mostly) open specification for data interoperability among Esri and other 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 zip file format, so they can be bound together as a coherent set of files. For this reason, the implementation of the portrayal service supports shapefiles that are packaged as a zip file that can be accessed remotely via a simple URL. For the demonstration, shapefiles describing airports of the world were used and portrayed with icon based symbolizers.

For the demonstration, a Technology Integration Experiments (TIE) was performed with the Web Feature Service 1.1.0 from GeoSolutions that provided data supporting a mass migration scenario. A significant amount of time was spent solving some issues related to the coordinate order of the WGS-84 coordinate reference system handled by the WFS Client library and GeoServer implementation. The notation EPSG:4326 and the URI form are still misunderstood in the industry causing issues with interoperability. For Testbed 13, the dynamic creation and custom rendering of layers based on WFS data returned in GML were successfully demonstrated.

For this testbed, Image Matters deployed its GeoSPARQL-compliant Server populated with OpenStreetMap data produced in Testbed 12. Some development was started to implement an OGC Query/Filter converter to GeoSPARQL. Unfortunately, due to technical difficulties related to the WFS Client and CRS conventions and the last minute addition of a Layer Management REST API on the Portrayal Service, the full integration of GeoSPARQL with the Portrayal Service was not achieved. This aspect can be addressed in next testbeds, as it could provide a powerful mechanism to portray any Geospatial Linked data on the web.

To demonstrate the REST API for Layer management, it was added in the portrayal web client the functionalities of creating new layers from different data sources such as Zipped Shapefile, GeoJSON, WFS and apply style information on this layer with interactive feedback in a map view. The order of application of symbolizers was controllable in the UI. The rendering of the layer in the map was delegated to the server by accessing the layer rendering endpoint with information about the view context. The rendering endpoint reprojected from the data to the viewer target Coordinate Reference System (CRS) as needed (see Figure 9).

Figure 9 shows the creation of a layer from a dataset of Police Precinct in New York City encoded in GeoJSON accessible from a URL. Two static symbolizers (line and polygon) are applied to the data and rendered in Web Mercator Projection using the layer rendering endpoint of the Semantic Portrayal Service. The rendered image was returned as PNG format.

To integrate the layer managed by the portrayal service with existing web clients such as Leaflet, OpenLayers or MapBox,a rendering endpoint was implemented with the OGC GetMap operation. The integration with Leaflet was demonstrated (Figure 10).

To demonstrate the search capabilities for layers, a faceted search for layers was implemented in the portrayal web client. The client used the Layer Search REST API to perform search by free text, spatial bounding box, keyword, layer types, data sources types. The search results could be sorted by relevance, creation date, modified date or alphabetically in ascending or descending order. A summary of each layer was displayed with hyperlinks to the layer detail page (see Figure 11 ).

For future testbed efforts, it is suggested to work on the alignment with the SRIM Profile for Layer and Map used for search and discovery of layers in the Semantic Registry. Additional fields such as subject, theme, layer classification using semantic concepts may be useful to support better semantic search of layer information in the faceted search. There is also a need to investigate synchronization mechanisms between the layers managed by the Semantic Portrayal Service and the Semantic Registry.

To demonstrate the rendering of layers and legend, a detailed page for a layer was implemented. It displays basic metadata about the layer, data source, the style information and legends. The graphic glyphs associated with each style were rendered on the server side using the symbolizer renderer endpoint. The layer display was reprojected and rendered using the server-side layer renderer endpoint implementing the WMS GetMap operation. Figure 12 illustrates the display of City of New York Police Precincts Layer with an OpenStreetMap base layer using Leaflet Web Map Client. The UI allows the user to modify the current style of the layer by providing a symbolizer search functionality and apply the symbolizer interactively using the server-side layer renderer. The customized layer could be cloned and saved by the client.

More advanced styling capabilities will need to be investigated in future testbeds by testing the application of relevant portrayal rules that are based on feature data attributes. The handling of coverage/image layers and styles specific to coverage layers should also be investigated.