ArcGIS ModelBuilder — Think like a programmer, save the hassle of being one
By: Fabien Ancelin
Tags: Arcmap, Arcgis Pro, GIS, Arcgis, Model Builder

ArcGIS ModelBuilder — Think like a programmer, save the hassle of being one Fabien Ancelin Follow Aug 18 · 5 min read

Spend less time creating — more time sharing.

Esri’s products ArcMap and ArcGIS Pro have a fantastic tool that lets their users automate workflows: ModelBuilder. If you want to automate some data conversion process, ModelBuilder has your back. If you want to reuse an analysis, ModelBuilder has your back. If you want to get rid of ArcGIS Error 999999? Sorry, there is nothing ModelBuilder can do about that.

Without a programming background, it can be harder to build models that are simple, easy to read, and easy to reuse. It is easy to overcomplicate models or make a big mess. But with a few tips and tricks inherited from programming, we can start writing smaller, simpler, reusable models; all of that without the need to be a programmer.

In this article, I am going to share those tips and tricks to help you spend more time enjoying your models, rather than making them.

ModelBuilder gives you programming tools: use them

ModelBuilder is a visual programming language. That means it gives us access to simple programming concepts that you should use and master. Here is a quick summary of things you need to know.

Parameters

A model should always have parameters. It let us run our analysis with different inputs, and generate different outputs. Without that, our model is never re-usable or shareable. If you’re working with ArcMap or ArcGIS Pro, you know any tool exposes parameters. Do the same. Parameters can be documented via your toolbox built-in help.

Let’s see that with a model that takes a point feature class as an input (purple parameter) and generates 50 meters buffer as an output (green parameter)

Model in edit mode with two parameters: one for the input dataset , one for the output

Parameters exposed through the User Interface

Variables

Each object symbolized by an ellipse in ModelBuilder is considered a variable that can be used to generate information. Let’s say that I want the output of my buffer tool is the exact same path as my input dataset, with the buffer distance as a suffix: variables let me do that.

Use the % character to define the use of a variables

The output data is the concatenation of the input dataset variable and the distance variable

Iterators

If you want to repeat a process for multiple input values, then an iterator is what you need. Here is an example of the previous model run for multiple distances as an input. Let’s assume we want to generate multiple buffers around our bus stops dataset in Ottawa, Canada. The distances are 25, 50, and 100 meters.

Our updated model interface that takes a list of distances, instead of just one.

Our updated model content. Note the iterator that runs our buffer for each input distance.

Our buffer outputs generated in Ottawa at 25, 50, and 100 meter of each bus stop.

Conditions

Conditions allow portions of our model to execute only if a condition is true. Using my previous example, I can set a condition so buffers are generated only if the input distance is 50 meters.

Setting a condition

Stop making big models

In programming, we take our big problems and break them down into a set of small, reusable, testable functions and modules. Do the same with you models and break them into small, reusable, and testable units.

Let’s have a look at two models that extract the first and the last nodes of a line feature class into two separate feature classes. Our first model does the trick, until we realize how much code is repeated, just with different parameters.

A model with two branches, and a lot of repetition.

What if we simplified that model into something like that?

Here we have isolated the duplicated logic into a better sub-model define below

Our Keep It Simple model: the logic is isolated and we make use of parameters to make it reusable (and documented)

What are the benefits?

By making a separate model to extract our data, we can reuse that model anywhere. In other words, many models can reuse that logic, not just the one we were planning to do.

We can test our sub-model separately. If we are modeling a big workflow, and want to test a small portion of it, it makes no sense to run the entire process to test a portion of our model.

Iterators can only be used once per model. If we break our big model into sub-models, we can start using a lot more iterators.

With those benefits in mind, always make sure that one model solves one problem. Programmers call that separation of concerns. It has been working well for us.

Document each model

Now that we understand that we are going to make small models, and use parameters to make those reusable, here comes an important guideline: document each model, since they can all be reused.

No decent programmer leaves code undocumented. Good documentation saves time, frustration, and anger: in other words bad interactions. Be a good person, never leave a model without documentation. People might not even bother using a tool without documentation.

Even better, document each model like you would expect any tool in the ArcGIS Platform to be documented. Documentation is one thing that Esri does extremely well. If your models don’t keep up, you won’t look good.

Models might also be exposed as geoprocessing services on ArcGIS Server, or shared outside our organization. If the tool is not documented, we’re letting a lot of people down.

If you enjoyed that article, don’t forget to clap and/or subscribe to the publication. It helps me know what topics are interesting to you.

References

What is ModelBuilder ?— Documentation for ArcGIS Pro here.

What is ModelBuilder ?— Documentation for ArcMap here.