I am new to Python scripting in ArcGIS but not new to ModelBuilder.

I would like to know the benefits of Python vs ModelBuilder.

When should we write Python script for GIS automation rather than use ModelBuilder?

What are the automation capabilities of Python that we cannot find in ModelBuilder?

7 Answers 7


I believe that the user should clearly define their objectives before deciding which set of tools to use. ModelBuilder and Python scripting excel at different tasks. A few thoughts:

  1. ModelBuilder has no mapping capabilities, whereas arcpy.mapping does.
  2. Python can be used to optimize workflows, such as with the multiprocessing package or with parallel processing.
  3. Python allows for nested loops and other handy iterative logic tools. To accomplish a similar result in ModelBuilder, you would have to construct intricate, and complicated, nested models.
  4. Simple text manipulation is very easy with Python and either very difficult or not possible with ModelBuilder.

    e.g. to rename a list of file names from, for example "m_2010_naip_2310345_nw.img" to "2310345nw.img" can easily be accomplished with Python using the os.path module.

On the other hand:

  1. ModelBuilder is very useful for quickly putting together common tools and eliminating the need for debugging scripts.

  2. ModelBuilder has a very useful recursive iterator that is easy to implement in order to loop through folders and subfolders.

  3. ModelBuilder excels at visually and intuitively depicting the workflow for complicated tasks.

  4. ModelBuilder can incorporate Python script tools.

  • 24
    I would add also: 1. you can run your Python script outside ArcMap 2. You can use ArcObjects in Python, 3. There may be some speed differences.
    – Tomek
    Commented Apr 7, 2013 at 19:19
  • 4
    – Tomek
    Commented Apr 8, 2013 at 5:39
  • 3
    +1 NESTED LOOPS & arcpy.mapping! I like the ability to make calculations within a script and add them to attribute tables or better yet to the map layout (area of each wetland type for example).
    – Roy
    Commented Apr 9, 2013 at 19:43
  • 2
    I read python scripting for ArcGIS book . I also add some more capabilities : 1- script cursors let you loop through records in a table, reading the existing rows and inserting new rows. 2- scripting can be used to wrap other software- that is, to glue together application. for example python can be used to access functions in Microsoft Excel or in the statistical Package R. 3-A script can be run as a stand-alone script on disk outside of ArcGIS.you do not need to run ArcMap or ArcCatalog for script to work. (Python Scripting for ArcGIS , Chapter 2 , Page 39)
    – BBG_GIS
    Commented Apr 13, 2013 at 15:02
  • 1
    Python will also work nicely with other data forms such as csv and text files to name a few.
    – Tom Dilts
    Commented Apr 8, 2016 at 18:59

If you are working solely within the confines of ArcGIS, there are a few considerations I would consider when attempting to determine the approach to take.

  • What are you trying to accomplish,
  • What are your current skill sets,
  • Will you be sharing your work with others to use, learn from, or manipulate, and
  • Who is your intended audience.

Given those considerations:

  1. It is often quicker and easier to build a process in ModelBuilder than in Python, unless part of your process cannot be replicated in ModelBuilder.
  2. If you don't know Python & have not intention to learn it, ModelBuilder is a great option.
  3. If you don't know Python & want to learn to incorporate it into your skill set, ModelBuilder is a great way to start by creating simple models, then exporting them to Python so you have the skeleton of your final process pre-built for you. This method does come at a cost, as there is a lot of extraneous information & variables that usually get created during the conversion process, but it is still a great way to start learning.
  4. If you are building tools for personal use, using whichever method you feel most comfortable with is usually the route to go. I personally use both, depending on my needs.
  5. If you are planning to share your analysis with others, and want to share your model/script with others are part of your process documentation, a model is generally much easier to follow and understand for non-technical people.

There probably is no answer to "which is better" for personal use, but if you are looking long-term at employment possibilities, by learning Python you will set yourself apart from those who only know how to use the pre-programmed tools, or just know how to use ModelBuilder. You also give yourself the ability to go outside the confines of Python for ArcGIS (ArcPy), and start automating far more tasks and projects by using other proprietary and open-source GIS libraries, as well as many non-GIS libraries (ie- database, image manipulation, statistics, etc).


Model Builder is a great and easy to learn visual programming language and a good entrance to GIS-programming in general. But in some things python can do more.

One example is the integration of non-ESRI GIS libraries. Nearly all of the Open Source GIS can be adressed via python as well (e.g. GRASS, Sextante, QGIS, SAGA). This helped me a lot, because I only have an ArcView license. So every time I cannot use a certain geoprocessing tool in ArcGIS, I look what other options are available in Open Source GIS. I then take these OpenSource-tools and combine them with ArcGIS tools either in a bigger python script or integrate them in ModelBuilder via a smaller python script.

I´m sure other members can name more advantages.


When using Python and ArcGIS, you get the entire functionality of Python in addition to what you already had in ArcGIS. If you need this kind of power and flexibility depends on your wishes. In addition, getting to know and really leverage a programming language such as Python takes time. If this investment is worth it for you is up to you. However, for serious data processing a real scripting language is a very good addition in your arsenal.

Apart form any functionality that the ModelBuilder might miss, there is also a more fundamental discussion. In general, scripts are much more suitable to create complex workflows. The code is processed from top to bottom, and complex tasks can be subdivided into smaller sub tasks using e.g. functions. or objects. A graphical tool such as the model builder tends to become a big spaghetti.


I'm partial to creating Python scripts. It's more fun to write code than to mess around with connecting lines to boxes and such, for me at least.

What's really great about Python scripting is you can schedule your scripts to run at a time that is convenient for you. If you have a script that takes a while to complete, or needs to be run outside of regular business hours, this is really convenient. You can see an example of how to schedule a script here.

And as @Aaron mentions, you can easily set up looping in a Python script.

If you're just setting out with Python scripting, you might want to create a model with Model Builder and export it as a Python script. I do this sometimes if I'm having trouble understanding how to use several tools in a script. It could help you get a sense for how to put scripts together.


I have found that I seem to get stuck with no solution more with model builder than with python scripting. The somewhat 'black box' nature of model builder to me makes it harder to find where the problem is located.

I have also found that I can find a lot more help on python. I tend to find lots of dead end threads and topics about model builder. There area also fewer example to go by, where as with python, you probably can find small snipets of most parts of any script you are writing.


Correct. Python is for "Pros" and people who want to advanced themselves. Model Builder is limited, and good for beginners or people who just don't understand how to program. Yep dead end threads are true simply because Model builder is a dead end solution. ;)

Python is really powerful and where its at, and and can be used just about anywhere. Take the plunge.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.