Module 3: Debugging

This module was much more straightforward than the prior. I am sure part of this is just the extra practice and increased understanding that goes with working through problems. I am glad that this module has been moved to earlier in the class so that we can find our problems in a systematic way.

During this module, we learned several ways to work through exceptions: Visual inspection of syntax, print statements, commenting out a line of code (or lines), and using the debugger tool in Spyder. I used all the tools throughout the exercise and assignment. Besides the visual inspection, I probably commented out several times to work through different versions of the script.

For Part 1, I just had to find two errors in the script. This was very easy, as this was just the warm up for the next two parts. When looking at syntax errors, the key is to consider indenting script properly and consistently, ensuring correct use of upper/lower case, symbols placement ("", :, etc.), and spelling.

Module 3, Part 1, Script 1

The above output was the result of correcting two script errors, which returned the feature classes in a geodatabase. A key to the exercise was ensuring that the scripts provided were in the correct location by verifying in ArcGIS Pro.

For Part 2, there were eight errors. These errors built onto the prior errors, but still contained many syntax errors. There was only one error that was a little difficult to find; however the debugger tool came in handy along with commenting out (using a #) and trying new lines of script. Once the script ran correctly, it printed out the names of the layers in the project's map.

Module 3, Part 2, Script 2

I was a little worried about Part 3 because it was the final step and I knew it would be the culmination of the entire module. For Part 3, we were expected to find an error, which was easy with the debugger tool. We were not supposed to fix the error, but use the try-except statement so that the script would execute with an easy to read statement and then continue to Part B. If correct, Part B would execute without error. The try-except statement was easy; however, it is imperative that you check your indenting so that those actions still remain within the script instead of outside. Below is the flowchart created to assist with this part.

Module 3, Part 3, Script 3

As you can see above, Part A ran, but returned an error statement that I had added to the code with my try-except statement. Once this executed, Part B ran and returned the names of the feature classes, data source, and spatial reference.

All my lessons learned are presented throughout this posting. A lot of this is just attention to detail. A big lesson learned for me was that everyone has errors and that many of the errors are simple spelling or punctuation mistakes. Look at those issues before deep-diving into the actual code. Additionally, the debugger tool is of great assistance.

GIS 5103--Programming--Module 1

After what seems like an eternity, classes have started again. This class will teach me how to write script using Python, which is the preferred scripting language for ArcGIS Pro. Though I was introduced to the Integrated Development and Learning Environment (IDLE), this class will use Spyder as the script editor. A word of caution is that if you use a virtual desktop, you must save the your products into the portal. If you were to complete the lab on your personal desktop and then dragged the finished product to the school's portal, there would be errors.

As part of the learning, we were introduced to The Zen of Python, which is a light-hearted set of guidelines for programmers. In a nutshell, the guidelines favor simplicity, utility, and practicality versus nested layers, complexity, etc. These guidelines also ensure Python can remain open source software and that others can add to its body of knowledge. Besides a few inside jokes in Zen, there is another: If you type in "import this" in Spyder, the Zen of Python will populate in Spyder.

The reading assignment also provided the steps to solve a problem for scripting. According to Agarawal et al (2010), I must first identify my inputs, determine the overall goals of the process, and then develop the steps to achieve those goals. Once I complete these steps, I can then write a pseudocode.  For this lab, I created a pseudocode for converting radians to degrees. The pseudocode must begin with Start and finish with End. All the interior lines are indented and completed in order with the variables placed prior to the actual operational function because the script runs in order from top to bottom and left to write just as we read. Once I created the pseudocode, I decided to convert this into Python script using Spyder, which yielded the correct computation. Prior to coding, I could have developed a flowchart, but I did not because it was a very simple computation.

For the lab deliverable requirement, I used Spyder and imported a .py file from the school portal (File>Open>*.py). Once I select the script and ran it (either using the run button or F5), eight folders (with three sub-folders each) populated into my share drive. This was important so that each student had the same folders. All data, scripts, and work will be placed in these folders in the future.

Screenshot of Lab 1 that Utilized Script to Produce 8 Folders in My Student Drive.

Though a little intimidating at first because I have never coded, the lab was very straightforward and there were very few pitfalls. My main pitfall was that I tended to overthink things. I have embedded many of my lessons learned throughout this post. One thing I did differently from the lab was that I went directly to Spyder from ArcGIS Pro instead of using the run option. To me, this was easier and saved a step. Another lesson is that when writing script, ensure that quotation marks are used following the command and be aware that a script must be saved prior to being run (the program will prompt you).