Module 5--Exploring and Manipulating Data

Well, I can guarantee that I am not quitting my day job. Though the lab started out easily, I got hung up on populating the dictionary. I probably spent 16 hours or more just one that one small step. After I finally figured out the issue, which was that by adding the update, get value statement for keys and values, and the key:value format statement within the for loop, everything printed out as required. I figured this out by commenting out lines of code and then adding new lines to see what happened. I eventually worked through the issues. Of course, viewing the student questions site on Canvas also assisted. Believe me, I contributed to the questions, but I also shared my solution.

The lab worked sequentially and built upon each step. Beginning with creating a new file geodatabase, I then assigned my feature classes to "fclist." I then copied these FCs to the new fGDB using a "for loop" (and also stripped out the .shp extension). Between each step, I learned how to add statements showing the date, time, and the amount of time the computer needed to complete the step. I also used "\n" to make sure lines were skipped for ease of viewing.

This screenshot shows the first several steps of the lab, to include the commentary: Create fGDB, copy Feature Classes, and creating a search cursor that returns county seats. The list of county seats is truncated to save space, but the code shows the information for all the county seats.

I then used a search cursor to sort out all the cities that were considered county seats in the feature column of the table. The only information I needed for this exercise was the name of the city, the feature, and the 2000 population.

Screenshot of the end of the county seat information. The dictionary is populated in the correct format {key:value}. Statements say how long it took, when the process finished, and the lab was complete.

Once I got the dictionary to print, the lab was complete. Though the lab was a challenge, I learned a lot.

A few words of advice:
--delete the row and cursor once you complete a loop.
--use \n so there is a line break.
--use print(arpy.GetMessage(count-1)) to get the date/time/process time for each line.
--don't forget the # symbol to add a comment.
--make sure ArcGIS Pro is not running at the same time as Spyder or you will likely get an error message.
--use the overwrite argument to reduce the amount of errors you receive saying that the fGDB exists (env.overwriteOutput=True).
--comment out lines of code (sometimes I put different numbers of # marks to keep myself straight) and try new lines. This way, you don't make a change and forget how to reverse it.

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.