Module 3 - Geoprocessing
 |
| Geoprocessing Script Code Output |
 |
| Geoprocessing Script Flowchart |
First and foremost, I discovered that most geoprocessing scripts (and scripts in general) involve a few essential elements to get started. I usually like to complete the comments at the top of the script to display my name, script name, and script details. Then I complete a flowchart to showcase the elements of the script and organize it so that it will be easy to follow along while creating the script. After doing this, before delving into the “bulk” of the code, I usually start by importing the necessary modules, in this case, arcpy and env. I also name all of the variables I would be using throughout the code early on to reduce errors and have names that will be easy to understand by the script reader.
The syntax for the geoprocessing tools was fairly easy to understand and format in order to make the script run properly. It was important to note the defaults for the tools, especially the buffer tool. For example, this tool automatically defaults to ‘feet’ as units of measurement. However, this assignment required that the buffer be in ‘meters’ as the unit of measurement. Thus, when setting the distance variable, I had to include “meters” after 1000 in order to override the default for this geoprocessing tool. Also, I ensured that I was including the previously set variables for the correct filepaths in the arguments so that the tools would run and produce output in the proper folders.
I found GetMessages() very easy to use and will certainly use it in future geoprocessing scripts to show that the tools run properly and how long it takes to run them. Unfortunately, GetMessages() does not always print out what tool is running, so I had to add a manual line that would print what the tool was before the GetMessages() line.
One error I kept running into this week involved the code not running because the output file was already created. I included a line to overwrite the previously existing file, but the error would still occur. I decided to run the code in ArcGIS Pro instead of Spyder to see if the error would be produced there as well, only to find out that it wouldn’t. After researching this issue online, I found that the code would not run properly in Spyder if the files were already open in ArcGIS Pro. To resolve this, I simply closed the ArcGIS Pro application and re-ran the code in Spyder.
The syntax for the geoprocessing tools was fairly easy to understand and format in order to make the script run properly. It was important to note the defaults for the tools, especially the buffer tool. For example, this tool automatically defaults to ‘feet’ as units of measurement. However, this assignment required that the buffer be in ‘meters’ as the unit of measurement. Thus, when setting the distance variable, I had to include “meters” after 1000 in order to override the default for this geoprocessing tool. Also, I ensured that I was including the previously set variables for the correct filepaths in the arguments so that the tools would run and produce output in the proper folders.
I found GetMessages() very easy to use and will certainly use it in future geoprocessing scripts to show that the tools run properly and how long it takes to run them. Unfortunately, GetMessages() does not always print out what tool is running, so I had to add a manual line that would print what the tool was before the GetMessages() line.
One error I kept running into this week involved the code not running because the output file was already created. I included a line to overwrite the previously existing file, but the error would still occur. I decided to run the code in ArcGIS Pro instead of Spyder to see if the error would be produced there as well, only to find out that it wouldn’t. After researching this issue online, I found that the code would not run properly in Spyder if the files were already open in ArcGIS Pro. To resolve this, I simply closed the ArcGIS Pro application and re-ran the code in Spyder.