Term Project: Using Routing Analysis and Elevation Overlays to Create Ideal Running Routes

Introduction:
My plan is to use routing analysis to create idea running routes. The idea for this came to me when on an easy run. I wanted to pick a flat route which would have a minimal impact on my legs and hopefully speed up the recovery process. It was then I thought it would be cool if google maps and/or GPS navigation systems could account for elevation in its calculations.

In theory I am trying to make it possible for people to enter in the desired distance they want to run, the amount of elevation they want to traverse (probably based off of categories: minimal, intermediate, and high elevation change.....based off the relative elevation of the Eau Claire area), and possibly the general area they want to run around. This could be difficult because routing software calculates from point A to B, and often times when going for a run your start/stop points are the same. So it will be necessary to create predetermined stop points along the way. I will create these manually based off the library of routes created by myself and the cross country team at UW-Eau Claire throughout my 5-years of experience.

Methods:

First I had to find a road network which would perform the necessary routing function I needed. Luckily there was an ESRI streets network on one of the UW-Eau Claire local drives. Next elevation data needed to be attained. Using the USDA Geospatial Data Gateway (http://datagateway.nrcs.usda.gov/), elevation data in the form of TIFFs were downloaded for Eau Claire and Dunn county. Because the area of interest (AOI) was only of the Eau Claire area and the immediate surrounding roads, some the maps were excluded for increased processing speeds. Figure 1. shows the 12 maps before the mosaic process.






Figure 1. 12 TIFF files before the Mosaic Process

Currently I'm trying to figure out how to make a raster of slope. I'll probably have to use the "reclassify" tool in ArcMap to make this. I'm still not sure if that will work better than a simple 6 class elevation model, but at the momment a slope model seems more relevant for a running application intent on ease of running routes.

After the maps are created I will choose one and convert it to vector format. I tried doing this earlier in the week and was prevented by an error, basically only integer rasters can be converted to vectors. After some digging, I realized the my raster was of the pixel type "floating raster." To change the raster to an integer format, I had to use the raster calculator. I found a formula online, but since I didn't need decimal places I simplified the equation to: "int(grid_name)" to get truncated integers (aka no decimal places). Once I was more aware of the tool I found more credible information in the ArcGIS Desktop Help (http://webhelp.esri.com/arcgisdesktop/9.1/index.cfm?TopicName=Int).  Since the raster was now converted to the integer type, it now had an attribute table with 182 values. This was a relief because I knew my raster had an elevation change of 182 meters. Now that the raster was of the pixel type "integer" and had an accompanying attribute table I was able to classify the values and convert it to a vector. Figure 2. shows the Eau Claire area and its elevation model classified into 6 categories.


Figure 2. Elevation Classified into 6 categories...from lowest elevation to highest: cyan < green < yellow < red < grey < white.

Results:

Problems/Obstacles:

Couldn't find a road network

Downloading elevation maps from USDA Geospatial Data Gateway taking a long time/kept being "interrupted"

Mosaic not looking right (had to change the bit depth from default 8 to 32 bit....this was the bit depth of the rasters I imported)

Working on converting a raster to vector format (raster calculator, then classify the values, then?)

Working on how to create a raster showing degrees of slope (Slope (3D Analyst))

Don't know how to find an pre-existing application I can convert for my application (haven't got that far yet...)

I can see how the routing app will avoid the high elevation areas when trying to create an easy route, but if the end-user were trying to create a more difficult route and run over higher grades of elevation/slope I'm not sure how the application will function....will it keep running up and down the same hill...will the application have to enter in predefined points (stops) to make the application work, which then in turn defeats the purpose of having the application create routes for you.

Conclusion:

Sources:
Talks about the various grades of slope and what they can be used for.
http://www.savesfbay.org/sites/default/files/Topography.pdf


Lab 6: Volunteered Geographic Information (VGI)

Goals:

Methods:

Results:


Problems/Obstacles:
During the publishing of my first service the cache must have been full. To get around this problem I hit "F12" on the keyboard, then clicked on "cache", then "clear browser cache." This cleared the tiles which were cluttering up the server. Once the cache was cleared my service was able to edit the features correctly.

My next problem came when designing my own VGI service. I created two feature classes; however, none of my feature classes would appear. After reviewing the code I realized I had residual code from the previous code which told the service to look for point and line information in the geodatabase. Since I only had polygon feature classes, this inhibited the service from working correctly. Once the code was deleted my first service displayed correctly, but not the second. Upon further review I noticed my second feature class would not show up when trying to be viewed from the REST URL. It said the feature was published on an internal server and editing was not enabled. This was how I came to the conclusion that I had not published my service correctly.

The next day I tried publishing my service again and multiple error warnings appeared, "tools not enabled" was the main error. This was because our tech support people were updating the server and the server was down. The only way to get around this problem was to be patient and work on other aspects of the project, like this blog post.

When I came back later and republished the feature class I was able to display the data correctly and edit the features from an end-user's perspective.

Lab 4: ArcGIS Flex API

Introduction:
For this lab we focused on using the Adobe Flash Builder (4.6) to write scripts. The language used for all scripts was MXML.

Methods:

The most important step in the lab was done in the first steps of starting a new flex project. When a new Flex project is create a window is opened with three tabs: project location, server settings, and build paths.

The project location lets you name your project, designate a folder location, pick your application type, and your flex version. For this lab the 'web' application type and Flex version '4.6.0' were used. We left the server settings alone, but the 'build paths' tab was a crucial part of the lab. This was where we browsed our local network drive to retrieve the 'Flex API' library. Without this library the reference words in the code would have no meaning and the script would be useless. To add a library we clicked on the 'add SWC' button and browsed the local network for the folder. Once added the library appeared in the 'build path libaries' box, found in the 'library path' tab of the flex builder path window.

