Introduction

High quality surfaces models play an important role in a range of geo applications, e.g. disaster management. Through newly available data acquisition techniques such as Airborne Laserscanner Data (ALS or Light Detection And Ranging, LiDAR) massive high-precision and spatial densly surface data enrich. Therefore high performance computing, storage capacity and datamanagement systems are required due to the increasing volume of available geo-data. For example hydrologists have specific requirements for inundation modelling, which is based on very exact surface data and preserve execution of time-consuming and very computationally intensive tasks. For acquiring, analyzing, refining and handling massive terrain data by using traditional desktop Geo-Information-Systems (GIS) rather than capturing account of the advantages of Spatial Data Infrastructure (SDI) or classical SOA-based geoprocessing services could hardly manage this. Anyway there is a need for more sophisticated data processing techniques. The processing of massive data is one of these open questions in GI Sciences (Geo-Information Sciences). Furthermore remote processing tasks and distributed data access should be done in a standardized way. An efficient usage and optimization of current existing IT resources are necessary. This is ensured by using Grid Computing technologies, which are standardized by the Global Grid Forum (GGF). The aim of a Grid system is connecting and accessing distributed data and enabling remote computations execution. This is aspired by developing open Grid infrastructures based on the principles of SOA and the Open Grid Service Architecture (OGSA), which takes the specification of the Web Service Resource Framework (WSRF) into account. In order to connect the GI community with the Grid community the OGC and the OGF (Open Grid Forum) are working together to specify interfaces, best practices and enhance existing Grid Computing and OGC standards. Therefore the OGF signed a memorandum of understanding to collaborate with the OGC. One objective of the collaboration is to integrate the OGC WPS standard with a range of back-end processing environments to enable large-scale processing. In order of particular interest of the Grid community we focus on the OGC WPS standard.

Linking Grid Computing infrastructure to OGC Web Services (OWS) is well suited to accomplish high processing performance and storage capacity and brings GI applications to a higher level raising new questions on service architecture, interfaces and best practices. We develop a variety of terrain processing services based on both OGC and Grid Computing standards. The huge amount of terrain data for Digital Elevation Model (DEM) generation as well as modelling spatial processes based on the DEMs require a vast demand on IT resources. Therefore the terrain processing services (Web Processing Service Terrain Framework) can be integrated as central component into a service architecture that manages and visualizes the 3D data. The potential of this terrain data is increased by the design of services for the preparation, fusion and processing, based on Grid technologies.

Furthermore, in approaching to the INSPIRE directive (passed in 2007) that aims to harmonize geospatial services for data access across Europe, our goal is to support the European environment policy taking the advantages of the benefits of SDI in combination with Grid Computing technologies for other sciences like hydrologists and noise or climate modeler. Additionally, scientists can use standard-conformal access to spatial data using OGC based Web Feature Services (WFS) or Web Coverage Services (WCS) using Grid resources interoperably into the context of INSPIRE SDIs.

The remainder of this contribution is structured as follows: Section “Related works” look forward to recent research works in the SDI and terrain algorithm domain. Section “Linking grid-computing to SDI” introduced to the OGC WPS specification and discusses the basic concepts of the Grid Computing technology and the differences between both. Section “Bridging the gap between OGSA and OWS” demonstrates the architecture and how these two technologies can work together. The next section presents our Web Processing Service Terrain Framework workflow for pre-processing algorithms for DEM and 3D data (section “Terrain web processing services”). We finish with a conclusion and an outlook to further activities.

Related works

A lot of research and implementations work has been done in GI Sciences and terrain processing field. In this section we give an overview of the state-of-the-art in both domains.

Geoprocessing in spatial data infrastructures

To avoid redundant data as well as to support data exchange based on standardized data formats and independent software the development of recent applications in Geo-Information Sciences (GI Science) and within the GI community takes place as Web services.

In the GI community, the Open Geospatial Consortium OGC, an international non-profit association of geospatial industries, government agencies and universities founded in 1994, participate in a consensus process to develop publicly available interface specifications, common standards and protocols to guarantee interoperability of data and services across a distributed network that become de facto standards. “OpenGIS® Specifications support interoperable solutions that “geo-enable” the Web, wireless and location-based services, and mainstream IT. The specifications empower technology developers to make complex spatial information and services accessible and useful with all kinds of applications.” (www.opengeospatial.org/ogc). Together with the Technical Committee 211 of the International Organization for Standardization (ISO/TC 211) scopes of common attention are defined to ensure harmonization of efforts and work closely on de jure standards for geographic information to represent and process spatial data.

