Show Navigation | Hide Navigation
You are here:

Geoprocessing framework

Release 9.2
Last modified October 30, 2007
E-mail This Topic Printable Version Give Us Feedback

Print all topics in : "Geoprocessing"

Related Topics

The geoprocessing framework is the set of windows and dialog boxes you use to manage and execute tools. This document focuses on the high-level concepts and ideas behind this framework rather than the mechanics of using it.

The core idea behind geoprocessing is to allow you to quickly and easily turn your ideas into new software that can be executed, managed, modified, documented, and shared with the ArcGIS user community. Software, in this case, means something that instructs ArcGIS to do what you want. A geoprocessing model, for example, is new software built by you with an easy-to-use visual programming language called ModelBuilder.
The main theme of this section is the idea that geoprocessing is a way for you to create new useful software. By doing so, it is hoped you'll have a broader and deeper understanding of how and why to use geoprocessing.

In order to create new software of any kind, two essential elements are needed:

Geoprocessing's language is its collection of tools. The geoprocessing framework is a small collection of built-in user interfaces for organizing and managing existing tools and creating new tools. The basic components of the framework are shown in A whirlwind tour of geoprocessing, and consist of:

Geoprocessing models and ModelBuilder

The tool dialog box and command line allow you to execute a single tool. You can think of this as executing a single instruction in a programming language. While single tool execution is certainly practical, the system wouldn't be very useful unless you could string together multiple tools, feeding the output of one into another, just like a programming language.
In the geoprocessing framework, the ModelBuilder window is how you quickly and easily turn your ideas into software by chaining together elements of the geoprocessing language (the tools) into a sequence. It's important to realize that models are software since they instruct the computer to do something. The programming language is visual—what you see in ModelBuilder—rather than text-based like a traditional programming language.
The most important thing to note here is that models are tools . They behave exactly like all other tools in the toolbox. You can execute them in the dialog box window or at the command line. Since models are tools, you can embed models within models. In fact, several of the system tools provided with ArcGIS are models.
Models can be as complex as you dare. You can use any number of the tools in ArcToolbox, including other models you've written (since models are just tools) and tools based on scripts. You can use loops and conditions to control the logical flow of a model.
Models can be extremely simple and still be productive. You can create a model that contains a single tool, but embeds some of its parameters. For example, the Buffer tool takes seven parameters, but for your current set of tasks, you know that three of these parameters will always be the same. Rather than filling out these parameters each time you execute the Buffer tool, you can quickly create a model and set these three parameters, save it as the MyBuffer tool, and use its dialog box rather than the Buffer dialog box. You might only use MyBuffer a few times before deleting it, but it's no loss because it was quick and easy to create and productive for you to do so.


You can also use a scripting language to create new, useful software. A program that uses a scripting language is called a script. In the world of software programming, languages can be divided into two basic categories: system languages and scripting languages. System languages are things such as C++ and Java, that are used to create applications from scratch, using low-level primitives and the raw resources of the computer. Scripting languages, such as Python and Perl, are used to glue applications together, using built-in higher level functions of the computer and masking the nuts and bolts a system language programmer must deal with. Compared to system languages, scripting languages are easier to learn and use—a basic understanding of programming is all that's needed to be productive.
In the geoprocessing framework, scripts are analogous to models in that they can be used to create new tools. Models are created with a visual programming language (ModelBuilder) and scripts are created with a text-based language and text editors.
Just like models, scripts are tools . You can introduce a script to ArcToolbox using a step-by-step wizard, and it becomes just another tool that you can use in a model or in another script. Several of the system-provided tools are scripts. Technically, you can write a script and not introduce it to ArcToolbox, in which case it's not a tool, but just a script on disk.
There are several reasons why you'd want to use scripting:

A framework for creating and managing software

The geoprocessing framework was built to let you quickly and easily turn your ideas into new software that can be managed by the system and shared among users.
Geoprocessing is a language consisting of operators, or tools, that operate on the data within ArcGIS (tables, feature classes, rasters, TINs, and so on), and perform tasks that are necessary for manipulating and analyzing geographic information across a wide range of disciplines.

You can quickly and easily create new software in the form of models and scripts. These new tools perform tasks that are not part of the standard ArcGIS package. For example, there is no menu, button, or programming object anywhere in ArcGIS that performs the simple Clip and Buffer model shown in A whirlwind tour of geoprocessing.

Tools are managed by the geoprocessing framework, which means you don't have to. This is a subtle but important point that isn't immediately obvious.

Tools can be easily shared. A toolbox with all its tools and toolsets is either contained in a file on disk with a .tbx extension, or within a geodatabase. Anyone with access to the file or geodatabase can run its tools.

The salient point is that your tools become full-fledged members of the geoprocessing framework where they have consistent documentation, user interface, methods of access, and methods of sharing.

Geoprocessing and ArcObjects

ArcObjects is the extensive library of low-level programming objects delivered as part of the ArcGIS Software Development Kit (SDK). Developers use ArcObjects to build new applications or extend the existing functionality of ArcGIS applications. (For the record, the core geoprocessing tools and framework were all built using ArcObjects.) Like geoprocessing, the ArcObjects SDK can be used to create new software.
The ArcObjects SDK and geoprocessing are complementary; neither obsoletes the other. As a general statement, ArcObjects is used to extend ArcGIS with new behavior while geoprocessing is designed to automate tasks. You'd use ArcObjects to do things like add new user interfaces, add custom behavior to feature classes, or create a special cartographic renderer. Geoprocessing is used to create software (models and scripts) that automate tasks within the confines of a well-behaved framework.
ArcObjects is meant to be used with a system programming language, where the programmer needs to access low-level primitives in order to implement complex logic and algorithms. This is why ArcObjects contains thousands of different objects and requests—to allow the programmer the fine degree of control they require. Because ArcObjects is used in concert with a system programming language, it requires a good deal of programming knowledge, much more than geoprocessing with its models and scripts.
Conversely, geoprocessing is a universal capability that can be used and deployed by all GIS users to automate their work, build repeatable and well-defined methods and procedures, and model important geographic processes.

Please visit the Feedback page to comment or give suggestions on ArcGIS Desktop Help.
Copyright © Environmental Systems Research Institute, Inc.