Picture This: A Model for GIS Workflow Automation

Suzanne-Boden · ‎08-16-2012

Python is one of the most popular languages used to script ArcGIS tasks, maybe because it has a relatively low learning curve and it can do a lot. Python is integrated into ArcGIS Desktop. You can create Python add-ins and toolboxes and in ArcMap you can directly enter Python label and MapTip expressions instead of having to load a script file. It's nice to have these options.

Amidst all the Python love floating around, some have said ModelBuilder is the forgotten hero of the ArcGIS automation world. They contend that ModelBuilder deserves a bigger share of the spotlight that's shining on Python. I've always found GIS professionals to be visual thinkers who embrace scripting, so it makes sense they would use both Python and ModelBuilder to do their ArcGIS work (and many of you likely do).

But if there is a Python vs. ModelBuilder debate, I'll stay neutral by saying that both are valuable and have their place. When an older child angrily accuses them of favoritism towards the unwanted intruder, wise parents know to respond, "We love your little brother just as much as we love you." And so it is with ModelBuilder and Python.

Both are tools to automate GIS analysis, data management, and mapping workflows. Unlike Alex and little Sam, they can even play nicely together (you can add a Python script tool to a model, and you can export a model to a Python script).

I've heard ModelBuilder called a "visual programming language." This is an interesting way to think about it as it's true there are many things you can do in ModelBuilder that mirror programming techniques—such as creating variables, iterating (looping) through a set of data, setting preconditions, and nesting submodels inside a larger model (similar to calling another script from inside a script).

Let's shine a little light on ModelBuilder just in case it is feeling left out. Why might you want to create a model?

Visualizing Workflows

A model is extremely useful when designing and sharing a workflow, especially when it's complicated. You can always draw on a whiteboard, but dragging and dropping tools into a model scores efficiency points—you can dynamically build and adjust the workflow as you're thinking it through. You can easily rearrange model tools and elements and add text labels to document the flow and datasets being created. When collaborating with others, communicating about a workflow using a model is more effective than reading and scrolling down through a script. A model is like a map—it's a graphical medium that engages people and enhances understanding. You can even export a model to a graphic or PDF file and bring it along to a meeting as a handout.

Exploring Results and Testing Scenarios

Because you run a model from inside ArcGIS Desktop (ArcGIS Pro or ArcMap), you can examine the results immediately. In this way, a model is part of the daily fabric of your GIS work. If the model output creates a new question to investigate, all you have to do is change a model parameter (e.g., switch out a tool's input dataset or value) and rerun a process or rerun the entire model, then explore what that yields.

With a script, it's certainly doable but not as easy to work iteratively like this. You have to open the script file, find the lines of code that need to be edited, make the edits, save the script, run the script, then possibly open ArcMap and add the output and maybe some other layers for context. To make things easier, you can start by loading the script into the Python window in ArcGIS and go from there.

Identifying Problems

One of the cool things about a model is that you can eyeball its progress as it runs. As each process executes, the tool flashes red and a drop-shadow displays under its elements when the process completes. You can immediately tell where an error occurred in the model because it stops processing there. Just find the first process that doesn't have a drop-shadow.

After correcting the error, you can continue running the model from that point—you don't have to go back to the beginning. Just right-click the tool element in the process that failed and choose Run. Identifying the location of a problem in a script is not always as fast.

Applying Skills You Already Have

The most obvious reason to create a model over a script is that you lack scripting skills, whether Python or any other language, and you don't want or can't afford to invest the time to learn scripting. Though these days it's fairly easy to acquire basic Python skills. From Esri alone there are free tutorials, presentations, training seminars, and free and low-cost web courses. ArcGIS geoprocessing tools output Python code snippets you can examine to learn from and then modify to suit your needs. Basic Python skills don't cut it, however, if you need to automate an advanced workflow.

Models chain together and run geoprocessing tools, so if you are a GIS professional who uses ArcGIS, more than likely you already have the skills required to create a model. Setting up a model correctly requires time and planning, like any other task. You have to understand your data, environment settings, tool parameters, and desired outputs. There are nuances and more advanced capabilities of models that you may need to educate yourself about, but again there are lots of resources to do so (see the list at the bottom of this post).

In the end, the choice of whether to automate an ArcGIS workflow using a script or a model comes down to what you feel most comfortable doing. Python is a logic-driven text-based tool and ModelBuilder is a logic-driven visual tool. When feeding your culture appetite, sometimes you want to read a great novel and sometimes you want to look at a beautiful painting. Similarly, there may be times you want to write a script and other times you want to create a model. The beauty of ArcGIS is that you can easily do both, right inside ArcGIS Desktop.