Among others the occupation of the OGC deals with Spatial Data Infrastructures (SDI). Based on Service Oriented Architectures (SOA), SDI supports discovery, access to distributed geospatial data and use of geographic information (Nebert 2004). Until recently the OGC was engaged in particular with visualization (Web Map Service, WMS), vector (Web Feature Service, WFS) and raster data access (Web Coverage Service, WCS), beside the ability to search for spatial data (Catalog Service for the Web, CSW), whereas a recognized standard for distributed spatial data processing was missing for a long time (Kiehle et al. 2006). This issue was addressed by the development of a Web Processing Service (WPS), which has been approved as official standard by the OGC in December 2007 (OGC 2007). The WPS makes real processing functionality available. Providing in fact distributed spatial data processing functionality by real standardized Web services through the OGC WPS puts SDIs into a higher level. This allows developing more complex services using a standardized interface via the Internet by providing the possibility of performing arbitrary geospatial analysis and manipulation on geospatial data. Also wrapping existing off-line services as Web services within an SDI becomes possible (Brauner 2008).

Furthermore there is a rising demand to Web based geoprocessing. In particular within clients using conventional Web Map Services (WMS) more and more extended geoprocessing functionalities are integrated. One example for this is the OpenRouteService (www.openrouteservice.org). Amongst others this service offers the possibility to digitize areas interactively on the map, which are treated by the route service as to be avoided (Neis and Zipf 2008), further more calculation intensive operations include for example the calculation of AccessibilityAreas (Neis and Zipf 2007). Figure 1 shows a screenshot of the OpenRouteService. Within a Route Service request, an AvoidList is send to the user. The WPS calculates route geometries that shall be avoided and by-passed.

Fig. 1
figure 1

Screenshot of the OpenRouteService.org

Full size image

The WPS standard is rather generic. Due to this, different geoprocessing tasks can be disposed in diverse fields of geography research. Several examples for WPS implementations used for basic calculations like buffering, aggregation and spatial join calculations are described in (Heier and Kiehle 2005). Higher level and specialist processing services are presented by Stollberg and Zipf (2007, 2008) for housing marketing analysis and disaster management. Other examples of processing services are for simplification (Foerster and Schäffer 2007), precision farming (Nash et al. 2007), hydrological applications (Belger et al. 2006; Díaz et al. 2008), biogeography and global change research (Graul and Zipf 2008), forest fire (Friis-Christensen et al. 2007), and terrain tessellation and generalisation (Lanig et al. 2008).

Terrain data and processing

Terrain processing is an important factor in typical earth science applications. Producing high quality DEMs based on high-precision Airborne Laserscanner Data (ALS or LiDAR, Light Detection And Ranging) or massive SRTM (Shuttle Radar Topography Mission) datasets needs steadily rising computing challenging. For example through the acquisition of LiDAR terrain data, very large data sets result due to the high measuring point density. Typically the LiDAR system acquired from four up to 40 measure points per square meter. The SRTM-3 terrain data for Germany sums up to more than 44 million points and the fully topological Triangulated Irregular Network (TIN) would require at least 8 GB RAM plus spatial index data (Schilling et al. 2008). It takes approximately 14.5 h to process 20.000 tiles of SRTM-data on dual-core server.

Processing precise, massive terrain data implies the management of very large data sets. State-of-the-art to pre-process terrain data for visualizing is to tessellate the elevation data, store the resulting surface geometry as TIN and render the triangulated mesh using for example a view dependent error tolerance which managing the scene´s geometric complexity (view dependent Level of Detail, LOD). The constraints of terrain simplification in general could be the number of very important terrain points or the allowable accuracy loss. For the generation of view-dependent LOD the triangles are dynamically selected using the current time step´s view parameter and the view dependent error tolerance (Bao et al. 2004). Examples for continuous LOD algorithm with given error tolerance are (Lindstrom et al. 1996; Duchaineau et al. 1997; Balmelli et al. 1998; Rottger et al. 1998; Gerstner 1999; Pajarola et al. 2002). For out-of-core visualization Lindstrom and Pascucci (2002) describes rendering methods based on quadtrees.

