Article Preview
TopIntroduction
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.