Final Project

Our final project for GIS 5990 was a substantial research project.  I chose to continue with the Valley of Oaxaca data that we had used in the Digitization module.  An important anthropological question is whether there is a relationship between population intensity, limitations on the carrying capacity of the land, and a resultant emergence of government. One way to study this relationship is with “site catchment analysis” (Vita-Finzi and Higgs 1970:5) which can be used to determine whether the carrying capacity (the ability of the land to produce food) is exceeded in later cultural phases as populations expand.

The project involved determining the site catchment buffer for the archaeological sites in several 4km square grids within the valley.  In the image above, I've created 1 km buffers around the Phase IIIA site for my grids.  The sites have been converted to points, allowing me to create Thiessen polygons around each point.  Thiessen polygons allow us to divide up an area so that each point on the map is within a region closest to one of the site points.  This helps prevent double counting of territory.

With the catchment buffer established, and with the help of land cover shapefiles we had built earlier, I was able to determine how many hectares of each type of land/soil were within the catchment area for each site.  This could then be used, along with some information from the literature about corn cob lengths during the various phases and resultant crop yields, to determine the number of metric tons of corn grown around each site.  Assuming that a family of five could live on a metric ton of maize for a year, we can estimate the highest possible population supported by the catchment buffer.

In the end, my results showed that the catchment return was quite high and that agricultural limitations do not appear to factor into either settlement patterns nor provide support for the emergence of government in later cultural phases within the Valley of Oaxaca.

Sharing Tools

Our final assignment involved updating a script and creating a toolbox with an embedded script.  We modified an existing script to use the sys.argv arguments instead of GetParameters. We also added descriptive help text and finally embedded the script securely within the tool (with a password). The end result was a tool that can be shared as one file, reducing management issues for users.

A good finale to the class as we will, hopefully, expand on our Python and ArcGIS skills and be prepared to create new tools and share them with the ArcGIS community.

Thanks for the class!  I learned a lot.  I'm mostly interested in GIS from a landscape archaeology point-of-view, so learning various ways to automate geoprocessing and working rasters will likely have a strong presence in my future.

Creating Custom Tools

Pretty easy (if you do the exercises) and useful lab this week.  We took an existing script that will clip multiple input files and turned it into an ArcGIS tool.  First we created a toolbox in ArcCatalog and added a new script tool to the toolbox.  Then we associated the tool with our existing script.  We needed to make a couple modifications to the script to connect the tool's input fields with inputs that the script needed.  Finally we modified the script's print messages into arcpy.AddMessage() so the messages would appear in the dialog's own message space.

Overall, pretty quick but a good basis for how to make ArcGIS custom tools in the future.

Debugging and Error Handling

This week's assignment covered debugging and error handling.  This is a topic that is useful in any form of programming, not just when writing GIS scripts.  Our first exercise (above) involved correcting some syntax errors in a simple script that reads out the names of various airports in a shapefile.  Nothing too difficult here and the IDE that I use (PyCharm) helps point out many of those errors.

The second part of the assignment similarly needed corrections.  This script used some of the functions we learned last week in the Map Scripting module, so it was interesting to try to find the syntax errors in that code which we've not used much.

Finally, the grads had the chance to implement a couple try-except statements on code that contained errors. We didn't fix the errors, but implemented the try-excepts so that the code would still run, even if it ran into a problem.  This is a super useful tool to have as the exception can return good information about the error and prevent things from running off the rails entirely.  

Overall, a good week, lots of useful tools for the toolkit.

Remote Sensing

This week's assignment focused on using remote sensing resources and raster classification (both unsupervised and supervised) methods in an attempt to locate unknown archaeological sites.  Our first attempt (above) was an "unsupervised" classification of land cover by the ArcGIS program.  Unsupervised means that the program basically tried to divide the region up into classes (we asked for 8 classes) based on the coloration of our aerial (which was gray-scale).  This led to a lot of errors and redundancy.  Specifically, water bodies (which seem to be quite green) and forest areas were frequently confused. In the same way, the mounds at Cahokia Mounds State Park, and specifically Monk's Mound, were classified along with field grass and roads and buildings.

In the second part of the assignment, we created a point shapefile and selected land cover around the map.  I added over 60 points and manually classified them as water, forest, fields, roads, buildings and mounds. Unfortunately, the results of this "supervised" classification were not much better than the unsupervised.  There was still a lot of redundancy and errors in areas with similar color (water/forests) and some areas (like residential areas) were classified as a mix of water and forest rather than building sites.  It was interesting to try these methods, but I'm doubtful on whether they can be effective for archaeological work.

Finally, the grads played around with chi-square tests.  This test is super useful and I've used it in classes in the past.  The key seems to be finding or setting up data in a way that allows the use of this test.  That is a tool that I want to be ready and able to use when analyzing field results.

Geometry and Rasters

We're starting to get into the nuts and bolts of reading and writing feature classes now. Part 1 of the assignment this week involved reading out the components of a shapefile and writing those to a text file.  This was a pretty straightforward assignment, though there are some subtleties with getting the "parts" of the geometry out of the shapefile.

Part 2 involved working with rasters.  I really wish we had more time for this topic as I think I will be working with rasters a lot in the future and I feel like we are only scratching the surface here.  The goal was to read in a raster and then apply various raster functions (slope, aspect - with varying conditionals) to create a new raster based on the combination of temporary rasters.  The end result appears above.

Finally, for grad students, Part 3 involved reading in the "parts" that we originally wrote out to a text file in Part 1 and build a new feature class.  This was actually pretty challenging.  While my code works and appears to match the desired outcome, I'm not completely happy with it.  One thing I don't understand is why the rows in the attribute table do not match the order that they are read in (and the order of the OID that they had in the text file).  I imagine there is some sort of object referencing/ordering going on that is outside our control, but it is somewhat troubling not having that level of control.  Overall, a good assignment this week and exposed a lot of the power of arcpy and GIS programming.

Week 6: Exploring and Manipulating Spatial Data

This week's assignment focused on exploring and manipulating spatial data.  We created a new geodatabase via our script and then populated it with feature classes created from existing shapefiles.  Then we were introduced to cursors.  We created a SearchCursor along with a snippet of SQL to find the cities that are county seats in the cities feature class.  Finally, we populated a dictionary with city:population key:value pairs derived from our county seat query.

All and all a pretty straightforward lab. The only thing that really hung me up was forgetting to delete the cursor (which locked the gdb and caused me to wonder why my env.overwriteOutput=True wasn't working).