How I Build Geoprocessing Tools: #14 Models and SubModels
Models and Sub-Models
I have taken personality tests in the past, where they have questions like, “would you rather be a concert pianist or a conductor?” Or, some have stated... your watch is a good indicator of your personality. (The first time I heard that I didn’t own a watch!)
I am enjoying very much coaching my daughter’s basketball team. In many ways it is like conducting a symphony. The girls are like the players of the instruments of the orchestra. Each team member learns “the song” on their instrument for their given position. The variations of all the instruments playing the song according to the composer’s orchestration can be combined to make music that is grater than the sum of the parts. The conductor plays the players, which in turn play their instruments.
There is something very organic about ArcGIS geoprocessing models. All because of the intelligent design of the geoprocessing framework, tools can be combined together in intelligent ways to perform a given task. The task that a tool is designed to perform may in turn be useful as part of a more complex task. However each tool can be defined and run separately. If a modification is made to the definition of a tool, that change is automatically realized in each of the tools that has included the tool as part of its own definition.
The ArcGIS geoprocessing framework ensures that once a tool is created it can be used in any of the different geoprocessing interfaces without additional work. This means that my custom tool can be accessed directly from its toolbox with a double-click and a dialog box will be generated to accept the user’s inputs and the tool will be executed. The same is true if I wanted to type the name of my script tool directly into the command line, or include it by name with its parameters, in a geoprocessing script.
I want to use my custom OffsetMove tool in a workflow. I will use ModelBuilder to build a tool that automates this workflow. I create a new model tool by right clicking on a custom toolbox and selecting the New Model option. A new blank ModelBuilder model canvas will be displayed. I can then drag tools from ArcToolbox onto my model builder canvas. I like to use the index tab of ArcToolbox to find tools, because I tend to think about tools by their name. My custom tool is called OffsetMove. By typing it into the search edit box it quickly locates my new custom tool and I can drag it onto the Model Builder canvas.
I will be creating three different tools that will add CAD text to a CAD drawing based on offsets from positions defined by different types of input feature classes. I will create a tool that offsets TEXT from points and writes them to a CAD file. I will also create a tool that creates TEXT in a CAD file based on an offsets from the Mid-Points of linear features, and a third tool that creates TEXT in a CAD file based on offsets from points located inside polygons. Because with certain polygon shapes, like a crescent, the centroid can be outside the polygon, I will select the INSIDE option to force my point for text to be inside the polygon and offset from there. At the heart of each tool is my custom OffsetMove tool.
The difference between my three tools are how I generate the input points that will in turn define the CAD TEXT positions. For line features I’ll use the FEATURE TO POINT tool with the default Mid-Point option, where as for the Polygons I will use the FEATURE TO POINT tool with the INSIDE option. For Point features I can run my OffsetMove tool directly. The part of the workflow that creates CAD TEXT for each option is handled by the ArcInfo EXPORT TO CAD tool. I will create a model that just includes my OffSetMove tool with the EXPORT TO CAD tool, and I will call it PointsToCADText. This named custom model tool will include my custom Script tool OffsetMove tool joined to the system tool EXPORT TO CAD. The result is another custom tool with its own name, and automatically generated interfaces. I will then use this new custom tool as a sub-model in the tool that creates text for lines and polygons.
A sub-model is just another tool. It is added to a ModelBuilder model like any other system or custom tool. Any of the parameters of its included tools can be turned into variables of the sub-model or can be hard coded. The parameters can be renamed and the resulting model tool can have its own help documentation and metadata. It is a tool.
I will expose the X,Y,Z offset parameters as variables as well as the input and output CAD file names in my sub-model. I will hardcode my output feature class, the one I use as input to the EXPORT TO CAD tool, the same that is the output of my OffsetMove tool and define it as intermediate input. It will then be deleted after I run the tool automatically for me. I will also expose as variables some of the parameters of the EXPORT TO CAD tool to provide enough flexibility to create the CAD file.
Sometimes I may want to hardcode all the parameters, or at least provide useful defaults for the various options to make a tool easier to run. If I always choose the same parameters in a model there is no reason to make my custom tool any more complex than it has to be. I will still have the flexibility to change the parameter values of my tool either by editing the model or by exposing the parameters as variables later on and saving it.
I have several custom model tools in my toolbox that are just system tools that I have hard-coded the inputs parameters. These custom model tools may have just a single system tool with all hard coded inputs and outputs and no variables. I just run the tool and it performs its function without prompting.
I have taken personality tests in the past, where they have questions like, “would you rather be a concert pianist or a conductor?” Or, some have stated... your watch is a good indicator of your personality. (The first time I heard that I didn’t own a watch!)I am enjoying very much coaching my daughter’s basketball team. In many ways it is like conducting a symphony. The girls are like the players of the instruments of the orchestra. Each team member learns “the song” on their instrument for their given position. The variations of all the instruments playing the song according to the composer’s orchestration can be combined to make music that is grater than the sum of the parts. The conductor plays the players, which in turn play their instruments.
There is something very organic about ArcGIS geoprocessing models. All because of the intelligent design of the geoprocessing framework, tools can be combined together in intelligent ways to perform a given task. The task that a tool is designed to perform may in turn be useful as part of a more complex task. However each tool can be defined and run separately. If a modification is made to the definition of a tool, that change is automatically realized in each of the tools that has included the tool as part of its own definition.
The ArcGIS geoprocessing framework ensures that once a tool is created it can be used in any of the different geoprocessing interfaces without additional work. This means that my custom tool can be accessed directly from its toolbox with a double-click and a dialog box will be generated to accept the user’s inputs and the tool will be executed. The same is true if I wanted to type the name of my script tool directly into the command line, or include it by name with its parameters, in a geoprocessing script.
I want to use my custom OffsetMove tool in a workflow. I will use ModelBuilder to build a tool that automates this workflow. I create a new model tool by right clicking on a custom toolbox and selecting the New Model option. A new blank ModelBuilder model canvas will be displayed. I can then drag tools from ArcToolbox onto my model builder canvas. I like to use the index tab of ArcToolbox to find tools, because I tend to think about tools by their name. My custom tool is called OffsetMove. By typing it into the search edit box it quickly locates my new custom tool and I can drag it onto the Model Builder canvas.
I will be creating three different tools that will add CAD text to a CAD drawing based on offsets from positions defined by different types of input feature classes. I will create a tool that offsets TEXT from points and writes them to a CAD file. I will also create a tool that creates TEXT in a CAD file based on an offsets from the Mid-Points of linear features, and a third tool that creates TEXT in a CAD file based on offsets from points located inside polygons. Because with certain polygon shapes, like a crescent, the centroid can be outside the polygon, I will select the INSIDE option to force my point for text to be inside the polygon and offset from there. At the heart of each tool is my custom OffsetMove tool.
The difference between my three tools are how I generate the input points that will in turn define the CAD TEXT positions. For line features I’ll use the FEATURE TO POINT tool with the default Mid-Point option, where as for the Polygons I will use the FEATURE TO POINT tool with the INSIDE option. For Point features I can run my OffsetMove tool directly. The part of the workflow that creates CAD TEXT for each option is handled by the ArcInfo EXPORT TO CAD tool. I will create a model that just includes my OffSetMove tool with the EXPORT TO CAD tool, and I will call it PointsToCADText. This named custom model tool will include my custom Script tool OffsetMove tool joined to the system tool EXPORT TO CAD. The result is another custom tool with its own name, and automatically generated interfaces. I will then use this new custom tool as a sub-model in the tool that creates text for lines and polygons.
A sub-model is just another tool. It is added to a ModelBuilder model like any other system or custom tool. Any of the parameters of its included tools can be turned into variables of the sub-model or can be hard coded. The parameters can be renamed and the resulting model tool can have its own help documentation and metadata. It is a tool.
I will expose the X,Y,Z offset parameters as variables as well as the input and output CAD file names in my sub-model. I will hardcode my output feature class, the one I use as input to the EXPORT TO CAD tool, the same that is the output of my OffsetMove tool and define it as intermediate input. It will then be deleted after I run the tool automatically for me. I will also expose as variables some of the parameters of the EXPORT TO CAD tool to provide enough flexibility to create the CAD file.
Sometimes I may want to hardcode all the parameters, or at least provide useful defaults for the various options to make a tool easier to run. If I always choose the same parameters in a model there is no reason to make my custom tool any more complex than it has to be. I will still have the flexibility to change the parameter values of my tool either by editing the model or by exposing the parameters as variables later on and saving it.
I have several custom model tools in my toolbox that are just system tools that I have hard-coded the inputs parameters. These custom model tools may have just a single system tool with all hard coded inputs and outputs and no variables. I just run the tool and it performs its function without prompting.
posted by Don Kuehne at 12:39 PM
0 Comments:
Post a Comment
<< Home