Lab 4 - Visibility Analysis

This week in GIS Applications we learned how to complete viewshed and line-of-sight analysis. This particular blog post will focus on one very small part of our lab, which is a visibility analysis of hypothetical street cameras at the finish line of the Boston Marathon.

Visibility analysis showing the viewshed of street cameras.

The screenshot above shows three hypothetical street cameras placed around the finish line for the Boston Marathon. The yellow circle represents my area of concern. The varying colors emanating from the cameras represent the portions of the street that area visible... unfortunately I did not include a key in my screenshot. If the key were there it would should that the lightest red color means that only 1 camera has a view of the street, the medium red means 2 cameras share that view of the street, and the darkest red means that all 3 cameras show that view of the street.

I used the following settings for the cameras when running the visibility analysis: all cameras were set to an offset height of 100 ft. The camera angles were all set to 45 degrees for the start and 135 degrees for the end. My first camera had been placed for me at the west end of the street, so to get the best coverage I placed another camera on the north side of the street by the finish line. My third camera was placed on the south side of the street east of the finish line.


I suppose that in order to better mirror reality (are all street cameras placed on streets with the exact same viewing angle?) one might need to run this analysis multiple times (so once for all cameras that have a viewing angle of 0 - 90 degrees, another analysis for those that have viewing angles of 45 - 135 degrees, etc.). Unfortunately I'm not sure how to successfully combine the results of all these viewing angle options - but I suspect it might ultimately involve some map algebra.

Module 4 - Debugging & Error Handling

This week's lab focused on debugging scripts... on purpose, not just those errors we accidentally created because we don't know any better! The error handling techniques learned in class were applied to scripts with both syntax and exception errors.

Script 1 - final results of a corrected script

The first script, shown above, contained basic input errors - such as not using the exact syntax for a defined variable. Most of the errors I was able to spot right away, but I used the PythonWin 'Step' debugging tool to highlight where these issues actually were.

Script 2 - final results of a corrected script

The second script, shown above, was a little trickier. This time I employed a mix of running the script with and without using the Step debugging tool - eventually I was able to fix it. The mistakes were similar to what had gone on in Script 1... except this time there were more of them so simply scanning the script wasn't very effective.

Script 3 - result show how exceptions can be caught!

The final script was not corrected - exactly. The purpose here was to use the "try-except" statement method of error handling... this allowed the script to run yet also to tell you in greater detail what the real issues are. I decided to use a "try-except" statement for what I perceived to be each block of code - a sign that I'm finally starting to read and understand coded scripts! My real issues with the final script were with improper syntax - nothing was going to happen until I had standardized my indentation. Once I figured that out I was able to produce the results that you see above.

Discussion Post 1

Our first discussion in GIS Programming is about the uses of GIS in the real world. To facilitate our discussion, we were to find an article showing just about any interesting application of GIS - not necessarily limited to Python programming. My article focused on the use least-cost path analysis to assist in determining the route of Hernando de Soto's 1540 entrada:
http://saa.publisher.ingentaconnect.com/content/saa/aa/2015/00000080/00000001/art00003

The researchers wanted the optimal path to take into account the size of the party traveling that path. As pointed out in their article, optimal paths use slope information to find the best route and so the default best route is almost always along a flat area. Within the area under consideration that would mean that the best route will tend to be along canyon bottoms - which isn't appropriate when trying to determine where a large party of over 100 people, plus livestock and supplies, would be traveling. To fix this they 'degraded' the spatial resolution of a DEM (specifically a DEM from the 2000 U. S. Shuttle Endeavor with a 90 meter resolution) - this did not affect the accuracy of the DEM but did eliminate the default canyon bottom choice (p.50). In the end their preferred route was a wide northerly path that was a bit longer distance-wise, but it does match with accounts from the travelers themselves, as well as archaeological and linguistic place-name evidence.

Overall I liked that the article used GIS as one tool (out of many) to answer an unresolved question, and also that the traditional parameters of a cost-path analysis were changed to fit a specific project need. The article shows just one of the many ways GIS analysis can be used to answer spatially related research questions.

