How I Build Geoprocessing Tools: #15/15 Deployment
Deployment
Having the right tool for the job is certainly a comforting feeling. Looking at your peg board and seeing only the outline of the tool provokes feelings of dread and frustration and the uncontrollable rhetorical shouting..."WHERE'S MY HAMMER!?" You value your tools, and you like to have them put back where they belong. If you buy a new tool, you want to give it its proper place, in a drawer, on the peg board or in its handy carrying case on a preferred shelf.
ArcGIS geoprocessing tools live in ArcGIS toolboxes. ArcGIS toolboxes can be a .TBX file that lives on the file system, or can they live as a named object in an ArcGIS geodatabase. References to your custom toolboxes can be loaded into ArcToolbox's dockable window interface. By default references to all the ArcGIS geoprocessing system tools are added to the ArcToolbox window. You can load your custom toolboxes that live on the file system or inside a geodatabase into ArcCatalog for easy access.
All Geoprocessing tools in ArcToolbox are automatically included in the ArcGIS geoprocessing framework as named objects along with their parameter definitions and help. Because toolboxes can live in geodatabases you can package your custom tools with the data that they were built to process. Because ArcGIS geoprocessing toolboxes can live in a .TBX file you can easily distribute your toolboxes simply by copying them. Script files are ASCII files that must accompany the toolbox as a separate file. If you have script tools you need to supply the accompanying script files with your toolbox.
I share my sample toolboxes on ArcScripts.com. ArcScripts includes all kinds of useful tools built by ESRI users for all the different software ESRI builds. To share your toolbox on ArcScripts you need an ESRI login. If you don’t have an ESRI user login, follow the instructions on creating a new login on the website. Once you have logged in you can upload your toolbox of tools as a single file or in the case of a script tool you may have to .zip the files.
Back during the original creation of a script tool I always select the store relative paths option when creating script tools in. This ensures that later on when tools are copied the script file can easily be found even when directory structures are different from one computer to the other. I always put the script file in the same directory as the toolbox. This is a good idea for tools that you want to distribute. However you may want to put all your script files in a single directory no matter where the toolboxes are located. You have the flexibility to do which ever is best for you.
To download sample tools use the search engine and its various filtering parameters to find useful solutions. Information is included with each script, listing the programming languages and software the tool was designed to work with. The ArcGIS geoprocessing scripts and ModelBuilder model tools I created would all be considered geoprocessing tools.
Once you download solutions from ESRI’s ArcScripts.com, or copy toolboxes fro your colleagues, you can browse to them using the ArcCatalog data browsing pane. As an extra step to make your tools more accessible you can use the Add option of ArcToolbox to include your new tools in the ArcToolbox interface.
I have posted the solutions discussed in this blog series to ArcScripts. I mentioned that I thought I could come up with another solution to moving data and here is what I came up with. The good news is this solution would support curves; the bad news is it would require an ArcInfo license to run the EXPORT TO CAD system tool. I will use some pseudo code to define this solution and leave it up to you to fill in the SMOP (Simple Mater of Programming).
# GET Input Feature Layer
# GET Output Feature Layer
# GET Translation Coordinates and/or Offsets
# GET the Feature Type of Input Feature Layer
#ADD FIELD - add the field “THICKNESS”
#CALCULATE FIELD – Calculate the Unique Identifier to the “THICKNESS” field
#EXPORT TO CAD- Create a temporary AutoCAD file where the FID (unique identifier is stored in the AutoCAD THICKNESS property. (see December 19th post "Symbology As An Application Messaging System")
#Write an ESRI .WLD file (simple ASCII) of offset coordinates based on user inputs
#GET the appropriate CAD feature class from the newly created AutoCAD file. (The world file will shift the coordinates, including curves)
#COPY FEATURES – copy the CAD Features to the Output FC
#MAKE FEATURE LAYER- create a join-able layer of the new features
#ADD JOIN- Join the Input layer to the Output layer based on ‘THICKNESS’ and ‘FID’ to get back the original attributes of the input feature layer.
#DELETE FIELD- Remove all the unwanted CAD fields from output feature layer
Having the right tool for the job is certainly a comforting feeling. Looking at your peg board and seeing only the outline of the tool provokes feelings of dread and frustration and the uncontrollable rhetorical shouting..."WHERE'S MY HAMMER!?" You value your tools, and you like to have them put back where they belong. If you buy a new tool, you want to give it its proper place, in a drawer, on the peg board or in its handy carrying case on a preferred shelf.ArcGIS geoprocessing tools live in ArcGIS toolboxes. ArcGIS toolboxes can be a .TBX file that lives on the file system, or can they live as a named object in an ArcGIS geodatabase. References to your custom toolboxes can be loaded into ArcToolbox's dockable window interface. By default references to all the ArcGIS geoprocessing system tools are added to the ArcToolbox window. You can load your custom toolboxes that live on the file system or inside a geodatabase into ArcCatalog for easy access.
All Geoprocessing tools in ArcToolbox are automatically included in the ArcGIS geoprocessing framework as named objects along with their parameter definitions and help. Because toolboxes can live in geodatabases you can package your custom tools with the data that they were built to process. Because ArcGIS geoprocessing toolboxes can live in a .TBX file you can easily distribute your toolboxes simply by copying them. Script files are ASCII files that must accompany the toolbox as a separate file. If you have script tools you need to supply the accompanying script files with your toolbox.
I share my sample toolboxes on ArcScripts.com. ArcScripts includes all kinds of useful tools built by ESRI users for all the different software ESRI builds. To share your toolbox on ArcScripts you need an ESRI login. If you don’t have an ESRI user login, follow the instructions on creating a new login on the website. Once you have logged in you can upload your toolbox of tools as a single file or in the case of a script tool you may have to .zip the files.
Back during the original creation of a script tool I always select the store relative paths option when creating script tools in. This ensures that later on when tools are copied the script file can easily be found even when directory structures are different from one computer to the other. I always put the script file in the same directory as the toolbox. This is a good idea for tools that you want to distribute. However you may want to put all your script files in a single directory no matter where the toolboxes are located. You have the flexibility to do which ever is best for you.
To download sample tools use the search engine and its various filtering parameters to find useful solutions. Information is included with each script, listing the programming languages and software the tool was designed to work with. The ArcGIS geoprocessing scripts and ModelBuilder model tools I created would all be considered geoprocessing tools.
Once you download solutions from ESRI’s ArcScripts.com, or copy toolboxes fro your colleagues, you can browse to them using the ArcCatalog data browsing pane. As an extra step to make your tools more accessible you can use the Add option of ArcToolbox to include your new tools in the ArcToolbox interface.
I have posted the solutions discussed in this blog series to ArcScripts. I mentioned that I thought I could come up with another solution to moving data and here is what I came up with. The good news is this solution would support curves; the bad news is it would require an ArcInfo license to run the EXPORT TO CAD system tool. I will use some pseudo code to define this solution and leave it up to you to fill in the SMOP (Simple Mater of Programming).
# GET Input Feature Layer
# GET Output Feature Layer
# GET Translation Coordinates and/or Offsets
# GET the Feature Type of Input Feature Layer
#ADD FIELD - add the field “THICKNESS”
#CALCULATE FIELD – Calculate the Unique Identifier to the “THICKNESS” field
#EXPORT TO CAD- Create a temporary AutoCAD file where the FID (unique identifier is stored in the AutoCAD THICKNESS property. (see December 19th post "Symbology As An Application Messaging System")
#Write an ESRI .WLD file (simple ASCII) of offset coordinates based on user inputs
#GET the appropriate CAD feature class from the newly created AutoCAD file. (The world file will shift the coordinates, including curves)
#COPY FEATURES – copy the CAD Features to the Output FC
#MAKE FEATURE LAYER- create a join-able layer of the new features
#ADD JOIN- Join the Input layer to the Output layer based on ‘THICKNESS’ and ‘FID’ to get back the original attributes of the input feature layer.
#DELETE FIELD- Remove all the unwanted CAD fields from output feature layer


3 Comments:
Hi,Don
I downloaded your package AS13639
for Export to CAD, but some of *.py say me "You do not have the necessary license to executethe selected tool".
I also have the same problem however I assume this is because I'm not running an ArcInfo licence. I belive Export to CAD requires this (unfortunately).
Cheers,
Starting at ArcGIS 9.3.1 Export to CAD is available with an ArcView license.
Post a Comment
<< Home