This article describes the installation and configuration procedure for an OGC WMS, WCS or WFS server. Once you have created a command dispatcher factory with the API, you can install and start a server.

## Installing a command dispatcher factory

To install a command dispatcher factory class, it must be copied into the servlet container’s classpath, along with any associated classes. These classes may be copied to the `WEB-INF/classes` subdirectory. Alternatively, the classes may be packaged into a JAR file and installed in the `WEB-INF/lib` subdirectory. Any required external libraries also have to be installed there.

Configure the LuciadLightspeed OGC servlet to use your command dispatcher factory by setting a servlet parameter in the deployment descriptor. The deployment descriptor is explained in Configuration of the deployment descriptor. Before you can run the servlet code with the LuciadLightspeed end user license, the code has to be obfuscated. Preserve the name of your command dispatcher factory class in the obfuscation process so that it can be instantiated by the servlet.

### Automating the build process

The procedure outlined above can be automated using a Java build tool, such as Ant. The LuciadLightspeed OGC web server distribution provides example Ant build scripts. You can find these scripts in the `wms`, `wcs` and `wfs` subfolders of the `build` folder. Th scripts are capable of creating ready-to-deploy servlets, starting from the source code of an OGC web server. The scripts are configured for the server samples, but it can be extended for custom web servers. The script contains four major targets:

• build_deployment_war: this is the default target when running the script. It builds a servlet package that requires an end user license to run. The target compiles the server sample code, obfuscates it together with the necessary libraries and builds a servlet package archived into a `WAR` file. This `WAR` file can be installed into a servlet container.

The free tool Proguard[1] is used for the obfuscation process. A sample configuration script for this tool, specific for obfuscating a OGC server, is available in `build/ogc/luciad_ogcservice.pro`. More information about obfuscation can be found in `docs/technicalnotes.html` in the LuciadLightspeed distribution.

You can find details about what assumptions the build scripts make and how they can be adapted in the top comments of `build/ogc/deploy_ogc_server.xml`. A set of configuration options are also available in the files `build/ogc/deploy_ogc_service.properties`.

The Ant tool is shipped with the LuciadLightspeed OGC web server distribution. The free tool Proguard[2] is used for the obfuscation process. You need to download it and put the `proguard.jar` in the folder `build/proguard`. Once you have downloaded and put proguard at the right location you can be start the build script by using the `build/ogc/deploy_ogc_service`.

## Configuration of the deployment descriptor

The deployment descriptor of a servlet is an XML file that describes how to deploy a module or application by specifying configuration and container options. The file is named `web.xml` and is present in the `WEB-INF` directory, directly under the web application root.

### Configuring the context parameters of the deployment descriptor

#### Performance for client applications using tiled requests

A tile cache can be configured to improve the performance subsequent Tiled WMS requests. This tile cache is not used for (regular) WMS requests. As a simple heuristic it is used for requested images that have a size that is smaller than 300 by 300 pixels. It is a two-tier cache that uses an in-memory buffer with a (non-persistent) disk overflow. The cache is configured as part of the servlet context, which means that it can be reused across multiple ervlet instances when in the same process. It can be configured by using the following servlet context parameters (`context-param` in `web.xml`).

`memory-cache-size`

The memory tile cache size in MB. Default is 10% of the max heap size. Can be 0.

`disk-cache-size`

The disk tile cache size in MB. Default is "memory-cache-size x 100". Can be 0.

`disk-cache-path`

The disk tile cache path. Also supports paths starting with `${java.io.tmpdir}` or `${user.home}`. Default is `\${java.io.tmpdir}/ogc`.

### Configuring the WMS deployment descriptor

In the context of the LuciadLightspeed WMS, the deployment descriptor contains several parameters that are used by `ALcdOGCWMSCommandDispatcherFactory` to initialize a `ALcdWMSCommandDispatcher` instance:

#### command.dispatcher.factory.class

This parameter defines the command dispatcher factory that is used by the LuciadLightspeed WMS servlet. Its value must be a fully qualified class name.

#### wms.capabilities.cfg

The parameter `wms.capabilities.cfg` defines the file containing the capabilities of the server. As described in Configure a WMS server, this file name is supplied to the capabilities decoder.

#### crs.epsg.cfg, crs.auto.cfg, crs.auto2.cfg

The deployment descriptor may contain three parameters that are related to the coordinate reference systems published by the WMS server. The use of these parameters is optional. If not defined a list of widely used CRS codes is generated. These parameters define the files containing the supported spatial reference systems:

