Friday, April 24, 2015

Network Analysis

Goals and Objectives: The goal of this exercise is to get a better grip on how network analysis is used in a real world scenario. The scenario we had to find the shortest transportation routes for sand mine trucks to the nearest railroad terminal. The constant back and forth driving of these trucks damages the road and it cost the residents of that county's money to fix those roads. Using the network analysis tools we can find the shortest distance and how much the damages cost. be sure to note the number of trips and cost is hypothetical.

Methods: The first operation was to create a python script that would select sand mines that were active, were not connected to a railroad terminal, and were 1.5 km away from a railroad. Once this was completed it was saved to the created geodatabase for this exercise. Next we added the street network dataset to our ArcMap and made sure to turn on the Network Analyst Extension. The results from the script and all the rail terminals were then added to the map. Next using the network analysis toolbar we created routes that were connected to the closest facilities. The closest facility tool helped determine the closest rail terminal to each sand mine. The next step was to use Model Builder to create a workflow that would help generate the results we would need to find the shortest route and cost. First we needed to add the streets to the closest facility tool. The result then had locations added using the mines_norail_final and trucks_rails_terms2. Once solved the routes are then selected and the copy features tool is used to save the selected features to the geodatabase in my work folder. I projected the routes along with the Wisconsin County Boundaries using the Wisconsin NAD_1983_HARN. After intersecting the two projected results I did a summary statistics to find the distance of route within the counties. I then converted the meters into miles using the equation [SUM_Shape_Length] *.00062137. To find the cost I took the distance result from the newly created field and used the equation [Distance] *2.2 *100. The result ends up showing the distance in meters, miles, and the cost per county.


Figure 1: The model builder used to calculate distance and cost for the counties



Results: The results shown below are the python script that was used to generate the mines. The table is what was created using the Model Builder. The map below shows the shortest distances to the rail terminals and the cost to each county. The results show that Chippewa, Dunn, and Wood County are the most effected by the cost. It is interesting to see Eau Claire has no sand mines but with routes going through it there is a nice price to pay for the trucks transporting the sand.


Figure 2: The python script used to select certain mines.

 
 
Figure 3: The resulting table from model builder showing the distance and cost.

 
 
Figure 4: The map showing the shortest routes and cost per county.





Conclusion: Working with Network Analysis was new and exciting. I was able to take the mine locations and find routes that would get the trucks to the closest rail terminal. This would help keep the trucks off other roads and make it cost less for the counties to repair. It is still unfair for the counties that would have to pay for the trucks damage to the road even though the county has no sand mines in them (i.e. Eau Claire, La Crosse). As I said before these results are hypothetical so we can not be sure that they are accurate to a T. 

Sources: WI DNR, ESRI Street Map USA
















Friday, April 10, 2015

Data Normalization, Geocoding, & Error Assessment

Goals and Objectives: The main goal for this lab was to take the data provided by the Wisconsin DNR and locate all the sand mines using geocoding in ArcGIS. Geocoding is needed because we have to normalize the data that is incorrect. These errors make finding the locations harder than it needs to be for whoever is using the data. We also needed to compare our normalized data with the actual locations of the sand mines so that we could see how far off we were on the distances between the two points.

Methods: Our first step was to normalize the data that was given to us. Some sand mines had an address and some used the PLSS for their locations. There were even mines that had both. To help normalize the table I had to separate and create new fields such as PLSS, Street Address, City, State, and Zip Code. Some fields that didn't have an address or PLSS I just left blank. Using the Geocoding Tool in ArcGIS the addresses where placed on the map. The problem is most of these addresses was that they were in the wrong spot. With the PLSS the address won't even map, I had to use the PLSS quarter-quarter layer to pinpoint an address for the mine. Once I figured out where all the mines were I used the Merge Tool to combine the mine locations that my classmates had to geocode. Now the actual mine locations were to be added the map so that we could see how close the geocoded locations to the actual locations. For this I used the Point Distance Tool which showed the distance between each of the mines.



Figure 1: (Table 1) This is a picture of the WI DNR data that we received. This table is an example of data that is not normalized

Figure 2: (Table 2) This is a picture of that same data normalized and using the new fields such as PLSS, County, etc.


Results: Here are the results comparing where the geocoded mines are in relation to the distance of the actual mine locations. The purple dots represent the sand mines the class located and the green dots show where the mine is. The table shows the distances between the actual and geocoded mines locations.


Figure 3: A map showing the geocoded and actual sand mines across WI.


Figure 4: This is the table that shows the distance between the two locations


Discussion: There are always going to be people out there that cut corners and don't provide the best work. With gross, systematic, and random errors it can mess up data that really shouldn't be too hard to mess up in the first place. The problem with the table we got from the WI DNR was that there was operational error. The information placed in the table was disorganized and this made some of the attribute data input confusing.

Conclusion: This lab taught me that fixing other peoples mistakes can take up a lot of your own time. From normalizing the data to locating it on a map it can get a little hectic. The main point is to check for data accuracy because even though you may geocode you might not get the address that matches up on the map.

Sources:

Wisconsin DNR

Lo, C. P., Albert K. W. Yeung, and C. P. Lo. "Chapter 4." Concepts and Techniques in Geographic Information Systems. Upper Saddle River, NJ: Pearson Prentice Hall, 2003. N. pag. Print