Final GIS II Lab ~ Python

Introduction:
     The goal of this lab is merely to acclimatize myself to python script and coding.  Over the past week or so, the class has taken on the challenge of learning some python code and we have practiced with it both in ArcMap and using a python shell (IDLE).  This week, we graduate to performing iterations and while loops, culminating in the exercise posted here.  The end product a quickly and cleanly generated script which includes an iterative feedback loop to draw five buffers.  These buffers will be formed around a provided point feature class, representing Trempeleau County sand mines (sound familiar?).  Ultimately, the script will produce a series of buffers around each mine, representing a distance of one to five kilometers from the nearest mine.

Methodology:

Fig 1:  Python script utilizing the Arcpy module to iteratively buffer around 

     Using the Python window in Arc, the above script was entered (fig 1) and run in the ArcMap environment.  The first task which it accomplishes is to import the arcpy module and the environments from the .mxd in which the script is being run (line 3, env.workspace= ...). Then, the script sets a "counter" variable on line 4 (i=1), which will hold the number of times the loop as been completed; a similar representative variable for buffer distance is formed.
     On line 6, the while loop begins.  What this bit of python syntax does is parse the nested code (indented, lines 7-9) if the condition provided (line 6, i<=5) is true.  After  performing the nested code, the the computer then returns to line 6 and reevaluates whether the condition has changed, and if it has changed while remaining true it will reiterate the nested code again until either the condition no longer changes or is no longer true.  Specifically, what this while loop does is create a buffer (line 7), then increase the buffer distance by 1000 meters and increase the counter variable by 1; thus each iteration will create progressively larger buffers while increasing the counter value.  Once that value exceeds 5, the loop will cease to be parsed and the script is done running.

Results:

Fig 2: buffers of up to 5km around sand mine addresses in Trempealeau County, WI.

Discussion:

     I found this exercise to be an easy and effective method of completing a project.  I almost wish that I had started GIS by running scripts in Arc, I wonder how much time I could have saved myself by now!  At the same time, while working with other students I was quickly reminded of the finnicky nature of coding which can be a quick draw on one's patience.  This is not a skill that one can simply pick up by looking at it; but the potential value that scripts bring as processes for automation seems nearly endless.

GIS II Project ~ Phase 4

Introduction:

Lab 5’s goal is to familiarize myself with raster analysis while developing a faux model for terrain suitability and environmental risk of sand mining in Trempealeau County, WI. I will use Elevation, Land Use-Land Cover, Slope, Water Table, and Railroad rasters to determine optimal locations for a sand mine in the county; then DNR hydro, prime farmland, county schools, recreational, and existing mine data will be used to determine locations within the county where a silica sand mine is not desirable. These two indices will then be compared to find the optimal locations for construction of a new mine.

Methods:

   Part I

Fig 1: Suitability Index

The first section, the suitability index (fig 1), begins with the consideration of geologic bedrock data gathered from the MRLC. The Wowenoc and Jordan formations are given as significant locations of silica sands, however the data provided is only a raster base map. There are two options for how to proceed to get this information into a format that can be analyzed: digitization (with which we are familiar) or elevation can be, in this case, used to interpolate the location of these formations because of a relationship between surface elevation and the formation of these bedrock layers. This process consisted of developing contours from the Digital Elevation Model retrieved from the Trempealeau county geodatabase, then comparing them against the geologic formations given in the base map.

Once the elevation range for these layers was determined, a ranking of the county’s territory was developed by reclassifying the original DEM into three regions delineated by elevational proximity to the aforementioned elevation ranges correlating with the Jordan and Wowenoc formations.  The regions that best fit the geologic layers were given “high” ranks of three, and the most distant received ranks of one.

With the DEM, the slope tool was also used to find %rise/%run in the county. From this data, Trempealeau was also divided into three regions based on the suitability of an area’s slope for construction (smaller slope=better).  Again, this coefficient was ranked one to three, as are the rest of the interpolated values.

The land use raster that was downloaded for Lab 3 was also used in the terrain analysis for this Lab: the county was reclassified based on the suitability of each area for constructing a mine. For example, an open field or barren land would be ranked highly whereas a forest would rank low because of the differential in ease of construction between the two parcels.  

The last factor considered in land suitability for the sand mines was the water table level. Silica sand mines use water in the process of extracting sand, therefore a higher water table (closer to the ground surface) merited a higher suitability coefficient.  The exact cutoffs for these factors were determined by examining the histograms of the final rasters produced, that values can be found in the table appended to the end of the methods section.

