Why use models?

Perhaps you're wondering, "Why should I build a model when I can easily run the geoprocessing tools individually?" Running individual tools is fine when your analysis doesn't involve much geoprocessing or when you just need to produce data to support a one-time analysis.

If, however, you have a complicated geoprocessing workflow or you want to be able to easily repeat an analysis using different data or parameters, a model is the way to go. Consider these advantages to using models:

Models provide a big-picture view of a project

Because of their graphical nature, models are especially useful for visualizing a workflow and the data that is being used and produced at each stage. They are also useful for showing to others when explaining a complicated workflow. A workflow presented in a model can be understood at a glance.

Models are reusable

You can save a model, open it, modify it, then run it over and over again—as many times as you need to. This means that if you want to perform the same work more than once, but with different parameters, you don't have to recreate it from scratch; you can just modify one or more of the processes within the model. You can easily experiment with different solutions to an analysis problem.

Processes run seamlessly, faster

Processes that are strung together in a model run seamlessly, one after the other, until the workflow is completed. Running a model is considerably faster than running each process separately from the tool dialogs.

Processes can be run individually

A complicated geoprocessing workflow is easier to create by using a model, because you can build each process separately. When creating a model that will run many interrelated processes, you can apply a modular approach to your work—build the model piece by piece, testing each process separately to make sure that it works as you want it to, before moving on.

Models make managing intermediate data easy

Because each process creates output data that is used as input for another process, you can end up storing many datasets you don't need. Sometimes, it can be difficult to even identify intermediate datasets. With a model, deleting intermediate data is easy. As you build a model, simply flag output data as intermediate, then delete it with a single click after the model runs.

Models can be shared

You can share models with others to avoid duplication of effort and promote the standardization of workflows.

More about sharing models

When sharing models, there are a couple of things to keep in mind:

· The first is that in order for others to be able to use your models, you must save all their component tools and data with relative path names. That way, when a model is opened from a different location, it will be able to find the required tools and input data and run properly. If absolute paths are saved with a model, the model will look for its tools and inputs in the wrong locations—in the folders on the model creator's computer or network where the tools and data were stored when the model was created.

· The second thing to keep in mind is that in order for others to understand your model and use it appropriately, you must document it. Just as you should document your GIS datasets with metadata, you should document a model and its processes. Because documentation is stored with a model, it is easily accessible to those using the model.

Models can have four different types of documentation:

· Description — you can document a model with a description that displays in the model properties.

· Metadata — you can enter standard metadata, such as an abstract, statement of purpose, and keywords, that will display in ArcCatalog and in a Web browser.

· Help — with ModelBuilder's Documentation Editor, you can create your own detailed model help, providing valuable information about the model processes and the data produced by each. When you build a model, the name of each tool you add is automatically listed in the model's help, which you can then edit. You can view a model's help from ArcToolbox or ArcCatalog.

· Labels — you can annotate model elements with graphic labels to help users more easily interpret what's going on as they explore the model.

Labels help users understand a specific aspect of a model or one of its elements.