After the code was successfully written for each individual layer, the corresponding icon would appear in the outline menu in the lower left hand corner (default location) of the flex builder application.

The first script, shown in figure 1 below, was a map of population density for the world in a Web Mercator projection.



Figure 1, script for world map of population density.

The next script we created was a map of the united states with pop-up enabled features which were the result of the action script we wrote within the code block.

The last map created used a pre-existing script for South Carolina with mouse over pop-ups for various population statistics. To edit the script to our purposes a few things had to be changed. First off, every time 'south carolina' appeared in the code, it had to be changed to 'wisconsin.' Also, since it is a map divided by counties, that number had to be changed to accurately reflect the number of counties within Wisconsin, 72 of them. Finally the viewer extent had to be changed so the application would know to focus on Wisconsin and not South Carolina. To find the extent the following website was used (http://help.arcgis.com/en/webapps/flexviewer/extenthelper/flexviewer_extenthelper.html). This was done by zooming in the Wisconsin at the proper scale and recording the numbers which defined the extent of the current map's position and scale.


Problems:

I encountered a few problems while working on this lab. The smallest problem was a general coding error that evaded me for quite some time. The next two errors stemmed from the same problem.

While I was working on the lab I was too focused on the instructions and I didn't organize the folders how I normally would with separate file folders in a hierarchy pattern. I had finished most of the lab and came back to work on it the next morning. However, when I went to look for the script in my "lab 4" folder it was not there. It was only after I restarted the lab that I realized the file was in a "bin-debug" folder. I had looked here already, but when I went to run the script it ran in an "ant" form and did not produce a map online successfully. Another problem that came from this was when I tried to make a new flex project. I would add the Flex API library to the project, but it would not show up in the left hand menu of Adobe Flex Builder. I'm still not sure the reason for this and it was at this point that I decided to restart the lab. Although it was a drain on time I planned to use for other projects, I feel I learned the Flex project builder much better and I understood the process of adding a reference library to the point where I would remember to do that again without prior instruction to do so.

Lab 3: ArcGIS Flex Viewer

Introduction:

This lab used ArcGIS Flex Application Builder to create a web application, complete with basemaps, operational layers, widgets. Another important component to the lab was the use of Flex XML (extensible markup language) to create a custom widget.

Methods:

The ArcGIS Flex Application Builder was the tool used in creating the application. With a relatively straight forward interface, building the application was more intimidating than it was difficult. Although, to make a more concise application, the pop-ups had to be reconfigured. For the lab's purposes only a couple fields were left on and renamed for end user client clarity (example, POP2007_SQMI was changed to Population density).

The last component to the lab was to create a Thematic widget. To do this a Thematic widget with population density, housing units, and total population of the United States was used. Then in the widget settings the configuration was changed from 'states' to 'counties' and the extent was set to central Wisconsin.

Problems:

As I had never worked with the XML I had a tough time with the initial sections of the lab. In the ArcGIS Flex Application builder I was able to get my custom widget to show up, but an error #1085 kept showing up. After I noticed the path my data was stored in and the directions in the lab had a discrepancy I thought I fixed the XML file and thought all was well, but there was still an error. Upon further studying the configuration file I found more errors; such as, not closing off the string of code (</examplelayer>). My file still wasn't working, but after longer inspection I realized I had a spelling error on two lines of code with the same mistake. After that was fixed the widget worked well and there were no other problems.

Although it was frustrating, this helped me learn the layout of how an XML file looks much better than if I had just typed out everything properly the first time.

Lab 2: Geospatial Web Services

Goal:
Successfully create and publish a geospatial web service using ArcGIS Online for Organizations and the ArcGIS server hosted by the Geography and Anthropology department here at UW-Eau Claire.

Methods:

Part 1:
The first task was to create a map on ArcGIS Online. To do this we had to download a zip file containing various feature classes for Wisconsin; such as, lakes, streams, the counties, cities, interstates, highways, etc. within Eau Claire.

Since we were not going to use all the feature classes for this first map we needed to sort the data. We did this in ArcMap by bringing in the counties, cities, interstates, and highways. Once all feature classes were in the map we compressed the map (send to- compressed (zipped) folder).

Once our folder was zipped we headed of to ArcGIS Online and added the zipped folder by browsing the local files. The only things that remained was to add a title, summary of the map, and give it the appropriate tags. Tags are important because they enable a client to search for relavant data. Below in figure 1 you can see the image of map created.



Figure 1.

Part 2:
The next task was more complex. Again we were trying to make a map and upload it to ArcGIS Online; however, this time the map was created using an Excel spread sheet with latitude and longitude data for fire occurences in Wisconsin 2004.

To make this map we had to open up an Excel file with data containing X- and Y-coordinate data, as well as fire occurence data. Before the data could be uploaded to ArcGIS Online, it had to be converted to a CSV file (comma separated file). This was simply done by going to 'save as' then in the drop down menu for 'file type,' the .xlsx had to be changed to .csv.

The next step was important. When uploading the data to ArcGIS Online you had to click the reticule for loacating features using 'Latitude/Longitude.' In this same menu there was the field names, field types, and location fields for your .csv file. The 'POINT_X' row needed to be changed to longitude, and the 'POINT_Y' to latitude. After this was done, the map needed to be more user friendly. To change the map we had to go to the legend and click the "configure Pop-up." This brought up fields for OBJECT_ID, FIREDATE, FIRE_YR, POINT_Y, POINT_X, and FID. For this assignment we only wanted the firedate to show up, so we unchecked all the boxes leaving only the firedate. This made it so the feature service would only show the fire occurence date for each location when clicked on in the map. The results from the .csv file can be seen in figure 2.



Figure 2.