One problem of processing massive terrain data is that it easily exceeds main memory storage capacity. Recent server technology is hardly capable of processing such an amount of terrain data. For this purpose sophisticated data processing techniques and customized algorithm are required. Our approach is to use the high processing performance and storage capacity of Grid Computing systems to process massive terrain data. Therefore we are currently developing several grid-based processing services for DEM with optimized processing algorithm (see section “Terrain web processing services”).

Linking grid-computing to SDI

OGC web processing service

The OGC WPS standard (version 1.0.0, passed in December 2007) offers web access to a variety of geoprocessing functionalities by a standardized interface. According to the specification a “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. … A WPS may offer calculations as simple as subtracting one set of spatially referenced numbers from another (e.g., determining the difference in influenza cases between two different seasons), or as complicated as a global climate change model. The data required by the WPS can be delivered across a network or available at the server” (OGC 2007).

The client posts the request via HTTP to the WPS server implementation using Key-Value-Pairs encoding (KVP) via HTTP GET or XML via HTTP POST. The server response is always formatted as XML document. The specification defines the communication between server and client by three mandatory types of request/response operations performed by a WPS. These request operations are:

  • getCapabilities: returns a brief service metadata document describing the resources of the specific server implementation, and gives a short description of each process offered by the KVP encoded requested WPS instance.

  • describeProcess: returns a detailed description of a process including its required input- (including the allowed formats) and output-parameter. The WPS describeProcess request performs either as a KVP encoded or optionally as XML document, chosen by a process identifier from the getCapabilities response document.

  • execute: runs the offered process by invoking the execute operation as an XML document request and returns the process results.

The data input and output can be simple literal values such as integer or double numbers as well as character strings (LiteralData), BoundingBox data structure like two pairs of coordinates or ComplexValue and ComplexValueReference that indicates complex data sets such as GML (Geography Markup Language) encoded fragments and raster, vector or other (large) data files. The data in the ComplexValue is part of the request/response document, whereas the ComplexValueReference handover the URL reference to the location, where the data can be downloaded. The input data can be managed by storing the data on the server and as part of or only referenced at the request document (Fig. 2).

Fig. 2
figure 2

WPS interfaces for our specific terrain processes

Full size image

The new WPS 1.0.0 standard introduced new features like SOAP (Simple Object Access Protocol) for exchanging XML-based messages over computer networks, and WSDL (Web Service Description Language) for describing Web services for request and response encoding for other specific computing platforms.

Adapting the OGC WPS to the Grid, means grid-enabling the OWS standards by complying with Web service standards based on W3C (SOAP, WSDL) in order to be interoperable with Grid services. Former work affected linking Grid technology with OGC Web services is done by Di et al. (2003, 2008). Currently there are two approaches for grid-enabling of a WPS. The “low-level gridification” of a WPS delegates the processing work to a grid job (Baranski 2008). In difference to this we aspire a “high-level gridification” of the WPS that provide a geospatial Grid service (WSRF service) by using Grid middleware.

Grid computing technologies

For determining whether system is a Grid, Forster proposes a three-point checklist. According to this a Grid system “coordinates resources that are not subject to centralized control using standard, open, general-purpose protocols and interfaces to deliver nontrivial qualities of services” (Foster 2002).

The objective of the Open Grid Service Architecture (OGSA) is to define an open and standardized architecture for grid-based applications to standardize all the services for job and resource management, security etc. by specifying a set of standard interfaces. Normally a Web services is stateless. The Web Service Resource Framework (WSRF) identifies and provides a set of operation that Web services may implement to become stateful services using Web service technologies (WS-Resource). The WSRF is the infrastructure on which the OGSA is built on. Encapsulated within the WS-Addressing endpoint reference and the WS-ResourceProperties, the identifier of the specific resources are included inside the client request as well as a simple URI address or complex XML content.

Following the IT mainstream, the underlying standards of the WSRF are WSDL and SOAP which are publicized by the W3C. Grid services are WSRF-based Web services integrated in Grid Computing infrastructure. To build WSRF compliant Grid applications the Globus Toolkit 4 (GT4) includes some high-level services for resource monitoring, discovery, job submission, security, and data management that we can use (Sotomayor and Childers 2006).

Grid security and delegation in globus toolkit 4

