Lab 6 - Crime Analysis

This week's lab centered on how to run various types of hotspot analysis. Our focus for this use of GIS was specifically on determining crime hotspots - although I can see alternate uses in terms of generating hotspots of other sorts (statistically significant concentrations of certain types of archaeological sites or artifact types, for example).

Overlay of three different hotspot mapping techniques.

The above map shows the results of three separate hotspot analyses. The most concentrated area (shown in red) was derived from the Kernel Density analysis tool. Running this particular tool is superficially easy - but the results will vary depending on the variables used. For example, would a search radius of 0.25 miles be enough? Or up to 1 mile? I had run the tool 4 separate times, from 0.25 miles to 1.0 mile and finally settled on the results from the 0.5 mile search radius. How one displays the results can also alter the final view - the above results are based on all values that were 3 times above the mean - or in other words, the magnitude of the number of crimes per unit area (raster cell size = 100 feet, and the search radius was 0.5 miles).

The second most concentrated area is the Grid-based overlay, shown in bright yellow above. The results are based on values added to a uniform grid - in this case, 2007 burglaries per grid cell. The final results represent only the top 20% quintile, so only the most concentrated areas of burglaries are shown.

The final view also takes up the most map space - this is the results of the Local Moran's I analysis, shown in blue. While this analysis uses spatial autocorrelation in its final output it covers too much area - in my mind this might be a deterrent to decision makers who simply wish to know where to concentrate their resources.

Module 6 - Geoprocessing with Python

This week's lab focused on running various geoprocessing tools within PythonWin - not necessarily within ArcMap itself. Setting geoprocessing environments and checking licenses were also covered within the lecture materials.

Process results from Module 6 script.

The above screenshot shows the results of this week's lab assignment. The goal was to write code to run three different geoprocessing tools (the Add XY tool, Buffer tool, and the Dissolve tool) and to print the results messages after each tool runs. The bit on the end about Module 6 being a success is my own personal variation.

At first this lab seemed daunting, but using the ArcGIS Help files was really the key to completing this lab. The help files contain useful scripting examples and notes, which made writing the code to run the geoprocessing tools very easy. The only real snags were directing the results to correct file paths and making sure to use the tool results from previous processes as inputs within the new process - but with a little thought things worked out well in the end.

Lab 5 - Spatial Accessibility Modeling

This week we explored Network Analyst and its use in spatial accessibility modeling. The term 'spatial accessibility' essentially refers to service area (such as for fire departments, grocery stores, etc.) - how long will it take to get from here to there, and what areas fall under the same time frame? This type of analysis can also be used for determining the best placement of a new store location, or, if need be, the best candidates for a store closure.

Side by side comparison of service areas.

The above map represents a simple service area analysis comparison. The schools represent the origin point, and the polygons surrounding them represent their 'service area' - broken up into minutes of drive time. The comparison shows what the loss of one of the schools would have on the overall service area network. As can been seen, only those living within the relatively populated section of Travis County, Texas would have the best access to the ACC school system. With the loss of one school this becomes even more true, and those further out may need to consider other options (if possible) for community college.

Network Analyst was utilized to run the service area analysis; a pre-existing streets network layer was used to calculate drive times. The facilities used for the analysis are comprised of the ACC locations, and the polygons displayed represent a travel radius of up to 15 minutes from the school locations. The analysis needed to be run twice - once to show the overall ACC service area, and then again to show the effects of the planned campus closure.

Module 5 - Geoprocessing in ArcGIS

This week we used Model Builder to create a simple model, and then converted that model to Python script.

Model result - the removal of certain soils from within a basin.

The above screenshot shows the results of the model that was created for lab. Essentially the model process was to clip a soils layer to the extent of a basin layer, then to select a certain soil type from within the clipped area (specifically soils designated as 'Not prime farmland'), then to erase the selected soil type from clipped area. The results shown above is the clipped soil extent without the 'Not prime farmland' areas.

One could do all of these steps individually... or they could combine them into a series of tasks using Model Builder. Converting the model steps to Python was super easy... and I found that I understood the Python coding process a bit better as a result. By doing a few simple fixes the Python code was able to be run outside of GIS - so that will be super handy for the final project.

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.