Week 4 - AppsGIS - Visibility Analysis

This week we worked on visibility analysis, using the Viewshed and Line-of-Sight tools. We worked with 4 different scenarios: viewshed looking at tower placement, security camera placement via viewshed, line of sight among summits, and and visibility of portions of Yellowstone State Park from roads.

For the security camera analysis, we worked with a raster that showed the finish line for the Boston Marathon, and were tasked with adding more cameras that could see the finish line. The view for the given camera was first for a 360 degree view at ground level. This is not the case of a typical camera, and so was later edited to account for it being on the side of a building (100 feet high) and a 90 degree view.

Figure 1. Visibility of camera near the finish line of Boston Marathon.
This is based off of 360 degree view of the camera at ground level.

The task for this portion of the assignment was to place two new cameras that would better cover the finish line. We had to place the cameras, adjust their horizontal viewing angle, and their vertical height. For the two cameras, one  was close to the finish line (Camera 2) and one on the opposite side of the finish line from the first camera (Camera 3). Camera 2 was placed in a building to the north of the finish line, on the north side of the road. The vertical offset for this camera was 75 feet, determined by a digital elevation model that included buildings. The viewing angle for Camera 2 was set to 90 - 180 degrees. This part took quite a bit of tweaking, as the degrees were not as expected and it took a while to get them right. I still am not sure why this was the case. Camera 3 had a viewing angle of 180 - 270 degrees, and was as expected visually. This camera was set to a 100 foot vertical offset, and was located about half a block west from the finish line. To show the overlap of the viewsheds, they were ranked by number of cameras that could see each cell, as shown below:

Figure 3. Overlap of viewsheds for cameras placed near the Boston Marathon finish line. Dark blue represents areas that are visible from all three cameras.

I was pleased with how this analysis came out, as the area around the finish line is quite visible. A way to improve this analysis, in my opinion, would be by ranking the distance from the camera as well. A camera does not see as well far away as it does close up, and this should be taken into consideration. I worked with closed circuit television (CCTV) monitoring, and have seen this first hand. Visibility analysis is clearly a tool that can be used in a multitude of applications, and it was neat to see how my other classmates felt it could be used. That is definitely a benefit of this class, that we all have different backgrounds, so see different "big pictures".

Week 3 - AppsGIS - Watershed Analysis

Figure 1. Final map comparing modeled and given streams and a watershed on the island of Kuauai.

This week we worked on watershed analysis of the Hawaiian island of Kuauai, comparing modeled results with actual streams and watersheds. First, we performed watershed delineation using streams as pour points. In order to do so, the digital elevation model (DEM) was filled-in using the Fill tool to remove any sinks. Most of the sinks removed were in the low elevation areas to the west side of the island. Now that the model is hydrologically correct, the Flow Direction tool was used to establish how the streams will flow. Following this, we used the Flow Accumulation, with the flow direction raster as an input, which resulted in a stream network:

Figure 2. Modeled stream network.

We then set a condition that all of the streams are defined by having at least the flow of  200 cells accumulated downstream. The resulting raster was turned into a feature class via the Stream to Feature tool. We additionally created a stream order raster that used the Strahler method to order the streams created via the Conditional tool.

The next part of our analysis was delineating a watershed using stream segments (Created with the Stream Link tool) as the pour points. Using the Basin tool, we then used the edges of the DEM to delineate drainage basins:

Figure 3. Delineated basins using the edges of the DEM.

Alternately, we used the river output as the pour point to delineate watersheds. This required us to use Editor to mark the pour point at the mouth of the river of the largest watershed (dark green in the image above), known as the Waimea watershed. This pour point was at the edge of the DEM, which is why it matched the basin result above. We also used a pour point in the middle of the DEM, which was a gauging station used by USGS. This station was not on a modeled stream, so the Snap Pour Point tool was used to correct for this. The Watershed tool was again used to create a watershed raster for the specified gauging station:

Figure 4. Watershed raster based off of USGS gauging station.

Finally, we compared our modeled results from above with streams delineated based off of aerial photos, and previously mapped watersheds. For the streams, it was quite apparent that modeled streams are quite different than given streams at extreme elevations, however, they "match" quite nicely at mid-elevation.

Figure 5. Modeled streams (light blue) compared to given
streams (dark blue) at low elevations.

Figure 6. Modeled streams (light blue) compared to given streams (dark blue) at high elevations.

Figure 7. Modeled streams (light blue) compared to given 
streams (dark blue) at mid-elevation.

For the watershed analysis, I chose the Wainiha watershed to model, with the pour point located at the output of the river. Looking at the modeled and given watersheds, they lined up quite nicely. 