To share resources and services from different individuals, enterprises and organizations under a set of rules or policies a Grid defines a concept called the Virtual Organization (VO). Security and privacy is one of the major requirements using resources from several organizations to build a larger Grid within VOs. The Grid Security Infrastructure (GSI) enables the security challenges in Globus Toolkit 4 (GT4). The GSI implementation of the GT4 offers Transport- and Message-Level Security; certificates based authentication (CA) methods through X.509 to identify users or hosts, several authorization schemes, credential delegation and single sign-on and different levels of security for container, service, and resource.

The SOAP messages being transferred between different components are protected by Transport-Level Security to protect the transferred data using the Transport Layer Security (TLS) or by Message-Level Security (MLS) uses Web services based standards like WS-Security.

The GT4 toolkit supplies a delegation service to distribute jobs to remote Grids. To transport the credentials to any certain Web service under client security policy the client must tell this to the delegation service to delegate its credentials.

Execution management

Central component of the GT4 execution management is the Grid Resource Allocation and Management (GRAM) service that attends with the deployment, submission and monitoring of executable programs (jobs) and acts as an interface between Grid systems and the computational resources. In order to execute these functions, a job request is defined as Resource Specification Language (RSL) document and pass to the GRAM service, which derives necessary resources from the XML description and distributes the job to proper resources.

Workflow management

To manage distributed data and services, chaining of different processing functions and fusing different types of geospatial data are necessary. The workflow covers the chaining of several Web services from different kinds of technologies like OGC Web services, WSRF-based Grid services or conventional Web services. This includes the combination of atomic services, general or specific purpose services or composite services for specialized tasks. Service Orchestration means the portrayal of the interaction between Web services at message level, including the control flow and the data flow (Peltz 2003). XML-based Web services can be orchestrated by using the Business Process Execution Language (BPEL). To combine traditional OWS and Grid services the BPEL offers the resources to construct workflows, based on SOAP Web services. Grid jobs could be integrated in a BPEL process without converting to Grid services. Based on the ActiveBPEL engine a workflow will be able to integrate OWS using proxy Web services, store intermediate data in a PostGIS database, integrate WSRF-based Grid services, and job submission to a Web Service Grid Resource Allocation and Management (WS GRAM) (Fleuren and Müller 2008).

Differences between OGSA and OWS

Including SDI (based on OGC Web Service standards, OWS) within Grid Computing (based on Open Grid Service Architecture, OGSA) infrastructure is causing a couple of problems. The main differences between OGSA and OWS concern to:

  • Service Description: all OGC Web Services (OWS) implement the mandatory operation GetCapabilities for receiving a service description. On the other side, Grid services are described by the Web Service Description Language (WSDL).

  • Messaging: OWS communicate via the Hypertext Transfer Protocol (HTTP) methods GET (Key Value Pair, KVP) and POST. Grid services correspond by means of the Simple Object Access Protocol (SOAP).

  • Service Infrastructure: OWS are stateless services despite of Grid services that are stateful Web services based on the Web Service Resource Framework (WSRF).

  • Security: OWS implements actual so far none security mechanisms. In Grid infrastructure security is a very important point. The Grid middleware implements the Grid Security Infrastructure (GSI) which is responsible for authentication and authorization as well as credential management and delegation.

  • Data discovery & management: OGC supported data access based on Web Feature Service (WFS), Web Coverage Service (WCS) and discovery on Web Catalogue Service (CSW) whereas Grid services transfer large amount of data in different formats between hosts by GridFTP or OGSA Data Access and Integration (OGSA-DAI) framework and implements Information Services, referred to Monitoring and Discovery Systems (MDS) in Virtual Organizations (VO).

This fundamental differences leads to interoperability problems between OWS and grid-enabled WSRF services which are based on standards like SOAP and WSDL of the W3C. The OGC is aware of this drawback and started working on solutions. Lately approaches are developed to describe OGC Web services with WSDL and messaging with SOAP. Furthermore the Open Geospatial Consortium (OGC) and the Open Grid Forum (OGF) aspires the integration of OGC Web services and Grid services using common synergies through a common working group. So the first task is to achieve that OGC Web services and the WSRF-based Grid infrastructure can work together. Our contribution to the OGF is a proof of concept of the grid-enabled OWS in the terrain processing domain. In the following we focus on the OGC Web Processing Service (WPS).

Bridging the gap between OGSA and OWS

The fundamental components of the system architecture of the Grid-enabled WPS are shown in Fig. 3. The core functionalities rest within the WSRF-based Geo-Grid-Services. These services can be invoked by compatible clients using the Grid implied security mechanisms based on certificates (Foster and Kesselmann 2003).