`crs.epsg.cfg`

This file contains the conversion of EPSG to Well-Known Text. Coordinate systems in the EPSG namespace that are not needed in the WMS can be removed from this file.

`crs.auto.cfg`

This file lists all supported AUTO projections. Projections that are not needed in the WMS can be removed from this file.

`crs.auto2.cfg`

This file lists all supported AUTO2 projections. Projections that are not needed in the WMS can be removed from this file.

By default, these files are available in the directory `WEB-INF/classes`. The class `ALcdOGCWMSCommandDispatcherFactory` decodes the available spatial reference systems and adds them automatically to the `ALcdWMSCapabilities` instance that is returned by the capabilities decoder. See Configure a WMS server.

This parameter defines whether the String `LuciadLightspeed` must be added to the list of spatial reference systems in the capabilities. The `LuciadLightspeed` reference system indicates that a client can format the CRS parameter in a request with `TLcdLuciadMapReferenceFormatter`, which is capable of formatting any possible reference implementation based on `ILcdXYWorldReference`. This can be useful if you are working with Luciad client software in combination with custom spatial reference systems that do not have an official EPSG, AUTO or AUTO2 code representation.

#### settings.cfg

The method `configureSettings()` in `ALcdOGCWMSCommandDispatcherFactory` is used to apply general configuration settings in LuciadLightspeed . The default implementation retrieves these settings from a properties file defined by the parameter `settings.cfg`. By default, the file is named `settings.cfg` and is available in the directory `WEB-INF/classes`. The following properties are included:

• JAI.tile.cache.size.mb: the cache size of tiles for JAI (in MB).

### Configuring the WCS deployment descriptor

In the context of the LuciadLightspeed WCS, the deployment descriptor contains several parameters that are used by `ALcdOGCWCSCommandDispatcherFactory` to initialize a `TLcdWCSCommandDispatcher` instance:

#### ogc.command.dispatcher.factory.class

This parameter defines the command dispatcher factory that is used by the LuciadLightspeed WCS servlet. Its value must be a fully qualified class name.

#### wcs.coverages.cfg

The parameter `wcs.coverages.cfg` defines the file containing the coverage offerings of the server.

### Configuring the WFS deployment descriptor

In the context of the LuciadLightspeed WFS, the deployment descriptor contains several parameters that are used by `ALcdOGCWFSCommandDispatcherFactory` to initialize a `TLcdWFSCommandDispatcher` instance:

#### wfs.command.dispatcher.factory.class

This parameter defines the command dispatcher factory that is used by the LuciadLightspeed WFS servlet. Its value must be a fully qualified .

#### wfs.featureTypeList.cfg

The parameter `wfs.featureTypeList.cfg` defines the file containing the feature type list of the server.

#### wfs.defaultMaxFeatures

The parameter `wfs.defaultMaxFeatures` defines the maximum amount of features which will be returned for a GetFeature request in case the client does not specify the number of features which should be returned. Without this parameter, the server will always return all of the features of a given type in case no other filter is set. This can be problematic in case the number of features for a given type is very high.

#### wfs.schemaLocations.cfg

The parameter `wfs.schemaLocations.cfg` defines the file name of a properties file which maps xml namespaces to schema locations. If this parameter is not set, the server will try to use locally stored schema files. It is also possible to add new namespaces to this file.

#### wfs.10.schemaLocations.cfg

The parameter `wfs.10.schemaLocations.cfg` defines the file name of a properties file which maps xml namespaces to schema locations. These namespaces will be used for WFS version 1.0.0. A separate configuration file is required for this version because the WFS 1.0.0 and WFS 1.1.0 use the same namespaces, even though the schema’s are entirely different. Otherwise, this parameter is entirely similar to the `wfs.schemaLocations.cfg` parameter.

#### wfs.enableLocking

The parameter `wfs.enableLocking` defines whether the server should support locking of features or not. Locking is used in transactional WFS servers to allow users to lock features before changing them. Do note that locking is not necessarily required in case the server supports atomic transactions, which is the case for the default implementation. By default this parameter is set to 'false', it should only be enabled if locking is absolutely required. Set this parameter to 'true' to enable locking.

#### wfs.enableTransactions

The parameter `wfs.enableLocking` defines whether the server should support transactions or not. When transactions are enabled, you can change the data on the server. By default, this parameter is set to 'false', setting it to 'true' will enable transactions. Transactions support also requires that you implement an `ILcdWFSServerModelEncoderFactory`, or an `ALcdWFSTransactionHandler`.