The OGC Web Server Suite is an API to create your own OGC Web Server for WMS, WFS-T, WCS, and CSW services, and tailor it to your needs.

The Suite offers dedicated articles to help you develop your OGC Web Server for each of the service types. See Configure a WMS server, Configure a WFS server, Configure a WCS server and Configure a CSW server.

This article describes the procedure for deploying the OGC Web Server that you developed.

Configuring the servlets

The web services in the OGC Web Server Suite (WMS, WFS, WCS, CSW) are defined as Java servlets, which can be configured through annotations. The samples include an example for each of the service types:

  • WMS: samples.wms.server.WMSServlet

  • WFS-T: samples.ogc.wfs.server.WFSServlet

  • WCS: samples.ogc.wcs.server.WCSServlet

  • CSW: samples.csw.server.CSWServlet

Each service requires you to configure the command dispatcher factory, which fully initializes a service.

The following sections discuss the available configuration parameters for each service in more detail.

WMS configuration parameters

command.dispatcher.factory.class

This parameter defines the command dispatcher factory that is used by the 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

These parameters refer to files that respectively define the EPSG, AUTO and AUTO 2 spatial reference systems that the WMS must support. You can remove unneeded spatial reference systems from the files.
The use of these parameters is optional. If you do not define them, a list of widely used spatial reference systems is used.

crs.luciadmap

This parameter defines whether the String LuciadMap must be added to the list of spatial reference systems in the capabilities. The LuciadMap reference system indicates that a client can format the CRS parameter in a request with TLcdLuciadMapReferenceFormatter. That formatter 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 parameter settings.cfg defines the Properties file that contains a JAI-related configuration setting:
JAI.tile.cache.size.mb: the cache size of tiles for JAI (in MB).

WFS configuration parameters

wfs.command.dispatcher.factory.class

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

wfs.featureTypeList.cfg

The parameter wfs.featureTypeList.cfg defines the file with the list of feature types offered by the server.

wfs.defaultMaxFeatures

The parameter wfs.defaultMaxFeatures defines the maximum number of features returned for a GetFeature request without a feature limit. Without this parameter, the server always returns all features for the requested feature type if no other filter is set. This can be problematic if the number of features for a given feature type is very high.

wfs.schemaLocations.cfg

The parameter wfs.schemaLocations.cfg defines the file name of a properties file that maps XML namespaces to schema locations. If this parameter is not set, the server tries to use locally stored schema files. You can also add new namespaces to this file.

wfs.10.schemaLocations.cfg

The parameter wfs.10.schemaLocations.cfg defines the file name of a properties file that maps XML namespaces to schema locations. These namespaces are used for WFS version 1.0.0. A separate configuration file is required for this version because WFS 1.0.0 and WFS 1.1.0 use the same namespaces, even though the schemas are different.

wfs.enableLocking

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

wfs.enableTransactions

The parameter wfs.enableTransactions 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 enables transactions. Transactions support also requires that you implement an ILcdWFSServerModelEncoderFactory, or an ALcdWFSTransactionHandler.

WCS configuration parameters

command.dispatcher.factory.class

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

wcs.coverages.cfg

The parameter wcs.coverages.cfg defines the file listing the coverages offered the server.

CSW configuration parameters

csw.command.dispatcher.factory.class

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

csw.insertEmptyValues

The parameter csw.insertEmptyValues defines whether missing property values must be replaced with empty, non-null values. By default, this is set to false.

csw.versions

The parameter csw.versions defines the supported versions using a comma-separated list. By default, this is 2.0.2,3.0.0.

csw.profiles

The parameter csw.profiles defines which additional metadata profiles must be supported, iso and/or inspire, using a comma-separated list. By default, this is empty.

csw.dataDir

The parameter csw.dataDir defines a folder containing individual metadata records to be read. By default, this is Data/csw.

Cache configuration for tiled requests

By default, the WMS and WCS services use a tile cache to improve the performance of consecutive tiled WMS and WCS requests. This tile cache is not used for regular WMS and WCS requests. To restrict caching to tiled requests, the OGC Web Server uses the cache only for requested image and raster data with a size smaller than 300 by 300 pixels. It is a two-tier cache that uses an in-memory buffer with a (non-persistent) disk overflow. You can configure the cache using these parameters:

memory-cache-size

The memory tile cache size in MB. The default is 10% of the max heap size. The value can be 0.

disk-cache-size

The disk tile cache size in MB. The default is "memory-cache-size x 100". The value can be 0.

disk-cache-path

The disk tile cache path. It also supports paths starting with ${java.io.tmpdir} or ${user.home}. The default is ${java.io.tmpdir}/ogc.

Configuring the license

To run a deployed server, you need a deployment license. You can put this in the licenses folder.

Building and packaging the server

You can build and package a developed server with the deploy_ogc_service Ant build script available in the build/ogc folder. The script is capable of creating a ready-to-deploy Web application ARchive(WAR) file.

The script’s main target build_deployment_war compiles the WMS, WFS, WCS and CSW server sample code, obfuscates it together with the necessary libraries, includes the deployment license from the licenses folder, and packages everything together in a WAR file in the distrib/ogc folder.

The free tool ProGuard[1] is used for the obfuscation process. You can install ProGuard by following the instructions in this article. The configuration for the obfuscation is defined in build/proguard/luciad_ogcservice.pro.

For details about what assumptions the build script makes and how you can adapt them, see the top comments in build/ogc/deploy_ogc_server.xml. A set of configuration options is also available in the file build/ogc/deploy_ogc_service.properties.

The data configuration file for the sample WMS server, config/samples/ogc/server/wms.capabilities.cfg.xml, uses a relative path to point to the sample data folder. If you keep using this configuration file in your developed server, you must make this path absolute to ensure that the servlet container or application server can find the data.

Open the file and find the Folder element: 

<MapData>
<Folder>samples/resources</Folder>
</MapData>

Update the contents of the Folder element so that it contains an absolute path to the corresponding folder in the root of your product installation.

Deploying the server

You can install the created WAR file in a servlet container or application server of your choice. The OGC Web Server Suite is based on version 3.1 of the Servlet API, and is compatible with any servlet container or application server supporting version 3.1 or higher.