Figure 8. Modeled watershed (light purple) compared to given 
watershed (red outline). There was little excess in the modeled
output, but the northernmost point was "missing".

The analyses we used this week were very interesting, and I can see how they will be highly beneficial later down the line. I liked the fact that we performed the analysis using different tools and methods so that we can see the options available to us. 

Week 2 - AppsGIS - Corridor Analysis

Figure 1. Raster of the proposed black bear corridor between two sections of national forest.

This week we worked on least-cost path and corridor analysis. For the first portion, we looked at a few different least-cost paths for a pipeline by creating cost surfaces for slope and proximity to rivers. We created three different scenarios by changing the cost of being close to rivers. For the first path, we only looked at a slope, which was reclassified so that the lowest cost was for low slopes (<2°) and highest for steep slopes (>30°). A cost surface raster was created, followed by a cost distance raster, with accumulative costs as you move away from the source. The source is at the top of the image, indicated in light blue, and the destination is represented with a dark blue asterisk. With this analysis, there are 4 river crossings, which were determined using the Intersect tool. A backlink raster was also created, so that a least-cost could be created using the Cost Path tool. 

Figure 2. Scenario 1, showing least-cost path with slope as the cost surface.

For the second scenario, we created a cost surface with a high cost for rivers, which resulted in fewer pipeline intersections. In order to combine the two cost surfaces, the Raster Calculator was used. For the third scenario, we used a high cost for rivers, and a slightly lower cost for the area close to a river (within 500 m). We again had two intersections, but they were at different areas. The following image compares the two:

Figure 3. Scenarios 2 and 3, with the path for Scenario 2 in darker red, and Scenario 3 in brighter red. Both paths cross the rivers a two points, but the location varies due to adding cost to being within 500 m of a river.

Additionally, we created a corridor for the same pipeline. Some layers could be reused, but we had to perform cost distance again, this time with the destination as a "source" since the Corridor tool requires two source inputs. After using the Corridor tool to create a range of possible paths, symbology was adjusted to represent 105, 110 and 115% of the minimum value. My image is slightly off from the example in the lab, I believe that this is due to differences in rounding when calculating the path values. I tried several different sets of numbers, to no avail. The following image is the result: 

Figure 4. Corridor result for the pipeline, with the least-cost path for the third scenario (high cost for rivers, lower cost for adjacency to rivers). Darker corridor is most similar to least-cost path, at 105% of the minimum cost value (path).

Finally, we conducted corridor analysis for a black bear corridor between two fragments of the Coronado National forest. In order to determine the best corridor, cost surface analysis for elevation, land cover and proximity to roads was conducted. Cost determination was based on the parameters that black bears prefer mid-elevation areas, prefer to avoid roads, and prefer forest land cover types. The three cost surface rasters were combined using the weighted overlay, with landcover having the highest weight. This result was then inverted so that the the higher suitability has the value of 1, and the lowest suitability has a value of 10. This was accomplished using Raster Calculator.

Corridor analysis was then performed, using both fragments of the national forest as sources. The same values were used in order to determine a suitable corridor (105, 110, 115% minimum value). All values above 115% were reclassified as NoData in order to create a raster with only the corridor and source areas. A final map was created in order to showcase the results:

Figure 5. Final output map for the black bear corridor. Map shows corridor areas ranked by suitability (1-3). 

Overall, I became fairly familiar with the Cost Distance, Cost Path, and Corridor tools. These tools clearly have many advantages when trying to determine the best area to place a path or corridor. Also, I learned the benefit of using the Hillshade tool over simply using the hillshade option when trying to adjust symbology, especially for elevation. I feel confident in this week's exercise and being able to implement it in the future.

Week 1 - AppsGIS - Suitability Analysis

This is the first assignment in the Applications in GIS course, and covers suitability analysis. We worked with both vector and raster Boolean suitability modeling, as well as weighted overlay. For the Boolean modeling, we looked to determine the suitable habitat of mountain lions. Criteria set were forest cover, steep slopes, within 2500 feet of a stream, and 2500 feet away from a highway. We accomplished this with the layers as vectors, and with the layers as rasters:

Fig 1. Vector result of Boolean suitability modeling for mountain lion habitat.

Fig 2. Raster result of Boolean suitability modeling for mountain lion habitat.

We also performed a weighted overlay for a separate data set, with suitability based on low slope, agricultural land cover, soil type, more than 1000 feet from a stream and within 1320 feet of a highway. We then compared results of when the layers are equally weighted, as well as when the layers are weighted so that slope has highest weight, while distance from streams and highways of lower weights. 