Fig. 3
figure 3

General architecture overview of the grid-enabled terrain WPS (WN = Worker Node)

Full size image

Security aspects are fundamental in Grid infrastructures. Therefore both an appropriate user authentification, and communication with Grid resources by encrypted protocolls must occur. In order to ensure security, all authentification credentials from the client must be delegated by creating a temporary proxy certificate to the Grid service. The authentification effected via sending the user name and the password as parameters in WPS request. The authentification within the Grid infrastructure takes place automatically over a proxy server (MyProxy-Server, http://grid.nc-sa.uiuc.edu/myproxy), that store the user authentication credential.

As mentioned above, service communication in line with OWS differs from the general W3C compliant IT mainstream. Due to this the actual OGC WPS standard be extended and is now compatible with WSDL and SOAP (OGC 2007). The GT4 architecture requires W3C Web service standards to create WSRF-based Grid services.

The Web Processing Service (WPS) provides a generic interface to a variety of geospatial processes (especially in this case terrain processing functionality) by a standardized way. For this purpose the processing service is available via standard based OGC WPS interfaces getCapabilities, describeProcess and execute.

In order to access Grid resources, the implemented OGC WPS execute process operation is mapped to a corresponding WSRF-based Grid service (Geo-Grid-Service). To develop WSRF compliant Grid applications, we use the GT4 middleware.

The OGC WPS execute operation is full embedded into the Grid infrastructure as WSRF-based Grid service. The implemented process logic, like terrain triangulation, is embedded within the Geo-Grid-Service. The design of the process logic allows parallel process execution (e.g. using MPI or data partitioning techniques) on several worker nodes (WN).

Currently, several WPS frameworks based on the OGC WPS standard exisits. The developped terrain processing services rest on the deegree framework implementation (Fitzke et al. 2004). This Java framework offers the main building blocks for SDI, amongst other OGC Web Services (OWS) also the WPS in the version 1.0.0. The WPS process contains neither own process logic, but serves only for the delegation and passing the execute request to the Geo-Grid-Service. Thus the WPS acts in this case as a Grid client, which calls the implemented Grid service.

The “gridification” or “grid-enablement” of the process operation is realized by defining a WS-Resource (to create resources and a unique ID for resource identification and a Web service association by assigning a resources key), and a WS-Addressing (to exchange address information and commit a Web service endpoint (Endpoint Reference , EPR) within SOAP header). Each WPS execute process is mapped to the process identifier. To access the resource by the WS-Resource any data items (input and output) are mapped to the WSRF service resource property. Resource properties provide a view on the current state of the resource and store information towards service data values and metadata and information to manage the state. Thus it is possible to calculate distributed geoprocessing tasks and access data over stateless WPS (WSRF-WPS-Adapter). The execution of a process occurs via delegation of the external WPS to the WSRF service.

The terrain processing occurs as job execution on Grid clusters. Each cluster possesses a GRAM (Grid Resource Allocation and Management) service, which receives the jobs and distributes it on available worker nodes (WN) in the cluster. The GT4 Web Service GRAM (WS GRAM) is addressed like a normal Grid service. On the individual WN the Grid jobs run as executable files. Before the actual job starts, the necessary data have to be transported to the node (stage-in). Therefore the terrain data is spatially partitioned in one pre-processing step and afterwards transported on the individual worker nodes. If the terrain processing is successfully, the results are sent back to the WPS, which aggregates the terrain tiles and return the data as part of the response, or in facts of huge terrain data, only the URL reference where the results are stored back to the client.

If data is stored outside the Grid and must be accessed, then the WPS component alternatively could be replaced by another OGC service, e.g. WFS or WCS. For this, the mapping of Grid certificates onto other credentials must take place.

The WPS specification provides different possibilities for data access. The input parameters are passing through the execute request either as simple or complex literal value or as a complex value reference. Especially in the manner of processing massive raw terrain data, this data should be directly stored inside the Grid as flat files or in a PostGIS database. So the WPS access directly to the huge data within the Grid and is responsible for the data input (stage-in) and the storage of the results (stage-out). To access and integrate data in different formats on a Grid system we use OGSA-DAI (OGSA Data Access and Integration) middleware.

Terrain web processing services

In particular we are developing a range of services for processing 3D surface data. Terrain processing is done in four steps (see Fig. 4). First the massive terrain data is spatially tiled by the WPS PartitioningService. The second step is the triangulation of several tiles by the WPS GenericGeotessellationService. Next the WPS GeneralizationService generates different terrain LODs and the final step is post-processing and dissecting the data for visualizing by a mapping service (WPS ConverterService).

Fig. 4
figure 4

WPS terrain processing grid service architecture

Full size image

So that the implemented terrain processing services interact with each other we define a workflow for Web Service Orchestration (WSO). For service chaining both a WPS and a workflow engine can be used. To chain several Web services based on different technologies, BPEL is a good choice. Based on the ActiveBPEL engine a geospatial workflow is defined and can automatically execute from predefined Web services.

The parallelization of the geoprocessing tasks is achieved by dividing the data into smaller tasks using geometric partitioning. The 3D point cloud will be divided spatially into regular tiles using polygons as borders and processed on different worker nodes in the Grid by the WPS PartitioningService; the parts that lie outside the preferred region are discarded. The borders between the tiles are fixed.

The default tessellation implementation works on 2D space and based on the Delaunay Triangulation (DT). To reconstruct surface features like dikes e.g. for hydrological simulations, a modified Delaunay algorithm that incorporates the measurement of the surface curvature has been implemented. Additionally to the Delaunay condition also the local curvature, this is measured by multiplying the angle between the adjacent triangles at an edge with the edge length, as an additional factor take into account. The TIN surface becomes smoother by minimizing the curvature value (WPS GenericGeotessellationService).

Further tasks include mesh reduction in order to reduce the geometrical complexity and polygon-in-mesh integration that cut 2D polygons into the TIN. To enable an efficient visualization and provide different generalization grades of terrain data we distinguish components for processing multi-resolution terrain. Based on an iterative generalization of edge aggregation by vertex pair contraction, the generalization takes place in dependence of the surface topography using quadric error metrics (Garland and Heckbert 1997). The LOD generation is based on a mesh simplification algorithm, which removes elements of the original TIN that have a low significance until a certain error value is reached (WPS GeneralizationService).

To visualize the TIN by a mapping service, the WPS ConverterService could transform different data formats for example VRML (Virtual Reality Modelling Language) or KML (Keyhole Markup Language) using XSLT (Extensible Stylesheet Language Transformation) technologies. A reference of the result terrain files is sent back within a WPS execute response to the client, which can visualize the result (Fig. 5).

Fig. 5
figure 5

Visualization of the terrain

Full size image

Conclusions and future work

Processing high quality surface based e.g. on LiDAR data requires enormous computing power and storage capacity. To process these vast data sets means to compute million of raw data points and running computationally intensive algorithms. In this paper we have presented a possibility to make the handling of massive surface data easier using Web based geoprocessing services combined with Grid systems. The OGC based Web services as well as the implemented processing algorithms are adapted to the requirements of the Grid architecture. It was shown, which synergies will be result from the connection of Grid Computing technology and SDI standards regarding calculation performance and storage capacity of large terrain data sets and that linking both can be beneficial. Grid Computing offers the capability to outsource processing jobs, whereas SDI provides the framework for processing, accessing and visualize spatial data. In order to orchestrate different processing services, we define a geoprocessing workflow based on the BPEL workflow engine (Fleuren and Müller 2008).

As proof of concept we processed SRTM terrain data covering Germany. The study area was split in 42 tiles with a size of 128 times 128 km per tile. Therefore about 100 million files (26 GB) were processed with a total processing time for instance of 1,300 CPU hours. Our future work will focus on more tests and qualitative and quantitative analysis of the results.

The officially released OGC WPS standard (version 1.0.0, OGC 2007) provides the basic requirements for real geoprocessing functionalities. This WPS version adopted the IT mainstream by supporting SOAP to exchange XML-based messages and WSDL to describe Web services. The WPS offers processing resources, so the spectrum of SDI services has been extended considerably, as SDIs are no longer restricted to sharing geo-data only, but also can provide real calculation services. Our terrain pre-processing interfaces are linked to the WPS interface. They may be providing a basis for deriving WPS profiles. Goebel and Zipf (2008) discuss WPS profiles for 3D geoprocessing and try to derive a classification of relevant categories of 3D processes through a top-down approach. On the other hand it is possible considering the basic processes, which may be generic or domain specific—leading to different profiles. The processes defined here may become part of such a future profile.