Finally, Raster Calculator was run to add the three coefficients together, piecing together the final Trempealeau Silica Sand Mining Suitability Index. Five coefficients ranked 1 to 3 means a range of 5 to 15.  Areas of urbanization and open water were also removed from the index, because it would be entirely impractical to construct a mine in those locations if not impossible.  The final mapped index can be found in the results section below.

   Part II

Fig 2: Unsuitability Index

The second portion of this exercise is to find areas in which a silica mine would be unsuitable for its surroundings, in particular the environment and local residents (Data Flow model in fig 2). This begins with an examination of potential impact of a silica sand mine on Trempealeau streams. To determine the risk of impact, a Euclidean Distance tool was used to find the distance of each cell within Trempealeau County from the nearest stream. From this distance, the county was divided into three regions of contamination risk determined by that distance. After viewing the stream-distance data that was generated, the region was ranked into three areas representing proximity to major streams.  This method is similar to the method for part I, however where in part I areas of high desirability were ranked highly, the opposite is true here and areas most suitable are ranked at a lowly one.

Schools, residential zones, and existing mines are similar to streams in that proximity to them is undesirable, and as such they both used a similar method to divide the county into zones of proximity. The difference with these two features was that they weren’t discrete features in the data provided by Trempealeau County; however they could be derived from the parcel and zoning data that was provided. The features were first selected out, then had the Euclidean Distance tool applied to them before finally being reclassified. Also, because of the intense noise produced by mining operations, it has been determined that 640 meters is the minimum distance that they should be located from hoses or schools, therefore those regions were excluded from the final analysis by using the Boolean “And” in raster calculator.  As for the distance from preexisting mines, obviously it is detrimental to compete for sparse local resources in addition to extra taxing on the local atmosphere to place mines too nearby.  Therefore a distance tool was run similar to above.

Agriculture is integral to the economy of Wisconsin, and Trempealeau County is absolutely an example of this. As such, in the Trempealeau County geodatabase that had been downloaded is data for “prime farmland,” agricultural land which is important not just to the local farmers but to the state as a whole.  This prime agro land is what received the highest value in this section of the exercise, and lands that were designated as never good for farmland received the highest.

The last coefficient to be determined was the effect of potential mines on recreational tourism in the area, in particular on the hiking trails.  The factors for both models are given in Fig 3 below.

The Suitability Factors used for Trempealeau County

Fig 3: Suitability Indices

Sources:


Trempealeau County Geodatabase, downloaded from the official Trempealeau County Land Records Division http://www.tremplocounty.com/landrecords/.

National Land Cover Database from the Multi-Resolution Land Characteristics Consortium. http://www.mrlc.gov/nlcd01_leg.php

Wisconsin Geological and Natural History Survey’s digital dataset of Trempealeau County: http://wisconsingeologicalsurvey.org/gis.htm

Results:

Fig 4: Suitability Index

Fig 5: Unsuitailibty Index

The results of the analysis (indices 4 and 5) speak for themselves.  Urban areas are clearly to be avoided in developing a new sand mine, especially particular to this was the exclusion of 640 meters around residential and developed land in the Unsuitability Index, with large swathes cut out around the relatively quite small urban areas in the county.  For comparison, I have included a model without the exclusion of these areas as to view the (un)suitability of the area excluded by this single factor (fig 6).  These indices could be subtracted from one another in order to derive a general suitability model for Sand Mining in the county.

Fig 6: Unsuitailibty Index, with urban areas included.

Lab 4 ~ Habitat Suitability

Introduction:

            The goal of this Lab was to familiarize myself with some overlay, generalization, and extraction tools integral to GIS while building a habitat model for black bears in an area of interest which focused in Marquette County, MI.  Ultimately, I intend on importing x,y data to the GIS, determine if bears can be found near streams, figure a suitable habitat for bear management and provide a cartographically pleasing map to showcase my effort.  I will also develop a data flow model to document my methodology.



Methods:

Results:

Sources: Source Data was obtained from the Michigan Geographic Data Library thru Professor C. Hupy.

Lab 3 ~ The Handheld GPS

Introduction and Background:

                For this lab, the objective is to simply digitize a handful of real-world features into a GIS by using a Global Positioning System (GPS).  Martin Goettl and the UWEC Geography Department provided the students with Trimble Juno handheld GPS units with which we would collect point, polyline, and polygon features nearby on campus.  Before collecting the data, we will need to familiarize ourselves with geodatabase construction and deployment of a geodatabase to a mobile device using ESRI ArcMap and ArcPad.  Finally, we are going to import the data back onto the computer and develop a cartographically pleasing product which shows three trees and lightposts, three triangular plots (which will turn to lawn in the spring), a nearby circular sidewalk feature and the nearby bridge.

 

fig 1 The Juno. Pulled from the interweb, this was not my exact Juno. It is the right model though. Virtually identical.

Methods:

                Step one is to develop a geodatabase using the Arc platform.  In our case, using ArcCat 10.1, this is accomplished by right clicking on the folder where the database will be stored, then under ‘new’ either “File-” or “Personal Geodatabase” is selected (fig 1).  Using a similar method, but clicking this time on the database, three new feature classes were developed: one point, one line and one polygon.  The feature classes were created using the NAD83 Wisconsin HARN in meters because it is a fairly accurate projection which is common throughout the state.  Also created was a field for each labeled “type.”    The ArcPad Data Manager extension in ArcMap was then used to export the data to the Juno device.

fig 2 adding a geodatabase

                With the important information loaded onto the handheld GPS, it was taken outside to collect the required feature data.  Before doing so, it needs to be ensured that the GPS unit’s almanac is up to date and if it needs updating the user should be sure to do so (fortunately, mine was fully updated).  To digitize the data, I used point averaging to collect the lights and trees (points) as well as the vertices of the triangles and circle.  Instead of using point averaging, I tried a tracklog for the bridge over the creek (which collected my position at points over a time interval).

                Finally, the data was uploaded to the computer using the Data Manager described earlier.  As a couple of triangles had extraneous vertices, possibly from user error, I edited these points out of the data.  It was then symbolized and made into a map.

fig 3 My raw data was contaminated by extra vertices. They could either be GPS burps, or user error. It is impossible to say for certain.

 

Results and Discussion:

                Completion of the project itself required relatively few steps), though learning to successfully navigate the foreign ArcPad controls was something of a headache for myself, which perhaps led to my interesting polygon features (fig 3).  This can be easily fixed in the Juno unit or in ArcMap though.  If I were to redo the project, I would definitely rely on point averaging for the path across the bridge, because -not surprisingly- the tracklog does not provide as accurate data as the point averaging.  This is not to imply that the average of ten points with the small Juno unit is necessarily accurate, because as can be seen in the final result it is not.  Well, it is to a point.  That point just happens to be small features such as the smaller triangles and circle.  In fact, I am a little surprised that my circle is as circular as it is.

fig 4 My final Presentation

The background aerial imagery given for the project was a year or so old, and had not been updated to reflect the fact that a fairly large neighboring building had been demolished, and a replacement built to its south.  The sidewalks over the area have been completely altered, and another completely new building in the north is in the process of going up, so the features I processed seem fairly out of place on the given image.  I pulled a more recent image from another class which was aerially mapping campus and had taken an image less than a week before I digitized the features.  The difference in the presentation of the final project is staggering.

GIS II Project ~ Phase 3 Network Analysis

Introduction:

     The function of this exercise is to develop some basic network analysis skills by working with the mine data developed in Phase 2.  During this project, I will load the geocoded locations of the silica mines in Wisconsin along with given state road data and locations of state railroad terminals.  I will run an analysis along the road network to find the most efficient route from the sand mines to rail terminals: shorter routes are desirable because a shorter route means lower time and gas requirements of getting the sand to market which adds up very quickly over the life of a silica mine.  After completion of this task, I will parse out these optimal routes by county and estimate the cost to each county for infrastructure maintenance related to the transportation of these operations.


Methods:

     As described in the intro, the first step in this process will be to import the mines, roads, railroad terminals, and counties into a GIS.  Fortunately, all of the data has been compiled (in the previous exercise) and is projected appropriately, so it  will merely be relocated to a central geodatabase for use in this project.  Once all of the base data is in the desired place, the network analysis can begin.


fig 1: the results of the route tool, interesting but not helpful to us today.

     Using Arc, the network analyst toolbar first needs to be initiated before beginning, and I recommend the toolbar be used to easily navigate the tools as opposed to scouring the toolbox for each step of processing.  The first tool that will be run is "new route" analysis to find one potential path that would include all of the mine locations as "stops."  This was mostly done to explore what the tool was useful for, but the result will not be of any use to us as our goal is to find paths from each mine to the nearest rail terminal, not a single route which connects each mine. That route would not be useful for very much.


     In order to determine the optimal routes from mines to rail terminals, the Closest Facility tool will need to be used, this process is described in the data flow model below (fig 1).  This tool uses the location of a set of "facilities" and "incidents" within a network such as a roads feature class.  Once it has determined those locations, the tool can consider additional parameters to the analysis such as whether or not the roads being used have a hierarchy , for example if one would rather drive on a highway than backwater streets.  Once the facilities (terminals), incidents (mines), network (roads) and optionally barriers have been set, the tool can be run.  Upon completion, the tool will provide a "Routes" dataset which is a collection of the fastest paths from each mine to each terminal.




fig 2: the final data flow model for this project.

     Once the routes have been found, the next task of the project is to determine the cost of each mine to the county for road maintenance.  The first step here is to parse out the route data by county, which can be accomplished easily enough by intersecting the routes feature class to a county feature class and then running the statistical summarize tool.  This gives a feature class of each county's routes used by the network analysis.  Then, in the attribute table which contains the data for each county's routes, a new (float) field was created which ran each route summary through an equation that was determined to roughly estimate the cost to each county of each mile of road.   This entire process was completed with the Model Builder tool, and this was the first project on which I worked with the Model builder.  The final model is given as figure 2.

fig 3: the calculation of cost per county

     The equation given was 100*[Miles]*0.022. The coefficients were determined as follows: each mine can expect to make 50 trips in a truck to each terminal (and 50 trips back), and the cost to the county is 2.2 cents per mile.  Therefore, the annual cost to each county in Wisconsin for road maintenance because of these silica mines is described as 2.2(miles), or as expressed in the Arc as described above (fig 3).  With the cost to each county estimated, the final maps for this project could be developed and are provided in the results section below.

Results:

fig 4: the results of the closest facility tool

fig 5: the results of the final analysis with cost per county symbolized.
 

Discussion:

     The results of this analysis may have been skewed by a couple of factors.  First and foremost, because of the scope and goals (educational) for this project a number of assumptions were made.  The number of trips that each truck was sent on to the nearest terminal was 50 per year, which seems extremely low.  Also, many mines have rail lines that pass through them in to which they are connected and therefore they do not need to drive to a terminal, costing the county in some cases millions of dollars.  Finally, it may have been unfair to use a different source and set of methods for Trempealeau County's mines than for other counties', as the TC mines were pulled from a geodatabse where every single mine was listed and addressed in the county which probably artificially raised the costs of this county in the analysis significantly.

     I learned to highly value the model builder in this project.  It helps to keep track of what I'm doing and organize my project to help give a clearer vision of what needs to be accomplished as the analysis continues. I also gained an appreciation for county webservers which provide accurate, high-quality information freely to the public.

Lab 2 ~ The Census

Introduction and Background:
     Every decade, the US government spends a great deal of man-hours and money to collect the Census, which is the most comprehensive survey on the planet.  Information gathered includes age, race, ethnicity, marital status, house ownership and more organized by location; and this data is freely available to the public online.  The goal for this lab is to familiarize myself with retrieving and working with census data in GIS.  We will ultimately create one map of Wisconsin population density by county, and one map of any variable of our choice in the state.

Methods:
     The first step is to download the data desired from American Factfinder2 on the census bureau's website, which in itself is a multi-step process.  For the data I want, WI population by county, I will select out the People, Basic Count/Estimate topic and the Counties, WI geography.  This will narrow down the field of datasets, from which I choose the SF1 2010 data (ACS is the American Community Survey, which is less comprehensive than the Census.)  Finally, the data is ready to download but I must be sure to download the shapefile if I don't already have one to which I will join my data.  This is done by going to the geographies selection menu, and clicking on the "map" tab.
     After unzipping asll of the downloaded files, we are ready to work in the GIS.  First, make sure that the data is joined to the shapefile by joining the two by the GEO#id field, which is the US Census Bureau's unique identifyer for each location.  Then, creating a map is as simple as setting up your symbology and adding the neccesities like a North Arrow, Legend, and Scale Bar.

Results:

GIS II Project ~ Phase 2 Geocoding

Introduction

     If the ultimate goal of this semester-long flirtation with sand mining is to develop and analyze silica sand mining and its effects in the State of Wisconsin, a smart place to begin might be to know where the Silica Sand mines of Wisconsin are located.  To this end, the goal of this project is to geocode the addresses of as many mines as we can in the state for use in future projects.  Having only one goal may sound like small apples, but the time-intensity that can be involved with geocoding makes this exercise no joke.  In order to compile a set of addresses that can be accurately placed in a road network, the class has grouped into pods of four which will ultimately divide up the task of geocoding the data that can be found regarding Wisconsin Sand mines.  Finally, each individual's geocoding results will be compiled and projected in a single geodatabase which will act as the base data for this project as it progresses.

fig 1: Silica sand deposits and mines of 2011 in Wisconsin.

Methodology

     The first task in this project was to explore online data servers that may contain relevant information to the class, described in the previous exercise.  Eventually, the class was given data to download from http://www.wisconsinwatch.org/viz/fracmap/, which provided a list of sand mines in the state as well as their locations, owners, and some other relevant information.  In an ideal world, this table could be run through ArcMap's address locator tool and all of the locations would be output with their approximate real world coordinates attached.  Unfortunately, the table was not conducive to running through the address locator in the first place, and some address fields for mines were missing entirely but had PLSS descriptions or in some cases directions.  So a couple of steps were needed to geocode the mines.

 

fig 2: the original table. note the address field.

fig 3: the updated table, note how the address data is spaced into seperate fields.

 

     The first step was to have the software code as many addresses as possible. However, it would not work immediately because the address field was not stored in such a way as could be read by the address locator tool (fig 2).  In order to fix this, each group member went through their division of roughly 25 mines and separated the address field into a street address, state, and zip code field (fig 3).  Once this information was properly parsed, the table was fed to the address locator tool in ArcMap which generated a list of locations that could be found.  This left the group member with slightly more than half of their mines remaining to be found, on average.
     Having located several mines, the remainder needed to be geocoded by more creative methods.  As so many mines were described by PLSS, the next step was to overlay an aerial basemap of the state with a PLSS dataset in ArcMap and go visually hunt for these mines one by one.  The remaining mines, if they contained any description of location at all, were found by reading the descriptions contained given and looking around the aerials provided through ESRI.  A typical description of this caliber would read "between Knapp and Menominee, along highway xx and between yyy road and the rail line," and with such general descriptions many of these mines were not found.
     At about this point in the process, a google fusion table of this data was discovered and used to inform the geocoding process.  Also, the owner field of the data was used to look up the company websites of those running the silica mines which we were attempting to geocode.  However, the table was incomplete and websites did not provide directions to their mines, so even with collaboration among classmates and the online fusion table many addresses were still not found.
   

Results

     Unfortuntely, the group was not able to geocode all ~125 mines in one swipe, however we were proud to say that we did in fact successfully geocode 75 mines across the state.

Conclusions

     The first and most noticeable conclusion drawn from this exercise is that geocoding can take a lot of time.  Even simply running the tools was a time-consuming task during which I was grateful to have useful tasks that I could complete while the computer worked in the background.  The coder was also somewhat glitchy, as several students had to run the address locator tool multiple times in order to arrive at a useful dataset.
     The feature class developed is incomplete because of an inability to find several mines on the orthophotos which were missing addresses, and while for our purposes this dataset will be adequate I would not accept this work in a professional setting.  The data provided/collected simply needs to be of a higher caliber if detailed analysis is going to be completed on a project such as this.  By the same token, having a messy data set allowed for practice with a number of different methods for locating mines, which could prove useful in the future.
     However, for the purposes of this project it will be adequate to have a

GIS II Project ~ Phase 1

Introduction:

                Hydraulic fracturing, or “Sand Fracking,” is one of many methods by which the energy industry in the United States has been expanding its access to fossil fuels over the past two decades.  The process can be simplified as blasting a rock formation in order to knock loose trapped petroleum or natural gas.  An energy company drills a hole to the rock and then pumps fracturing fluid to the rock through a metal pipe with enough pressure to split the rock along a pressure gradient.  This fluid could be any of a number of materials: gel, foam and detergent could all be included in a mixture.  Along with the fracking fluid is a material called a proppant, which is small grains such as sand or ceramics suspended in a fluid solution.  This is designed to keep the fractures developed by the fluid open, by lodging particles in the small cracks opened up in the rock this material “props” the rock open when the fluid is gone.  If this didn’t happen, the fissures opened by fracking could close under the pressure of the earth!  In Wisconsin, the procurement of this proppant is a rapidly growing industry.  The state happens to be blessed, or cursed, with extremely accessible and pure silica sands which are used as proppant by energy companies performing fracking around the world.