Fig 3. Comparison of weighted overlay results when criteria equally weighted vs. unequally weighted. For this analysis, no suitability value of 1 (lowest suitability) was calculated, and therefore is not present on the map.

I feel like I learned a lot this week performing the analysis. First and foremost, I (re)learned how to to turn-on an extension in ArcMap. I had totally forgotten that this was necessary sometimes and had a slight freak-out, whoops. I did become quite familar with the Reclassify, Euclidean Distance, Raster Calculator and Weighted Overlay tools. The Euclidean Distance tool was used to evaluate the distance from rivers and roads, which was reclassified to the desired levels. The Raster Calculator was implemented to combine the rasters used in the analysis into one single raster (used in the mountain lion analysis). The Weighted Overlay was used to rank each cell's total suitability when each of the five criteria are combined as one. It is definitely interesting to see how the results change when you change the weight (importance) of the criteria. I can see how this type of analysis is highly important and can be utilized in a variety of situations.

Weeks 14-16 - IntroGIS - Final Project

These last few weeks we worked (hard) to showcase what we have learned over the last few months. We "assessed" a proposed transmission line corridor for Manatee and Sarasota Counties. I had a lot of fun putting this together, it was really nice to see everything that I have learned. It also reiterated how complex a GIS can be, and how I will never be fully happy with my deliverables.

I definitely had to refer back to my notes several times, but I made it through. Some of my stuff is not quite as organized as I would have liked, eDesktop was quite slow, so I had to work off my own computer, and then move everything back over. This of course required quite a bit of time copying such large files. My presentation can be found at the links below; there is a PowerPoint presentation and a written summary:

Presentation

Summary

Week 13 - IntroGIS - Georeferencing, Editing and ArcScene

Map showing the current (as of 2010) extent of the University of West Florida. The inset map shows the location of an eagle nest located on the property, which the University was looking to develop. 

This week we went over some seemingly small, yet important aspects of GIS: georeferencing, editing, and working in ArcScene. We used georeferencing to orient aerial photos of the University of West Florida (UWF) campus. We combined the images with layers of buildings and roads with spatial reference. I feel that I had a bit of an advantage over some students because I know the campus quite well. We also learned about Root Mean Square error and transformations of the results. This definitely came in handy. Despite our best efforts, we always run the risk of misrepresenting the information, especially when you have things such as shadows and poor image quality.

Additionally, we learned how to perform an editing session, so that we can change attribute table information, digitize objects, or add features. I struggled time-wise with the digitizing of the UWF Gym because I can be a bit of a perfectionist, and I kept starting over. We also worked with the Multiple Ring Buffer toolbar in order to set up a buffer around the eagle nest, at 330 and 600 feet. As part of this, we placed a link within the eagle nest location that takes the viewer to an image of the nest. This is especially cool to me as I am working on a shark identification project that this will be perfect for. As a side note, I was happy that we finally learned how to use the transparency option on the data symbols.

Maps showing a three dimensional image of the UWF campus, with buildings and roads highlighted. 

Finally, we worked in ArcScene to create a three dimensional image of the campus, with our newly added features (the Gym and Campus Lane). We learned how to set up the layers by floating them on top of a digital elevation model (DEM), how to unite the layers when extra space is present (Layer Offset), and how to exaggerate the buildings so that they stand out more from the landscape (Vertical Exaggeration). I also had to investigate to figure out how to get my roads to stand out, as the ones in the northern section wanted to fade into the topography due to the Layer Offset. It is a bit of struggle working with the .jpg files in ArcMap, as they do not seem to set up the same way as a shapefile or feature class. I had to draw several polygons and shade them the same as the background in order to get the results above. I really enjoyed this week, and am really pleased, as well as amazed, at all that we have learned and accomplished this semester; I hope to showcase this in the final project.

Week 12 - IntroGIS - Geocoding/Network Analyst/Model Builder

Map of the emergency medical services (EMS) for Lake County, FL. Has additional inset of Paisley Fire Station, with optimal route for 3 emergency locations

This week we worked on three important aspects of ArcGIS: geocoding, Network Analyst, and Model Builder. We set out to map a route for emergency services through geocoding and Network Analyst. I really enjoyed this part, I thought it was neat to see first hand how it is done. We never really worry about how our GPS works, we're just glad that it does. Unless you are like me and yours is terrible and never works correctly on your phone.

Resulting model for ModelBuilder exercise.

We also worked with Model Builder through ESRI's educational training. I like how this is set up, and can fill in some of the blanks on its own. I think you could come up with some pretty intense models, and this format is really nice. We didn't build our own (yet), we just worked with one that was already set up. I think it will be interesting once we get to that point.