To simply load and visualize data from a WMS, you can create a model through
Using a proxy model
LuciadLightspeed uses proxy models for connections with OGC services. When added to a layer in a view, they automatically obtain the data (features, images …​) from the OGC service, making the service connection transparent to the user. The OGC client APIs create these proxy models by default, using a data source and model decoder.
To support customization possibilities, the OGC clients offer additional API related to the proxy model. Examples include the configuration of constraints on what data should be retrieved or which data exchange format should be used.
Exploring and configuring a WMS proxy model
A decoded WMS model has a model descriptor of type
This can be used to recognize an
ILcdModel representing a connection with a WMS service.
The model contains a single element of type
ALcdWMSProxy, which acts as proxy towards the service.
The proxy object has a double role, which is illustrated in Figure 1, “Main classes of the WMS Client API”.
On the one hand, the proxy object provides access to the available WMS layers published in the capabilities of the service. The available layers are structured in a hierarchical list, of which
the root can be obtained through the method
This method takes an index, to support multiple layer roots. Although the WMS specification essentially defines the existence of one layer root, this flexibility has been added to increase interoperability with WMS services that do not adhere to this requirement. In general however, there is only one layer root and 0 can be supplied as index.
The result of this call is an
ALcdWMSNamedLayer, which is a representation of a WMS named layer. An
ALcdWMSNamedLayer can itself be composed of other
ALcdWMSNamedLayer objects, according to the "Composite" design pattern of the GoF (Gamma et al., "Design Patterns"). Note that instances of
ALcdWMSNamedLayer that are composed of other
ALcdWMSNamedLayer objects do not always have a name,
null for example. In that case, the composed
ALcdWMSNamedLayer is only a category or logical group
for all the layers nested within. It cannot be used in requests.
On the other hand, the proxy object provides you with a way to select and configure one or more WMS layers that should be
visualized on the map. You can do this by adding an instance of
TLcdWMSStyledNamedLayerWrapper to the
ALcdWMSProxy for each
that should be included in the view.
TLcdWMSStyledNamedLayerWrapper can also contain an
ALcdWMSNamedLayerStyle. This represents the style that is used to represent the
ALcdWMSNamedLayer. If no
is set on the
TLcdWMSStyledNamedLayerWrapper, the default style will be used.
The number of possible
ALcdWMSNamedLayerStyle objects for a
ALcdWMSNamedLayer can be retrieved with the method
ALcdWMSNamedLayerStyle can be retrieved with the method
In the hierarchy of
ALcdWMSNamedLayer objects an
ALcdWMSNamedLayer can also be represented with an
ALcdWMSNamedLayerStyle of one of its ancestors.
The total number of possible
ALcdWMSNamedLayer (i.e., including the styles from the ancestors)
can be retrieved with the method
getNamedLayerStyleCount; the _n_th
can be retrieved with the method
Specifying dimensional parameters
A WMS server can define one or more dimensions for a layer, to allow support
for multi-dimensional datasets. The available dimensions for a layer can be retrieved through the methods
A dimension itself is represented by
ALcdOGCWMSDimension, which contains all
the dimension-related parameters, such as the name, the unit, etc. The available values or intervals for an
ALcdOGCWMSDimension are represented by
To specify dimensional parameters in a request, an instance of
TLcdOGCWMSDimensionWrapper must be
created for each desired dimension. This class holds two objects:
ALcdOGCWMSDimensionrepresenting the dimension that must be included in a request.
TLcdOGCWMSDimensionExtentrepresenting the value(s) or interval(s) that are defined by the client for the specified dimension.
After they have been properly initialized, you must add the
TLcdOGCWMSDimensionWrapper objects to
ALcdWMSProxy , using
addDimension(TLcdOGCWMSDimensionWrapper) and related methods, to have them included in subsequent requests. As defined by the WMS specification, the dimensional parameters
in a request are not directly linked with a layer. Instead, the server itself determines which dimensional parameters apply
to which layer.
Setting an exception handler
It is possible to set an
ILcdExceptionHandler on the proxy using the method
setExceptionHandler(). This makes it possible to intercept exceptions that occur during communication with the server, and handle them appropriately.
Performing a FeatureInfo request
ALcdWMSProxy offers more high-level API to perform FeatureInfo requests. See
createFeatureInfoInputStream(TLcdWMSGetFeatureInfoContext) for more information. You can retrieve the
TLcdWMSGetFeatureInfoContext argument from the layers that are used to paint the WMS data. The context argument makes it possible to perform FeatureInfo
requests that correspond exactly with what is shown in the view. See:
TLspWMSGetFeatureInfoContextQueryfor Lightspeed views.
TLcdGXYTiledWMSProxyPainterfor GXY views.
For a demonstration, see
WMSGetFeatureInfoMouseListener in the WMS client samples.