The LuciadLightspeed WMS Server API offers support for the OGC Styled Layer Descriptor specification. A server can be configured to accept requests that make use of an SLD to define user styles or user layers.

In a WMS server without SLD support, a client can only use the named layers and their (optionally) corresponding named styles that are defined in the capabilities. When integrated with the WMS, the SLD language offers clients the possibility to include user-defined styles and/or data layers in their requests. For example, if a WMS offers a vector layer showing roads and rivers, a client could retrieve a map showing this data using a custom defined color scheme. Even more, an SLD-enabled WMS can allow clients to include user-defined data layers in requests, asking the WMS to retrieve data from another WFS or WCS server and rendering it with a user-defined style. In fact, a WMS server could be implemented that does not contain any data itself, but only serves as a portrayal engine that renders data coming from other OGC servers, such as a WFS or WCS.

Styling model introduces the styling model in LuciadLightspeed that is used to represent an SLD. The WMS server uses this styling model internally. To convert the XML representation to the styling model and the other way around, the WMS API offers a decoder and encoder, which are described in Decoding/Encoding. Next to its use in the WMS server, these components can also be useful at the client, for example to construct an SLD programmatically within a graphical editor and encode it into a WMS request. Creating an SLD-enabled WMS explains how a WMS server can be built that accepts SLD requests. Finally, Limitations lists the limitations of the current implementation of SLD.

Styling model

The OGC Styled Layer Descriptor specification comprises XML Schema files describing the styling model and how it should be stored in XML files. The package ogc.sld.model in LuciadLightspeed contains a Java translation of the XML Schema for the FeatureTypeStyle element. More information about the FeatureTypeStyle styling model can be found in the LuciadLightspeed Developer’s Guide. The package wms.sld.model is built upon this styling model and contains a Java translation for the StyledLayerDescriptor element, which is used within a WMS.

Decoding/Encoding

Because the SLD language is defined as an XML format, the WMS API provides a decoder and encoder to convert the XML format to the styling model and the other way around. The package ogc.sld.xml contains a decoder, TLcdSLDStyledLayerDescriptorDecoder, which decodes XML files with StyledLayerDescriptor as the top element to a TLcdSLDStyledLayerDescriptor object. The decoder is built using the LuciadLightspeed XML decoder framework that is located in the package com.luciad.format.xml. More information about the usage of this framework can be found in the LuciadLightspeed Developer’s Guide. The XML decoders are accessible through the class TLcdSLDStyledLayerDescriptorDecoderLibrary. This allows the user of the API to reuse them and integrate them in another decoder built with the LuciadLightspeed XML decoder framework. This may be necessary to decode XML files that contain a StyledLayerDescriptor element as a child element.

Analogously, TLcdSLDStyledLayerDescriptorEncoder encodes a TLcdSLDStyledLayerDescriptor object to an XML file. The encoder is built using the LuciadLightspeed XML encoder framework that is located in the package com.luciad.format.xml. The XML encoders are accessible through the class TLcdSLDStyledLayerDescriptorEncoder, which makes it possible to reuse them in another encoder built with the LuciadLightspeed XML encoder framework.

Creating an SLD-enabled WMS

The user of the API must provide an implementation of ALcdOGCWMSCommandDispatcherFactory (or an extension of TLcdOGCWMSCommandDispatcherFactory) to create a WMS server. To offer support for SLDs extra methods from the ALcdOGCSLDWMSCommandDispatcherFactory need to be implemented as they have no default provided implementation. The extra factory methods allow the user to provide special encoders, decoders and layer factories for user-defined data and styling.

Handling of the incoming requests in an SLD-enabled WMS is done by the default TLcdOGCWMSCommandDispatcher. To create an SLD-enabled WMS server, the user must only provide an implementation of ALcdOGCWMSCommandDispatcherFactory. The following paragraphs describe the extra configuration methods defined by this class in more detail.

Adding user-defined styling support: createSLDWMSGXYLayerFactories()

To provide support for user-defined styling, the WMS server uses ALcdSLDWMSGXYLayerFactory, which is an extension of the regular ILcdWMSGXYLayerFactory. This class introduces three layer factory methods, each for a different purpose corresponding to the possibilities in an SLD WMS request:

  1. A layer factory method to create layers for named layers with named styles, which corresponds to the classic usage of a WMS.

  2. A layer factory method to create layers for named layers with user styles.

  3. A layer factory method to create layers for user layers with user styles.