Reference:
Sampeck, Kathryn, and Jonathan Thayn, Howard H. Earnest, Jr.
2015     Geographic Information System Modeling of de Soto's Route from Joara to Chiaha:     Archaeology and Anthropology of Southeastern Road Networks in the Sixteenth Century.  American Antiquity (80) 1: 46 - 66.

Lab 3 - Watershed Analysis

This week in GIS Applications we covered the topic of watershed analysis. The analysis itself requires a lot of steps, although thankfully they are fairly intuitive and standardized.

Our final map output for this week shows a comparison of a modeled watershed and the actual limits of a defined watershed - for my lab example I had focused on an area of the Anahola Stream Watershed, on Kuauai Island, Hawaii.

View of a modeled watershed versus reality.

To create my model I selected a pour point location along a stream on the edge of my DEM (shown above as the 'landscape' underneath the main map elements). I then ran the watershed analysis tool (which can be found in ArcToolbox under Spatial Analysis > Hydrology). My input layer was a previously created raster file which showed the flow direction for all stream segments as well as my selected pour point. The result was a raster file showing the watershed extent in light green above - although for display and analysis purposes I had converted the raster to a polygon file.

What is striking is how much smaller my modeled watershed is in comparison to the extent of the actual Anahola Stream Watershed. Note that only the connected stream segments are shown within my modeled watershed extent. I believe that my watershed extent is directly due to my choice of pour point location... in fact the watershed area would be even smaller had I selected a pour point further upstream.

Module 3 - Python Fundamentals Part II

This week we finished up our scripting basics with a lab that involved debugging a previously written code as well as adding new code ourselves.

Screenshot of code results.

The first part of the code was previously written for the lab - it is a play by play loop (of if, then, else statements) for a dice game. We were to remove the two errors in the code in order for it to run correctly. The screenshot makes it appear random, but after running the code dozens of times I can honestly say it is not. Computer gamblers beware!

After the line 'Marceline wins!' is a list of numbers - this is the result of the first block of code that I had written for the lab. This line of numbers was randomly generated from 1 to 10, but repeated up to 20 times. The code used is known as a loop, and it utilized a 'while' loop structure to obtain the results.

The last three lines of the results represent my final block of code. The first line explains that I'm removing "unlucky number 3" from the previous list of numbers. The next line shows that the number 3 had been removed, and the final line indicates that the number is no longer present. This was all accomplished using methods (such as the remove function) and conditional for statements.

It was a little tricky for me to put this all together... which is a bit disheartening since I did understand the readings. Clearly learning and doing are two very different things!

Lab 2 - Least-Cost Path and Corridor Analysis

This week's lab focused on determining the least-cost paths and creating corridors using cost distance surfaces. The map layout below shows the result of a corridor analysis of black bear movement between two green zones, in this case Coronado National Forest.



View of possible bear routes between forested areas.

To run the analysis a cost surface was created - first by converting all vector data to raster, then by reclassifying the values of the input data. The cost surface inputs included the distances from roads, ranges of elevation, and types of land cover. Each cost surface was classified, and all cost surfaces were then added together using the Weighted Overlay tool. The weighted overlay results were then inverted using the Minus tool, since in our model the higher values actually represent the more desirable areas for black bears to travel within. Once complete the Cost Distance tool was run twice - one for each 'source' location. These results were then used as the input values for the Corridor tool.

Other Thoughts

This lab was actually very difficult for me - I kept hitting all kinds metaphorical walls until I finally realized what small random misstep I had taken. And the missteps were small - for example I had trouble getting my weighted overlay results to show something other than linear-like features. It wasn't until I really thought about what the data was meant to represent before it clicked what the problem was (in my case, the roads needed to show a range of distances... and to do that one needed to run the Euclidean Distance tool before running the Weighted Overlay!). Overall it was a learning experience as I believe I've gained some very useful knowledge on what it takes to complete a corridor analysis.