deegree Web Processing Service v2.3

lat/lon GmbH

Aennchenstr. 19

53177 Bonn


Tel ++49 - 228 - 184 96-0

Fax ++49 - 228 - 184 96-29

Dept. of Geography

Bonn University

Meckenheimer Allee 166

53115 Bonn

Tel. ++49 228 732098

Change log





Initial Document setup

Christian Kiehle


Document finalized

Christian Kiehle


Update to v2.3

Sebastian Goerke

Table of Contents

1 Introduction 3

2 Download / Installation 5

3 Architecture 7

4 Configuration 8

5 Implement your own process 10

6 References 11

Index of Tables

Table 1: Directory structure of the WPS release 5

Illustration Index

Figure 1: deegree WPS architecture overview 7

Figure 2: Files affecting the deegree WPS configuration 8

1 Introduction

deegree is a Java Framework offering the main building blocks for Spatial Data Infrastructures (SDIs). Its entire architecture is developed using standards of the Open Geospatial Consortium (OGC) and ISO Technical Committee 211 – Geographic information / Geoinformatics (ISO/TC 211). deegree encompasses OGC Web Services as well as clients. deegree is Free Software protected by the GNU Lesser General Public License (GNU LGPL) and is accessible at

deegree2 is the new release of deegree supporting a number of features that deegree1 was not able to handle. This documentation describes setup and configuration of the deegree Web Processing Service (WPS), an implementation of OGC's Web Processing Service Deprecated Request for Comments Version 0.4.0 (OGC Document # 05-007r4).

deegree's WPS is able to process Feature Collections based on arbitrary processes. OGC's WPS (Schut & Whiteside 2005) specification describes WPS as follows: “WPS defines a standardized interface that facilitates the publishing of geospatial processes, and the discovery of and binding to those processes by clients. “Processes” include any algorithm, calculation or model that operates on spatially referenced data. “Publishing” means making available machine-readable binding information as well as human-readable metadata that allows service discovery and use.

Therefore the following WPS requests are supported:

Although WPS is not restricted to serve processes based on spatial and/or temporal data it is meant to be a specification for processing mainly spatial and/or temporal data.

The WPS Server acts as a container for an unlimited number of processes. The relation of a WPS Server to a WPS process comprises the same relation as the WMS Server to a WMS Layer.

Besides the WPS, deegree comprises a number of additional services and clients. A complete list of deegree components can be found at: Products

Downloads of packaged deegree components can be found at: Download

deegree's Web Processing Service offers great flexibility regarding it's configuration and output formats. Although the current implementation is only a basic implementation of the specification it is easily enhanced to process data beyond Feature Collections.

WPS, like any other web service of deegree, is realized as a Java module controlled by one central servlet (the “dispatcher”). This servlet has to be deployed to the respective web server/servlet engine. Most of the common web servers support servlet technology, thus making deegree a universal product. The Apache-Tomcat 5.5 Servlet-Engine is recommended due to its widespread use and its status as an open-source product.

Processes should be implemented using Java 1.5. Later versions of the Java programming language should work as well but will not be supported within deegree 2.2.

The WPS server API is – unlike data oriented services like WFS and WCS or portrayal oriented services like WMS and WPVS – mainly geared to software developers. This documentation is intended to get you quickly up and running a sample process (spatial buffer) and point you to the relevant parts of the API to implement your own processes with deegree.

2 Download / Installation

Running deegree2.2 Web Processing Service requires the following components to be installed:

For installation of these components refer to the corresponding documentation at and

deegree Web Processing Service can be downloaded from The release is packed as a WAR-archive. Simply put this file into your $TOMCAT_HOME$/webapps directory and (re-)start Tomcat. The installation of deegree WPS is already done with this.

Note: It is also possible to extract the WAR archive into another place of your computer and direct Tomcat to this place. Because of this possibility, in the remainder of this document, the directory you extracted the files to is referred to as $wps_home$ (=$TOMCAT_HOME$/webapps/deegree-wps in the standard case).

Your $wps_home$ will contain the following structure:




Required by Tomcat, containing all libraries, configuration- and data-files


XML configuration files for in-detail description of a process (input / output parameters, etc.)

    Table 1: Directory structure of the WPS release

After deploying the deegree-wps into Tomcat servlet container you should be able to access the URL http://localhost:8080/deegree-wps/

To ensure a successful deployment process you should request the capabilities of the service:


This link is provided within the generic client software through http://localhost:8080/deegree-wps/

Another HTTP-GET-based request is provided through the DescribeProcess interface. A process description is being returned by providing the process identifier of one or more processes. Process identifiers can be found inside the WPS Capabilities response inside the ProcessOfferings section. The preconfigured spatial buffer process is identified by 'buffer'. This results in the following DescribeProcess request:


The execute interface is only accessible through HTTP-POST and requires an XML payload in the request. An example can be found through the generic client interface.

3 Architecture

Figure 1 shows the overall architecture of the modules involved in the deegree WPS. The HTTP interface is realized by a servlet that has to be registered into a servlet engine like Tomcat or Jetty. The servlet chooses a handler class depending on the incoming request that delegates it to the responsible service (in this case the WPService). Depending on the requested processes the WPService decides which process is responsible for handling it. The central configuration document of the deegree WPS is based on a OGC WPS 0.4.0 capabilities document plus a few custom tags as well as a OGC WPS 0.4.0 process description document plus a few custom tags.

Figure 1: deegree WPS architecture overview

4 Configuration

Figure 2 shows the relationships between different configuration files that determine the behaviour of the deegree WPS.

Figure 2: Files affecting the deegree WPS configuration

The WPS-configuration/capabilities document and process configuration files will be described in detail in the following.

The format of the main configuration document of the deegree WPS is based on the OGC WPS 0.4.0 capabilities document plus a few custom elements. deegree-specific elements reside inside the deegree-Namespace (e.g. <deegree:deegreeParams>).


<deegree:DefaultOnlineResource xmlns:xlink="" xlink:type="simple" xlink:href="http://localhost:8080/wps_deegree/wps"/>







<deegree:ResponsibleClass>org.deegree.ogcwebservices.wps.execute.DefaultReq uestQueueManager</deegree:ResponsibleClass>



Within the <deegree:deegreeParams> the following options are configured:

Each process is described and configured by a process configuration xml file (as referenced inside the wps configuration document. Besides the definition of input/output data types (for details have a look at the WPS specification) there is a single deegree-specific parameter as well:

5 Implement your own process

The OGC Web Processing Service specification is intended mainly for developers of geoprocessing routines. It is assumed that you, before starting to build your own processes, have a good grasp on Java and XML. deegree WPS offers the basic building blocks to reflect the data types as defined inside the OGC WPS specification.

The starting point of any process development is the abstract class org.deegree.ogcwebservices.wps.execute.Process.

Process offers one public method with the signature

public abstract ProcessOutputs execute( Map<String, IOValue> inputs, OutputDefinitions outputDefinitions ) throws OGCWebServiceException;

A process implementation has to derive from this abstract class and provide an implementation of the execute method. Furthermore, for each process a process configuration document has to be provided and put into the processConfig directory. deegree will scan this document for the definition of the responsible class and register the to the WPS. As a developer, you do not have to take care about neither the describeProcess nor the GetCapabilities interface programmatically.

6 References

Schut, P.; Whiteside, A. (Eds.) (2005): OpenGIS® Web Processing Service. OGC 05-007r4. Online: