GIS II Post 4: Network Analysis, Closest Facility Routes for Sand Mining in WI

Goal:

Learn Network analysis and the various solvers within the tool.

Objectives:

The objective for this exercise is to calculate the impact Frac Sand mining has on Wisconsin's roads. Since the primary method of shipping is by dump truck to rail road, the analysis will focus on trips from the sand mine to the rail road loading sites, or "rail terminals."
Outline

1. Load features into the Network Analysis Window
2. Calculate a route
3. Calculate a closest facility and route
4. Build a model to calculate the closest facility route
5. Claculate the cost of sand truck travel on roads by county

Map 1 Locator map of the Counties in Wisconsin which contain
a Frac Sand Mine and/or Railroad Terminal.

Data Sets:

Railroad Terminals - Point feature class
North America Street Network USA Dataset - Network dataset created by ESRI.
Geocoded Sand Mines - Point feature class, sand mines found and cross checked by GEOG 339 students, 120 total WI mines.


Methods:

TOOLS USED:
Add Locations
Make Closest Facility Layer
Solve
Copy Features
Select Data
Project
Intersect
Summarize
Add Field
Calculate Field

The main tool used during the project was Model Builder within ArcMap. Using the search tool to quickly navigate the ArcToolbox, it was easy to find the tools needed to accomplish the various tasks. Once all the feature classes were created, all that remained was to calculate the total miles each of each trucking route per county; and, ultimately calculate the cost each county would pay for maintenance of roads per year. Model 1 shows the process of adding the various feature classes (in turquoise):

050_000 = Shapefile of Wisconsin
streets = ESRI's Street Network
Mines_AOI = Frac Sand Mines in West Central Wisconsin
Terminals_LoadingSites = Point feature class of Rail terminals & Railroad Loading Sites

Model 1 Model of Closest Facility solver with the end output table showing
cost of trucking Frac Sand across each countys' roads



 

 

To Calculate the Trucking Cost Per County (dollars) / Year

Several assumptions were necessary:

1. Each sand mine would use 50 trucks per year.
2. Each truck would travel from the sand mine to the rail terminal AND back.
3. The cost per truck mile is 2.2 cents.

Final Equation:

Trucking Cost = (SUM_Shape_Length x 0.000621371 x 0.022) x 100

Explaining the variables and numbers:
SUM_Shape_Length : was the total distance of all the routes in that county (map units = meters)
Conversion factor :  1 meter = 0.000621371 miles
Cost of each Truck / mile : 2.2 cents
Number of trucks / year, traveling to and from rail terminal : 100

Results:

The results were pretty straight forward. Certain roads were more highly traveled than others due to the way the road network was layed out. Unfortunately I did not record what the impedance was set to for the routing. However, I can make an informed decision based on the information in the output table. I assume, with confidence, that distance was the cost being calculated and regulating which routes were ideal. Map 2 shows the routes taken (red) from each sand mine (turquoise circles) to its respective rail terminal (mustard R&R circles).

Map 2 Map of West-Central Wisconsin illustrating the sand mines (not an exhaustive
representation) in the region as well as their respective rail terminals and
the roads the trucks traversed to make it there.

After a visual analysis was performed. A more accurate measurement per county was applicable. As Graph 1 shows, for the sand mines and rail terminals included in this study, La Crosse county had the greatest expenditure necessary to maintain it's roads.

The distance traveled in miles per county was also measured, but I found it redundant to include another graph. Instead, Table 1 shows the output statistics created by Model 1 previously shown at the top of the page.

Table 1 Shows the three statistics calculated for this exercise.

Some nnoteworthy observations from Table 1deal with the leaders for each trucking statistic. 1) La Crosse County has the greatest number of total miles travel and road maintenance costs, yet only ranks 4th among Wisconsin counties for the number of trucks that travel its roads each year. The leader for number of trucks transporting frac sand each year is dominated by Trempealeau County, a surprising 150% more trucks travel its roads based on our model.

Discussion:
Although this was a fun and interesting project, it wasn't without its flaws. First of the impact on the roads was calculated to be constant throughout the travels. In reality the trucks weigh much more on the destination trip with a full bed load of sand than they do coming back. Next, the method assumed that the truck would travel to the rail terminal AND back. I imagine that the trucks do not religiously come back to the sand mine after every delivery.  

Conclusions:

The focus of this project was to have a crash course in Network Analysis and by the end feel comfortable with the general procedure. Along the way more routine tasks had to be repeated which helped reinforce the important steps in the process; such as, adding a new solver (i.e. Closest Facility layer, or new route). Continued projects within the Network Analyst are sure to occur given the expanding field of GIS and the amount of applications and power of Network Analysis.

Sources:

ESRI's Street Network
W:\geog\ESRI\streetmap_na\data\streets

GIS II Post 3: Geocoding Frac Sand Mines of Wisconsin

Goals and objectives

This exercise will focus on the process of finding addresses, specifically sand mines, normalizing those addresses, and learning about the different forms and sources of error.

Outline:

1. Download and explore data from the Trempealeau County Land Records Division
2. Download an updated list of mines from the WisconsinWatch website
3. Connect to the geocoding service from ESRI
4. Geocode the mines with street addresses using the ESRI address locator
5. Connect to the department ArcGIS server
6. Geocode the mines with PLSS manually
7. Compare your results with the results of your colleagues in class

Methods  

This lab started out at the Trempealeau County Land Records Division, where a database of Trempealeau County was downloaded. This database contained a variety of boundary feature classes along with emergency system features, recreational classes, and a few transportation feature classes. Next a list of existing sand mines in the state of WI was downloaded from WatchWisconsin.org. Upon further review it was clear that the addresses were not normalized, thus they had to be prepared before the mine locations could be geocoded. Geocoding is the process of finding associated geographic coordinates, often expressed as latitude and longitude, from other geographic data, such as street addresses, or ZIP codes. Table 1 shows the mine locations before normalization. Some had complete street addresses, others were in the Public Land Survey System (PLSS) format, and many were incomplete versions of one or the another.


Table 1 Shows the 14 mines I needed to find. The data is not ready for geocoding.

These incompletions could be the result from inaccurate records or error. There are three types of error: 1) gross, 2) systematic, or 3) random. The first source of error is a mistake, a blunder, or the technical name, a gross error. These can occur from writing down the wrong value, reading an instrument wrong, etc. They are not specific to humans and the only way to correct for them is with careful procedures and persistent checking of our work. Systematic errors are those which can be accounted for by mathematical models. This is because systematic errors have a pattern to them. Lets say a remote sensing instrument consistently measures data erroneously because of bad calibration--if the problem in the calibration can be understood and accounted for, then that error is called systematic. Systematic errors usually affect accuracy. The final source of error is random. Random error cannot be controlled. Random errors are often introduced in little bits at each stage of data collection and processing. Random error cannot be corrected but it can be accounted for. By using statistics like mean, median, and mode, the severity of random error can be decreased.

Whatever the reason for the lack of consistent complete addresses, they still needed to be found. Although there was a field in the spreadsheet which stated the business in charge of the mine, most often this didn't help locate the mines. Usually searching across city websites, blogs, aerial photographs and user intuition were combined to located the addresses. As a class we geocoded all the mines combined, but individually we only had to geocode 14 mines. Table 2 shows those 14 mines in a normalized for geocoding format.

Table 2 Shows the data as normalized as possible with the provided information.

Once the addresses were found we uploaded them into a community folder and waited for the rest of the classmates to contribute. Once everyone uploaded their mines it was time to commence with he geocoding.

The mines with correct addresses were geocoding friendly and a point was added without a hitch. However the addresses in PLSS were a manual process. You had to "pick the address from the map," which was the technical term used in ArcMap's geocoding service. This process was carried out by adding a shapefile of PLSS quarter-quarter-sections and given a hollow symbol. This grid, along with the identify tool, allowed for a systematic approach of locating the mine. Table 3 shows a table with the match score for 14 addresses I geocoded.

Table 3 The "score" field shows how close the location of the address was to an address in real life.

Next a new shapefile was created compiling all the mine locations, except for the mines personally located. The new shapefile was then queried again to separate only those mines which shared the same Unique ID as those mines that I had found. This shapefile was then used in combination with the "point distance" tool to test how accurate the mines were. Figure 1, shown below, illustrates how the point distance tool works.

Figure 1, The point distance tool takes two input point datasets and finds the distance from one point to the next. The output is a table which contains record of the input point (INPUT_FID), the nearest point (NEAR_FID), and the distance between the two points.

Results

After both methods of geocoding were performed, my mines finally had a spatial component to them. Image 1 shows the distribution of those mines. Another interesting distribution came when looking at all the mines sharing the same UNIQUE_ID as the sand mines given to me.

Image 1 Shows most the 14 mines I found
spread across West-Central Wisconsin.

Figure 2 Shows the spatial distribution of
all my mines and those that shared the
same UNIQUE_ID field.

Table 4 (below) shows just how close, and far, some of the mines were, in relation to my own mines.

Table 4 A selection from the 750+ results the point distance tool gave as an output.

The mines appear to be similar, however some of the mines that were far off were by thousands of meters. Image 2 shows one such mine which clearly is not in the correct location. Some of the mines I had to add manually, in this case scale could have been to blame.

Image 2 A geolocated mine in the middle of an urban area, a clear error.

Conclusion

In conclusion, this was an effective exercise in demonstrating an important skill set. The process of geocoding is relatively straight forward, but when not all the data is provided, creative and critical thinking are needed. Becoming more familiar with the process of geocoding as well as the many types and sources of error is an important first step on the way to mastery. As more larger scale projects and complex geocoding jobs come along it will be important to remember the foundations behind geocoding and how to avoid error.

Sources

Trempealeau County Land Records Division
http://www.tremplocounty.com/landrecords/

WatchWisconsin.org
http://www.wisconsinwatch.org/2012/07/22/map-frac-sand-july-2012/

GIS II Post 2: Data Collection and Geodatabase Design

Goals:

Data provides the foundation for all GIS projects. So naturally finding different ways to acquire this data is very important, as many GIS professionals discovered with the shut down of the government websites during the shutdown. So knowing a wide variety of geoportals is important in acquiring data. This lab is designed to familiarize ourselves with acquiring data and knowing how to correctly process the data for later use.

Objectives:

• Download Data from four geoportals
• Import and process data
• Build a geodatabase for AOI (Trempealeau County, WI)
• Create table of data quality measures

Methods:

Data Acquisition

National Atlas -

• Railroad.shp at the 1:1,000,000 scale

USGS National Map Viewer - 

• NLCD 2006 Land Cover Data 
• National Elevation Dataset (1/3) arc Second - Staged in ArcGrid format

USDA Geospatial Data Gateway -

• LULC data for the state of Wisconsin

USDA NRCS Web Soil Survey -

• SSURGO data for Trempealeau County
• SSURGO is an acronym which stands for "Soil Survey Geographic Database" or "Soil Survey Geographic." SSURGO comes in the form of digital soils data produced and distributed by the Natural Resources Conservation Service - National Cartography and Geospatial Center.

Once the data was acquired it needed to be properly prepared. The raster of the elevation dataset needed to first build pyramids in ArcCatalog to speed up viewing. This caches tiles at different viewing extents to speed up loading and processing. Once both rasters were viewed in ArcCatalog and added to ArcMap, they were mosaicked together using the "Mosaic to New Raster" tool. Looking at the elevation you can determine the unsigned (no negative values) pixel depth type needed. Since the data has decimals I decided to use the pixel depth floating point, with supports decimals. I also went with the bit depth of 32, because the decimals are enabled; and, even though their is only a change in elevation of 236 m, the values with decimals account for many more than 236 values. So the 32-bit depth is necessary or else data will be lost. Since the rasters are a grey scale only one band is required. I also changed the mosaicking scheme to "mean" so that the overlapping zones were averaged instead of just taking the values from one or the other. Figure 1. shows the two rasters before and after the mosaic. In the mosaic tool I made sure to change the mosaic colormap mode to "match," so the two rasters would look more uniform.



Figure 1. A comparitive view of the two rasters before (left) and after (right) the mosaic process. NOTE: the more uniform coloring of the raster after the mosaic process.

Next the various remaining datasets were downloaded. To prepare the data a geodatabase for Trempealeau County was created and a feature dataset. The projection for the feature dataset was chosen as NAD_1983_HARN_StatePlane_Wisconsin_Central_FIPS_4802_Feet because of the location for Trempealeau County had in the state. Then SSURGO feature class was imported into the geodatabase and a relationship class was created to reference the data using "mukey" as the primary and foreign key. From here on out it was smooth sailing and all that remained was to make sure all the data was in the same projection and the maps were clipped to the outline of Trempealeau county using a projected shapefile downloaded from the Census Bureau. Figure 2 shows all five datasets illustrated by four maps.


Figure 2 All the downloaded data sets.

Data Quality Measures

Key Terms and Definitions:

Scale - in geography scale represents the relationship of the distance on a map/data to the actual distance on the ground.

Effective resolution - In GIS, the smallest allowable separation between two coordinate values in a feature class. The smaller the effective resolution the more precise your data can be.

Minimum mapping unit - For a given scale, the size in map units below which a narrow feature can be resonably represented by a line and an area by a point.

Planimetric Coordinate Accuracy - Is determined by the root mean square error (RMSE). RMSE is the cumulative result of all errors including those introduced by the processes of ground control surveys, map compilations and final extraction of ground dimensions from the map. Limiting RMSE is crucial to data credibility and accuracy.

Lineage - A collection of states representing the changes that have occurred over time in a versioned geodatabase.

Temporal Accuracy - How accurate data is in relation to time; the frequently of data collection.

Attribute Accuracy -  An assessment of the accuracy of the identification of entities and assignment of attribute values in the data set.

Sources:

Definitions taken from ESRI's GIS Dictionary.
http://support.esri.com/en/knowledgebase/Gisdictionary/browse

National Atlas Data
http://nationalatlas.gov/

USGS National Map Viewer
http://viewer.nationalmap.gov/viewer/

USDA Geospatial Data Gateway
http://datagateway.nrcs.usda.gov/

USDA NRCS Web Soil Survey

http://websoilsurvey.sc.egov.usda.gov/App/WebSoilSurvey.aspx

Drainage Index Data from
http://foresthealth.fs.usda.gov/soils/

http://foresthealth.fs.usda.gov/soils/MoreInfo

GIS II Post 1: An Overview of Frac Sand Mining

Overview of Sand Mining in Wisconsin

Possibly a common misconception, but sand mining has been taking place within Wisconsin's boarders for hundreds of years. It has not been until a recent uptick in hydrofracking that the heightened interest of the public has been involved. Because there aren't any oil or gas wells in Wisconsin, the people of Wisconsin's interest is mainly on the sand mines.

What is Sand Frac Mining? Where is it in WI?

In January of 2012 the WI DNR created a map showing the locations of frac sand mines. As figure 1 illustrates, most of the mines are located in west central Wisconsin, with clusters of mines in Chippewa, Monroe, and Trempealeau counties. Although there are some sites that use a special hydraulic dredging technique, dry mining is much more common. So most mines look for the ideal sand to be closest to the surface, such as the Jordan and Wonewoc formations.



Map created by the WI DNR. http://dnr.wi.gov/topic/mines/silica.html 

What Are Some of the Issues Associated with Sand Frac Mining in Western Wisconsin? 

• Destruction of once/future wildlife habitat (hunting is a large part of Wisconsin culture)

• Impact on roads from Transportation.
• Primarily use trucks to railroads.
• One operation is trucking sand to Minnesota where it is being processed, then loaded onto barges and transported downstream on the Mississippi.

• Sometimes sand-bearing geological formations are tightly cemented and need to be 'blasted' to make sand accessible.
• Noisy
• Vibration
• Dust emissions
• May happen as frequently as every day or only once very few months.
• Federal Mine Safety and Health Administration (MSHA) rules require the use of water injection when drilling the blasting holes in order to control drilling dust.
• Blasted materials need to be "crushed," to reduce size of particles.

Overview of how GIS will be used to further explore some of the issues as part of a class project.

From the various websites we have downloaded a wealth of data which will be used to create specific sand mine site criteria. Such as slope grades, sand type, distance from rail road terminals, etc. Using a vast host of tools all these models could be used to help government bodies issue permits or sand companies in deciding where to locate their next mine.

References Cited

Information and figures taken from the Wisconsin Department of Natural Resources's Silica (frac) sand mining page and the corresponding pdf.

"Silica (frac) sand mining." Wisconsin Department of Natural Resources. January 2012. Accessed: 1 November 2013. http://dnr.wi.gov/topic/mines/silica.html

"Silica Sand Mining in Wisconsin." Wisconsin Department of Natural Resources. January 2012. Accessed: 1 November 2013. http://dnr.wi.gov/topic/Mines/documents/SilicaSandMiningFinal.pdf

"What is Frac Sand?" Geology.com. 2011. Accessed: 8 December 2013. http://geology.com/articles/frac-sand/

GIS I Lab 4: Using Overlay Functions to Find Suitable Bear Habitat in Marquette County Michigan

Goal:

The purpose of this Lab is to apply the spatial vector tools learned over the recent weeks. These tools will be used in finding a suitable habitat model for a Michigan county bear population.

Background:

Like any animal, bear have a niche. As we discovered throughout the lab, this niche was in tree cover and within a close proximity to a water source. The DNR wanted to create a habitat zone for bear in this niche, but they could only create habitat zones in land they already managed. So a habitat model for bear within the DNR's land management zone must be created.

Methods:

This lab was once again centered around the ArcGIS program, specifically ArcMap. Inside of ArcMap a variety of tools were used to create a suitable habitat range and narrow down the criteria to the specified overlap zones. The new tools applied to this lab were intersect, clip, erase, buffer, and dissolve.
These tools allow for more complex queries and specified areas of interest. The 1st tool intersect, takes all the overlapping points, lines, or polygon regions from the input features and creates a new feature class. The next tool, clip, cuts an input feature in the shape of clipping polygon. The output feature class has all the same data of the original input feature, but shapes and values inside of the shape of the clipping polygon used. The tool erase works similar to the clipping tool, but instead only keeps the data on the outside of the erase polygon. One of the more useful tools, is the buffer tool. This tool takes an input feature and creates a polygon around the original point, line, or polygon with a user designated distance between them, or a "buffer." Finally, the dissolve tool is used to erase or "dissolve" the internal boundaries. This would be used if nearby points had overlapping regions and you only wanted the union of the two buffer shapes, not the specific circles for each buffer region.

The data flow model was created using Microsoft Visio.

Results:

The bear population lived in a relatively specific niche. There were 68 bears in Marquette County, Michigan. Of the 68 bears, 62 of them lived in three varieties of forest cover: mixed forest land (31), forested wetlands (17), and evergreen forest land (14). Also noteworthy, 72% of all the bears were found within 500 meters of a stream. This data, in combination with the DNR management zones, was used to create a bear management model as seen in Figure 1.





Figure 1. Marquette County Michigan DNR Management Model.

 

Figure 2. Data Flow Model for the DNR management model.

 

Data Sources From Michigan Geographic Data Library:

Landcover:
http://www.mcgi.state.mi.us/mgdl/nlcd/metadata/nlcdshp.html

DNR Management Areas:
http://www.dnr.state.mi.us/spatialdatalibrary/metadata/wildlife_mgmt_units.htm

Streams:
http://www.mcgi.state.mi.us/mgdl/framework/metadata/Marquette.html

GIS I Lab 3: Introduction to GPS

Introduction:

 

The purpose of this lab was to familiarize ourselves with the general process of collecting data with a GPS (create a personal geodatabase, collect data in that geodatabase, then making a map with the data).

 

Methods:

 

For data collection, a Juno 3B GPS unit was used. Prior to collection, a geodatabase was created in ArcCatalogue. In ArcMap: points, lines, and polygon feature classes were created. A raster image and campus buildings shapefile (shown as brown polygons in Figure 1) were also brought into ArcMap. Next the data was exported as an apo. file to the Juno unit and ready for data collection.

 

Results:

 

As Figure 1. shows the data collected wasn't very accurate. Although most of the time my PDOP value was under 2.0, my data still wasn't very accurate. The Juno unit should have given me 2-5m accuracy. However, there were many multi-path errors in the form of buildings and trees. The main source of error probably came from the atmosphere in the form of overcast skies. There was a mixture of rain and snow, so I imagine the error from the Troposphere was higher than usual. In conclusion I wouldn't recommend mapping out sidewalks with a GPS, digitizing would probably work better.

 



 

Figure 1. Collecting points, lines, and polygons on the lower campus mall at UW- Eau Claire.

Problems/Solutions:
I had two hiccups during this exercise. The first came when my project file wasn't loading on the Juno unit. I think the issue revolved around my data dictionary. I ended up checking out a new unit and going through the creation of my dictionary again and re-deployed the data successfully to my new Juno unit.

The second problem came when trying to "check-in" the data to the mxd. would show the data collected. Apparently when trying to remove some of the clutter in my folder I deleted the old data for the first Juno unit. In the process I deleted the geodatabase for my points, lines, and polygons. To fix this I created a new geodatabase and brought the data back into that geodatabase.

GIS I Lab 2: Downloading GIS Data

Introduction:

The goal of this lab was to become familiarized with retrieving data from the Internet. There are countless data sets to choose from, so knowing your area of interest, or AOI, is important before downloading your data. The AOI for this lab was the state of Wisconsin at the county level, specifically the populations and a variable of our choice, in my case, the Median Age of each county.

Methodology:

This lab started out at the U.S. Census Bureau's American Fact Finder website http://factfinder2.census.gov/faces/nav/jsf/pages/index.xhtml. Here, we downloaded the Total Population data for WI by county. Next the shapefile was downloaded. Since the files were zipped, they needed to be unzipped so the data could actually be utilized. As the data was a ".csv" file it needed to be converted to an Excel file before the data was brought into ArcMap. This was accomplished by opening up MS Excel and saving the population data as an excel file (.xlsx). Now the data could be brought into ArcMap and added to the data frame. However, the shapefile didn't have any population data yet. To get the shapefile to share the attribute data of the Excel file a 'table join' was performed using the common field of "GeoID." From here it was just a matter of making a cartographically pleasing map by picking an appropriate color ramp, adding a legend, title, etc. This process was repeated with another the Median Age of each county.

Results:

As the map shows the median age is higher to the northern part of the state where the population per county is less. Other observations were the decreased median age in counties with a major college in them.

Problems/Obstacles:

I originally wanted to map the age groups and gender of WI. Although there were many categories and it would have been hard to show all of the data. I thought maybe I could throw out the county choropleth map, and instead map the weighted mean center of each age group by gender. However, that wouldn't have fit the parameters of the assignment so I had to download another data set.

GIS I Lab 1: Base Data

Goal:
The goal of this lab was to familiarize ourselves with various data sets used in public land management and to prepare base maps for the proposed Confluence Project in Downtown Eau Claire, WI.

Background:
The driving force behind this project was a hypothetical internship. As an intern at Clear Vision Eau Claire, you are tasked with constructing a basic report communicating any relevant information as well as base maps to describe the Confluence Project. This project will add a general housing building for future art students at UW-Eau Claire as well as a new Theatre/Arts building to host future University performances and other important venues in the city.

Methods:
The process was relatively straight forward. First up was to digitize the parcels bought by the Haymarket Concepts LLC. These buildings are located at 128 Graham Ave & 202 Eau Claire St. After a feature class was created in ArcCatalog containing the newly digitized shapefile, the projection needed to be set. Using the projection from an existing feature class, the projection was added to the recently created feature class. As I was not confident in my knowledge of the Public Land Survey System (PLSS) I had to read a basic introduction to PLSS from the Wisconsin Geological Survey website. This relatively short article went a long way to help further my understanding of parcels and land organization. With this knowledge I was able to fashion a short report giving the addresses of the two buildings, parcel numbers, PINs, owner, the owner's address, and legal description; and for clarification, a small .jpeg to clarify the respective addresses. Once all this was out of the way I was able to start the actual map making.

The freedom of design was a little restricted with the parameters of having six maps (civil divisions, census boundaries, PLSS, parcel data, zoning, and voter districts) and various features such as center lines of roads, labels on counties, the confluence project identified for all maps, and various other features. The skills I fortified most revolved around the formatting and manipulation of the legend, scale bar, and symbology. Since there were many elements to catch the eye, I found it difficult at times to portray information accurately and legibly without detracting from other features.

Noteworthy obstacles:

• normalizing the data for the census boundaries (pop/sqmi)
• getting the labels on the voter districts in the correct locations
• grouping similar categories for the zoning map. 

The first problem simply evaded me because I wasn't trying to answer the parameters of the map right away. The second came when I was completely finished and I realized the district labels weren't accurate. At first I thought maybe the projection was off, then I realized the text box for the 'confluence project' was pushing the labels out of the way. From there it was a simple fix of moving the label. Lastly, the zoning map. Since the labels were each category were coded, I had to look up the labels for each zoning category. Once I realized many of them were similar yet different, I had to differentiate between what data was similar enough to put in the same group (i.e. high rise apartments and two bedroom houses, both housing, are they different?) and what needed to be in two separate classes. Getting them into the same class was also a chore, but after playing are with highlighting the data and right clicking in a few different places I was able to group them together properly.

Results:
Civil Divisions Map: This map shows the county boundary of Eau Claire, as well as the city of Eau Claire and the townships dividing it.

Census Map: This map shows the confluence project as well as the tract and block groups. The block groups are normalized by population per square mile.

PLSS Map: This shows the location of Eau Claire with the dividing lines of the public land surveying system.

Parcel Map: This shows the parcels in close proximity to the proposed Confluence Site as well as the roads and water bodies. The water is important because this is the location where the Eau Claire and Chippewa rivers meet and thus gave birth to the name of the "confluence" project.

Zoning Map: This showed the various zones of Eau Claire, specifically of those close to the confluence site. This digitized view shoes the location of shopping, business, industrial, public, residential, and transportation zones. As well as the proposed location of the confluence site and the center lines of roads.

Voter Districts Map: This shows the boundaries and district number for most the city of Eau Claire.