The LuciadLightspeed WMS Server API offers support for the OGC Styled Layer Descriptor specification. By default, a server accepts requests that make use of an SLD to define user styles. Through the API, you can further customize the behavior.
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. Customizing SLD support in the WMS explains how the SLD support in the WMS server can be customized. 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. For more information about the FeatureTypeStyle
styling model, see Styling data with OGC SLD. 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
. For more information about the usage of this framework,
see Integrating XML data into your application. 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.
Customizing SLD support in the WMS
As indicated in Configure a WMS server, the WMS server relies on
an implementation of ALcdOGCWMSCommandDispatcherFactory
. Its default implementation TLcdOGCWMSCommandDispatcherFactory
comes with out-of-the-box support for user-defined SLD styling. You can extend this class to customize this and to include
support for user-defined SLD layers (with user-defined data), GetLegendGrahphic
and DescribeLayer
requests. The following paragraphs describe the methods that you can use for this in more detail.
Adding user-defined styling support: createWMSGXYLayerFactories()
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:
-
A layer factory method to create layers for named layers with named styles, which corresponds to the classic usage of a WMS.
-
A layer factory method to create layers for named layers with user styles.
-
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.
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: createRemoteOWSModelDecoderFactories()
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. For more information about limitations regarding this implementation, see Styling data with OGC SLD.