How I Build Geoprocessing Tools: #5 Scripting
Scripting and Other Not So Scary Things
My daughter is in seventh grade. She is enrolled in a university model school and attends classes twice a week. She is taught in a normal classroom setting, but all of her work is performed at home, like you would when attending university classes. At home my wife and I become her teachers. In that way her school is a hybrid private school/ home school. She has choices of which electives or independent courses of study she wants to take. Instead of enrolling her in the math classes offered at the school we decided I would teach her math.
My teaching style for math is to present simple concepts and overly complex homework to show how the complex application of a problem can be broken down into simple steps. I remember being confused in elementary school by simple repetitive homework because I thought I only learned a small thing when in fact I really knew more. For example, when I taught my daughter two digit addition in 1st grade her homework consisted of 15 digit number addition problems. It’s the same technique just more carrying of the “ones” to the next column. Likewise, subtraction, division, multiplication, etc… unfortunately/fortunately she ended up learning most of 1st – 4th grade math the first month or so. Now, she really likes math because I think she feels empowered (or, despite her teacher she’s really smart). I hated the repetition of elementary math, one reason why I like computing; if I do my job right I only have to solve any given problem once. Like you, I want to solve problems not calculate pages and pages of long division.
I chose the MOVE data tool example because I had a pretty good hunch it was something that wasn’t going to be straight forward to accomplish in ModelBuilder with system tools alone. The task is easy in ArcMap with the standard user interface, and in ArcObjects it would be an elementary task for someone with those skills.
I still think with a little compromise and bending I could come up with a ModelBuilder solution using system tools only, but all signs seem to be pointing to the creation of a geoprocessing script tool for this BLOG series.
So it appears I will begin my sample geoprocessing MOVE tool with a little more complexity, and then we’ll put it all back together and hopefully make it look easy in the end. I think the fear of a scary “looking” math problem or a new computing environment can best be handled by embracing the scary parts in context. At first I myself avoided geoprocessing scripting all together with my realization that I was not a programmer. I soon found that scripting often simplified tasks rather than making them more complex. And, I still didn’t have to become a programmer.
For those of you hoping to get a better look at ModelBuilder stay tuned, we’ll be coming back to ModelBuilder with our new script tool to automate a couple of different use cases.
The actual script code of a geoprocessing script tool can be created using a number of different development tools. Without wading through all the details, Python is the best choice for my application because it comes with the software and is more powerful than the others.
The ArcGIS geoprocessing environment treats an ArcGIS system tool the same way it treats a custom Model tool or a custom Script tool. The application and user experience are the same no matter how a tool was crafted. So once we build this tool we will use it the same way we would use any other tool.
In my last post I mentioned an email I got from a colleague that will help me with a lot of the guts for this solution. (More about that later.) Before that we’ll take a look at the two parts of a script tool and how to build them. First is the GP script tool, which is like a container that defines the types and names of any inputs or outputs and then points to the actual script file. The script tool has properties common to all GP tools and lives in a toolbox. The script tool points to a file which contains the instructions the tool will perform on the given inputs. The script itself is comprised of lines of ASCII text stored in a text file that are interpreted by the chosen scripting language.
In the next post we’ll build the actual script tool part…
My daughter is in seventh grade. She is enrolled in a university model school and attends classes twice a week. She is taught in a normal classroom setting, but all of her work is performed at home, like you would when attending university classes. At home my wife and I become her teachers. In that way her school is a hybrid private school/ home school. She has choices of which electives or independent courses of study she wants to take. Instead of enrolling her in the math classes offered at the school we decided I would teach her math.My teaching style for math is to present simple concepts and overly complex homework to show how the complex application of a problem can be broken down into simple steps. I remember being confused in elementary school by simple repetitive homework because I thought I only learned a small thing when in fact I really knew more. For example, when I taught my daughter two digit addition in 1st grade her homework consisted of 15 digit number addition problems. It’s the same technique just more carrying of the “ones” to the next column. Likewise, subtraction, division, multiplication, etc… unfortunately/fortunately she ended up learning most of 1st – 4th grade math the first month or so. Now, she really likes math because I think she feels empowered (or, despite her teacher she’s really smart). I hated the repetition of elementary math, one reason why I like computing; if I do my job right I only have to solve any given problem once. Like you, I want to solve problems not calculate pages and pages of long division.
I chose the MOVE data tool example because I had a pretty good hunch it was something that wasn’t going to be straight forward to accomplish in ModelBuilder with system tools alone. The task is easy in ArcMap with the standard user interface, and in ArcObjects it would be an elementary task for someone with those skills.
I still think with a little compromise and bending I could come up with a ModelBuilder solution using system tools only, but all signs seem to be pointing to the creation of a geoprocessing script tool for this BLOG series.
So it appears I will begin my sample geoprocessing MOVE tool with a little more complexity, and then we’ll put it all back together and hopefully make it look easy in the end. I think the fear of a scary “looking” math problem or a new computing environment can best be handled by embracing the scary parts in context. At first I myself avoided geoprocessing scripting all together with my realization that I was not a programmer. I soon found that scripting often simplified tasks rather than making them more complex. And, I still didn’t have to become a programmer.
For those of you hoping to get a better look at ModelBuilder stay tuned, we’ll be coming back to ModelBuilder with our new script tool to automate a couple of different use cases.
The actual script code of a geoprocessing script tool can be created using a number of different development tools. Without wading through all the details, Python is the best choice for my application because it comes with the software and is more powerful than the others.
The ArcGIS geoprocessing environment treats an ArcGIS system tool the same way it treats a custom Model tool or a custom Script tool. The application and user experience are the same no matter how a tool was crafted. So once we build this tool we will use it the same way we would use any other tool.
In my last post I mentioned an email I got from a colleague that will help me with a lot of the guts for this solution. (More about that later.) Before that we’ll take a look at the two parts of a script tool and how to build them. First is the GP script tool, which is like a container that defines the types and names of any inputs or outputs and then points to the actual script file. The script tool has properties common to all GP tools and lives in a toolbox. The script tool points to a file which contains the instructions the tool will perform on the given inputs. The script itself is comprised of lines of ASCII text stored in a text file that are interpreted by the chosen scripting language.
In the next post we’ll build the actual script tool part…
posted by Don Kuehne at 9:23 AM
0 Comments:
Post a Comment
<< Home