Formalizing Cross-Parameter Conditions for Geoprocessing Service Chain Validation

Formalizing Cross-Parameter Conditions for Geoprocessing Service Chain Validation

Daniel Fitzner (Fraunhofer IGD, Germany)
Copyright: © 2011 |Pages: 18
DOI: 10.4018/jagr.2011010102
OnDemand PDF Download:
$30.00
List Price: $37.50

Abstract

Geoprocessing operations offered via web services provide the means for building complex web-based geospatial applications. Often, certain postconditions such as the spatial reference system, bounding box, schema or quality that hold on the output dataset after the execution of a geoprocessing service are determined and derived from the properties of the inputs passed to the service. Further, geoprocesses often hold preconditions that relate to more than one input, such as the requirement that all inputs must have the same schema. Within current process descriptions for geoprocessing operations, such conditions which we call cross-parameter conditions, can not be explicitly specified. In this paper, the author gives an approach to formalize such cross input-output and cross input parameter conditions in a rule-based language. Further, the author proposes an algorithm for deriving pre- and postconditions for a service composition or workflow out of the pre- and postconditions of the services involved, allowing a more automated handling of workflows in general.
Article Preview

Introduction

Geoprocessing tools are software components that input (geospatial) datasets; perform some sort of processing on the inputs and output (geospatial) datasets. Usually they perform some sort of calculation on the geometric attribute of the input data.

Such geoprocessing tools can either be generic and therefore reusable in a number of different application contexts or specific to an application case. Standard, desktop-based GIS such as ArcGIS (Ormsby, Napoleon, Burke, Groessl, & Bowden, 2004) usually come with a set of generic geoprocessing tools since – due to the generic nature of GIS – these tools should be reusable in different application contexts. For example, a standard GIS-geoprocessing tool that calculates a buffer around features can be reused in a number of different application contexts, e.g. for calculating a buffer around datasets representing cities, highways or anything else. To enable users to perform application specific calculations and to create application specific tools for reuse, standard GIS allow the combination of such generic geoprocessing tools. This means, the output of one tool is given as input to another (or the same) tool and so on and the whole chain then outputs datasets that can not be derived from any of the known data sources directly or from executing single generic geoprocessing tools.

For simple chains, involving only few generic geoprocessing tools, it is manageable to perform this process fully manual. This means, a human user executes a tool on some dataset, executes another tool on the resulting dataset and so on until the desired result is reached. However, standard desktop-based GIS, in order to enable reuse and automation of such chains of geoprocessing tools, further offer the possibility to store them such that they can later be retrieved and executed. In GIS terminology, such chains are often called models or workflows. Most GIS come with a user interface that allows users to graphically compose workflows of geoprocessing tools without the need for programming. Although the workflows in desktop GIS can typically be exported into some sort of script-file, the users composing them usually do not get in contact with program code. Additionally, GIS often offer the possibility to parameterize workflows, i.e., some of the input datasets or values (or all of them) are not stored with the workflow (e.g., as pointers in the script-file) but can be specified by users when executing the workflow. This has several advantages: First, storing the input data to a workflow would typically mean storing a pointer to a data source somewhere on hard drive (e.g., a file path) or in the current GIS-workspace. As soon as the location of the data or the workspace changes, the workflow becomes invalid. Second, the parameterization of the workflow allows building a simple user interface within the GIS that allows specifying the inputs without the need for editing or changing the workflow as it is stored. This means, when executing the workflow, users, who are probably not familiar with all the details of the workflow only see the entry points (the input signature) to the workflow without being confronted with the whole, probably quite complex processing encapsulated within.

Complete Article List

Search this Journal:
Reset
Open Access Articles: Forthcoming
Volume 9: 4 Issues (2018): 1 Released, 3 Forthcoming
Volume 8: 4 Issues (2017)
Volume 7: 4 Issues (2016)
Volume 6: 4 Issues (2015)
Volume 5: 4 Issues (2014)
Volume 4: 4 Issues (2013)
Volume 3: 4 Issues (2012)
Volume 2: 4 Issues (2011)
Volume 1: 4 Issues (2010)
View Complete Journal Contents Listing