Please refer to the reference documentation for more details about the usage of these methods. The SLD command dispatcher factory must provide an array of one or more valid implementations, in order to support user-defined styling.

Note that the default implementation of createWMSGXYLayerFactories()() uses the service look-up mechanism for available layer factory implementations. As ALcdSLDWMSGXYLayerFactory is an extension of ILcdWMSGXYLayerFactory they are picked up automatically as well when they annotated as ILcdWMSGXYLayerFactory.

Adding user-defined layer support: createRemoteModelDecoderFactories()

In addition to using predefined layers in the WMS server, an SLD-enabled WMS server can allow a user to define custom layers for rendering. Through an SLD, the user can specify a number of features that are assumed to be fetched from an OGC Web Feature Service or Web Coverage Service. To support the decoding of data from a remote server, the WMS server uses an ILcdRemoteOWSModelDecoder. Instances of this type are created in the WMS through the factory ILcdModelDecoderFactory. The SLD command dispatcher factory can provide an array of one or more valid remote model decoder factories. This is not mandatory, as this functionality is optional for an SLD-enabled WMS server.

Adding GetLegendGraphic support createWMSGetLegendGraphicEncoders()

The GetLegendGraphic request is introduced by the OGC SLD specification and is considered as an optional request for an SLD-enabled WMS. It provides a general mechanism for acquiring legend symbols. This request can be used by a client application to construct a meaningful legend for a map. To create and encode the result of a GetLegendGraphic request, the WMS server uses the interface ILcdWMSGetLegendGraphicRequestEncoder. Each ILcdWMSGetLegendGraphicRequestEncoder is associated with one output format, which is specified as a MIME type through the method getContentType(). Creating and encoding the legend graphic is left to the implementation of ILcdWMSGetLegendGraphicRequestEncoder: the encode() method supplies the necessary parameters.

The default implementation of createWMSGetLegendGraphicEncoders() does not create any encoders, because the GetLegendGraphic request is optional for an SLD-enabled WMS. To offer support for the GetLegendGraphic request, an implementation of createWMSGetLegendGraphicEncoders() must return one or more valid encoders. Furthermore, the capabilities of the server should reflect that support for the GetLegendGraphic request is offered: this must be done by adding one or more available output formats for the GetLegendGraphic request.

Adding DescribeLayer support: createWMSDescribeLayerEncoders()

The DescribeLayer request is introduced by the OGC SLD specification and is considered as an optional request for an SLD-enabled WMS. It allows clients to obtain feature/coverage-type information for named layers. This information is useful to create user-defined styles at the client: because an SLD allows to style parts of the data differently depending on some feature, a client needs to find out which features are available in the data.

To create and encode the result of a DescribeLayer request, the WMS server uses the interface ILcdWMSDescribeLayerRequestEncoder. Each ILcdWMSDescribeLayerRequestEncoder is associated with one output format, which is specified as a MIME type through the method getContentType(). Creating and encoding the response is left to the implementation of ILcdWMSDescribeLayerRequestEncoder: the encode() method supplies the necessary parameters. Because the OGC SLD specification defines a default XML format for DescribeLayer responses[1], an abstract implementation ALcdWMSDescribeLayerRequestEncoder exists that already implements the methods getContentType() and encode(). To construct the full response, it introduces a few protected methods for which the implementation is left to the user.

The default implementation of createWMSDescribeLayerEncoders() does not create any encoders, because the DescribeLayer request is optional for an SLD-enabled WMS. To offer support for the DescribeLayer request, an implementation of createWMSDescribeLayerEncoders() must return one or more valid encoders. Furthermore, the capabilities of the server should reflect that support for the DescribeLayer request is offered: this must be done by adding one or more available output formats for the DescribeLayer request.

Limitations

The following OGC SLD requests for an SLD-enabled WMS are optional, and are currently not supported: GetStyles and PutStyles.

The SLD styling model itself is internally implemented by the painters in LuciadLightspeed . Please refer to the LuciadLightspeed Developer’s Guide for more information about limitations regarding this implementation.