Over the course of this semester, our geography class will step through the process of a land suitability/risk analysis of Wisconsin land for the development of sand mines in order to both expand our technical skills and examine the relationships that this industry has on the local landscape.  Today’s post is the first in this process.

Today’s goal is fairly straightforward: we are going to download geospatial data from various sources and import it into a Geospatial Information System.  This is the preliminary step in in our analysis where we are simply going to prepare data on land cover, railroads, soils, elevation, and cropland.  Once finished, we have all of this information projected into the same coordinate system and compiled in a single geodatabase.

Methods:

                The first task is to download the data that will be used for this project:

                From       Trempealeau County – we will download a land records geodatabase
                                National Atlas – railroads
                                USGS – digital elevation model
                                USDA – cropland data and a drainage index
                                NRCS SSURGO – soil data

                All of this data is in fact free to the public.  Anyone with internet access can use the information that will be used in this task.  Before the data is useable, a few things need to be changed.  The elevation data came in two separate topographic files, which need to be mosaicked together (using the mosaic tool in ArcMap, then mosaic to new raster).  The SSURGO data was downloaded as one database which contained only tables that referenced a half dozen georelational shape files; when importing to my personal geodatabase the shapefile required a component table to work.

 After this was accomplished, a new personal geodatabase was developed to house the data.  The soil feature class was combined into the same table as the drainage index, in order to keep organized and preserve data space and integrity (join tool).  The new soils/drainage information was stored with the data downloaded from Trempealeau County in a feature dataset.  Finally, all of this data was projected into UTM zone 15N, selected because of this exercise’s focus on western Wisconsin which is entirely within this UTM zone.

Results:

                As of yet, most of what has been accomplished is basic data management.  There is not much to see here really, but here are four images of Trempealeau County with their features titled.  They are missing a number of essential map elements, but hopefully they can convey a sense of what is being worked with on a statewide basis. 

     

Lab 1 ~ The PLSS

Introduction and background:
     For the first lab in this course, we undertook to understand legal description of a property, and use that to develop a legal description of the Eau Claire Confluence Project Propopsal, complete with several base maps displaying the project with overlays of different civil divisions for reference.  The goal here is to develop rudimentary digitizing and cartography skills while learning about different aspects of land parcels such as PLSS, Wisconsin's Township-Range system, and civil divisions.
     The City of Eau Claire, the Eau Claire Regional Arts Council, and University of Wisconsin -- Eau Claire have partnered with a number of private interests to finance an $80 Million development at the confluence of the Chippewa and Eau Claire rivers in the Old Downtown of Eau Claire, WI.  The project is to include student housing, an arts center, retail space and possibly more and it is hoped that the influx of funds to the area will revitalize a stagnant downtown.
    

Methods:
     The first step in the process of developing this lab was to digitize the proposed site of the project.
After setting up a geodatabase for the project, we loaded an aerial of the region (using the Bing basemap provided by ESRI) and a polygon feature class of parcel data provided by the city.  Next I created a new polygon feature class in my shiny new database for the porposed site.  I then found the parcels which are a part of the project using the identify tool and turned on snapping so i could begin digitizing.  While I could have simply selected the parcels needed and formed a new feature class from them, that is not the goal of this excersize.  Before long, I had two beautiful polygons where the proposed site stands (fig1).


fig 1 my digitization

     The next task was to develop six base maps with this data: one with a PLSS overlay, one using civil divisions, one using census tracts, one displaying parcel data (which was used in digitization), one showing city zoning, and a final map that pverlays voting districts around the site.  Fortunately for me, the geospatial data has all been provided by the city of Eau Claire, so I only need to develop the maps!  The six basemaps are added to one layout which includes scale bars and north arrows (like a professional, fig 3).  PLSS data does not exist within the city however, and the civil division map of the county would be entirely useless if focused on the confluence project, so these two data frames will act as locator maps to show the location of the project within the broader region (fig 2).



fig 2 My locators

 

fig 3 The Whole Shebang

     Finally, we had to develop legal descriptions of the parcels being mapped.  Using the parcel id's found with the identify tool, I looked up the legal information needed on Eau Claire's Property and Assessment Search.  This was put into a sheet containing a base map for each parcel and the important parcel information to provide a succinct legal description of the info (fig 4).  The result was a single file conatining both the legal description, of the property, the basemaps laid out as above, and of course this blog announcing  describing the processes used to develop these materials.


fig 4  My result