Model Builder: Difference between revisions

From Wildsong
Jump to navigationJump to search
Brian Wilson (talk | contribs)
mNo edit summary
Brian Wilson (talk | contribs)
mNo edit summary
Line 3: Line 3:
The idea is to make programming more accessible for non-programmers.
The idea is to make programming more accessible for non-programmers.


The flow chart "language" is extremely limited as a programming medium,
There used to be a joke in programming school back in the olden days. All flow charts can be simplified to this:
but it has one big advantage for learning to program in the ESRI domain.
Once you have a "model" built and working, you can generate the equivalent Python code. (Model->Export->To Script->Python). This gives you a starting point for writing your own Python [[Geoprocessing]] scripts for use as components in Model Builder, or as standalone tools.
 
There used to be a joke in programming school back in the olden days that went like this: All flow charts can be simplified to this:


[[Image:UniversalFlowChart.jpg]]
[[Image:UniversalFlowChart.jpg]]


Though at the time this was (relatively) true, college professors never accepted it. You always had to flesh things out more. At the time, almost all programming then was procedural. Event driven models, MVC, objects, functional programming... all those things were in the future.  
Well, we're geeks, we thought it was funny. What can I say? At the time this was (relatively) true, but college professors never accepted it on tests. You always had to flesh things out more. At that time, almost all programming was "procedural". Event driven models, MVC, objects, functional programming... all those cool things were in the future.  


A procedural program starts at the top (well... at the left in this case) and flows from one box to the next until it completes. Using Model Builder is a tool for building procedural programs. The diagram above was built with Model Builder.
A procedural program starts at the top (at the left in this case) and flows from one box to the next until it completes. Model Builder is a tool for building procedural programs. Indeed, the diagram above was built with Model Builder. Ellipses represent data such as feature classes and rectangles are processes; either spatial like transformations or data processes like simple calculations.


Another way to think of procedural programs is to think of a really old computer system. It had a card reader, a processor, and a printer. Input, processing, output. You put a stack of shape objects into the card reader, you perform some operation on them, and you push them back out into a feature class.
Another way to think of procedural programs is to think of a really old computer system. It had a card reader, a central processing unit (CPU), and a printer. Input, processing, output. Put a stack of shape objects into "the card reader", the CPU performs some operation on them, and then it pushes them out into the "printer" (an output feature class).


With Model Builder, that's really all there is to it. You just build on this model by chaining things together in stages.
With Model Builder, that's really all there is to it. You just build on this model by chaining things together in stages.
Line 24: Line 20:


Still, there is a lot you can do within the existing framework.
Still, there is a lot you can do within the existing framework.
The flow chart "language" is extremely limited as a programming medium,
but it has one big advantage for learning to program in the ESRI domain.
Once you have a "model" built and working, you can generate the equivalent Python code. (Model->Export->To Script->Python). This gives you a starting point for writing your own Python [[Geoprocessing]] scripts for use as components in Model Builder, or as standalone tools.

Revision as of 17:26, 26 April 2006

ArcGIS 9.x has a new thing called "Model Builder" that lets you build scripts in the form of flow charts and then execute them.

The idea is to make programming more accessible for non-programmers.

There used to be a joke in programming school back in the olden days. All flow charts can be simplified to this:

Well, we're geeks, we thought it was funny. What can I say? At the time this was (relatively) true, but college professors never accepted it on tests. You always had to flesh things out more. At that time, almost all programming was "procedural". Event driven models, MVC, objects, functional programming... all those cool things were in the future.

A procedural program starts at the top (at the left in this case) and flows from one box to the next until it completes. Model Builder is a tool for building procedural programs. Indeed, the diagram above was built with Model Builder. Ellipses represent data such as feature classes and rectangles are processes; either spatial like transformations or data processes like simple calculations.

Another way to think of procedural programs is to think of a really old computer system. It had a card reader, a central processing unit (CPU), and a printer. Input, processing, output. Put a stack of shape objects into "the card reader", the CPU performs some operation on them, and then it pushes them out into the "printer" (an output feature class).

With Model Builder, that's really all there is to it. You just build on this model by chaining things together in stages.

You can chain many tools together, and you can use "preconditions" as a simple form of decision-making (branching) but you can't use any advanced iterations or branches. (I suspect that more advanced features are coming down the road.)

Still, there is a lot you can do within the existing framework.


The flow chart "language" is extremely limited as a programming medium, but it has one big advantage for learning to program in the ESRI domain. Once you have a "model" built and working, you can generate the equivalent Python code. (Model->Export->To Script->Python). This gives you a starting point for writing your own Python Geoprocessing scripts for use as components in Model Builder, or as standalone tools.