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