+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).
–
RoyApr 9 '13 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)
–
wetlandApr 13 '13 at 15:02

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:

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.

If you don't know Python & have not intention to learn it, ModelBuilder is a great option.

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.

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.

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.

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.