GEOG 566

         Advanced spatial statistics and GIScience

April 29, 2018

Mapping Beaver Dam Habitat and Geometry through OD Cost Analysis

Filed under: Exercise/Tutorial 1 2018 @ 6:08 pm


Question 1: How well do habitat models predict suitable beaver dam locations?

This analysis was initially driven by the question of how well models of suitable habitat for beaver dams could predict stream reaches where observed beaver dam locations were identified during a pilot field season in the West Fork Cow Creek of the South Umpqua River (see Map: Umpqua Basin  below) in southern Oregon in fall of 2017. This question focused initially on implementing a Habitat Suitability Index (HSI) described by Suzuki and McComb (1998).  The findings from this query are noted below and ultimately led to a second question for this analysis.

Map: Umpqua and WFCC basins

Click to enlarge


Question 2: Is there a difference in the geometry of suitable dam habitats with and without observed  beaver dams?

After applying the Suzuki and McComb HSI to the stream network it appeared that observed beaver dams occurred more frequently on those sections of streams where habitat ‘patches’ – that is, contiguous segments of the stream classified as suitable for damming – were larger and/or separated from other patches by smaller breaks of unsuitable habitat.  These obervations are consistent with theory from landscape ecology that suggest habitat ‘geometry’ (see Figure 1) such as size and relationship to other habitats can be an important factor in selection of habitat by animals (Dunning et al, 1992).  To approach this question I focused on generating two metrics of habitat geometry: 1) patch size, and 2) distance to next patch.

Figure 1.

Figure from Dunning et al. 1992 showing how habitats A and B, while both too small to support a population, may be occupied (A) if in close proximity to other habitats


Click to enlarge

Seemingly simple, these tasks ultimately proved more time intensive than I first anticipated so my contribution for this first exercise focuses less on results than on describing the geoprocesing procedures and workflow used derive this information.  The hope is that others may be able to repeat the processes for similar questions related to stream habitat without running into as many dead end efforts as it took me.

Data and Tools Used:

For this exercise, I used data from Netmap, a modeled stream layer representing the stream network with polylines at approximately 100m segments across more than two dozen attributes.  More information can be found here.

Select by Attribute query to identify suitable habitat.

The first task was to identify all segments in the stream network that fit the HSI criteria: stream gradient ≤ 3%, active channel width > 3m but < 6m, and valley floor width ≥ 25m.   To accomplish this, I used a Select by Attribute query, which can be found in the Attribute Table “Options” dropdown.  The procedure is relatively simple but requires that you use SQL (Structured Query Language) syntax to define the variable(s) and respective parameters for the attributes that you wanted selected.

Analyzing Patch Length with Buffer and Dissolve tools

To combine contiguous segments of the stream suitable for damming into single/unique habitat patches I used a combination of tools found the in the ArcMap Toolbox. The primary tool was Dissolve, which can combine a layer’s features, in this case the stream segments defined as habitat, along with the attribute information for each feature.  After several iterations, I found that using the Buffer function to ensure overlap among contiguous habitat segments in the stream network prior to dissolving was helpful.

Analyzing Distance to the next Habitat Patch with OD Cost Matrix

I initially tried several approaches to measure the minimum distance to the next patch for every patch in the stream network. The first approach I used was the nndist function in the R spatstats package that calculates the distance from one point to the nearest neighboring point. A similar tool exists in ArcMap, Near, and was appealing so that I could maintain workflow in the same program if possible.  Ultimately, I landed on OD Cost Matrix, a traffic planning tool in ArcMap that looks at distance between points using a specified network of travel corridors (aka streets).   This seemed best suited to my needs of looking at travel distances between patches when considering realistic pathways of movement for beavers along the stream network.

Steps to complete the analysis:

Identify Suitable Habitat with Select by Attribute.

These steps were relatively straight-forward. I opened ‘Select by Attribute’ window from the options dropdown menu in my attribute table of the stream network layer and used the following syntax to select all stream segments that met the HSI criteria: “WIDTH_M” >=3 AND “WIDTH_M” <=6 AND “GRADIENT” <= .03 AND “VAL_WIDTH” >= 25.  After running this query, all of the segments matching these criteria are highlighted on the stream network layer.  From there I exported the selected items into a new layer Suitable_habitat by right clicking the stream layer in Table of contents, select export data, and chose to export ‘selected features ‘from dropdown, being sure to click what geo-referencing system I wanted to use. I usually choose to reference based on the existing data frame when exporting data since I specified that when first opening the map and its an easy way to keep all exported layers consistent.

Dissolve Contiguous Stream Habitat Segments into Single Patches

I defined a “habitat patch” as any contiguous length of suitable habitat segments in the stream network. My goal was to take these individual contiguous segments and convert them into single polylines of “patches’ through the dissolve function that would ultimately provide a measure of the total patch length.

Step 1: Buffer all suitable habitat segments.

Before dissolving I created a 20m buffer on my habitat segments so that I could ensure that contiguous sections were overlapping eachother.  To do this, I opened the Buffer tool, selected the Suitable_habitat layer and specified 20 meter buffers.  This generated a new layer of the buffered habitat segments I labeled Suitable_habitat_20mbuff.

Step 2: Dissolve Buffered layer into unique patches.

I then opened the Dissolve tool, selected the buffered layer.  For the second part of this function I needed to choose which attributes to keep from each habitat segment (e.g. length, gradient, width, valley width, etc.) and how I wanted it combined with the other segments as attributes of the patch layer that I was generating.  To do this I went to the Statistics drop down in the Dissolve window and added each attribute along with the relevant calculation. For example, I specified that Length (LENGTH_M) be the sum (SUM) of all the segments for that patch, for GRADIENT I choose to carry over the mean of each segment (MEAN) and so on.   Finally, I unchecked the “Feature with multiple parts” box and checked “Unsplit line” box. By doing so I told ArcMap that I do not want all of these segments to be to turned into one feature (meaning one row of attributes in the attribute table) and instead turn any overlapping line vertices (the ends of my stream segments) into a single feature or ‘unsplit” line.  I then ran the function and labeled the layer output as Habitat_patch.

*Note, that I’ve had to repeat the Dissolve more than once and found the Results window in ArcMap highly useful. (Main Toolbar > Customize > Results).  By using it I can re-navigate to the Dissolve tool table with all the Statistic/attribute selections already populated.

Calculating Distance between Patches Using OD Cost Matrix

The OD Cost Matrix is a tool developed for transportation planning that can calculate the distance (referred to in Arc as Cost) from starting points (Origins), to ending points, (Destinations), using a specified network of travel corridors (Network Dataset) such as streets, highways, etc.  When completed, the analysis generates a dataset with distance from every specified origin to every specified destination along the network paths and can become quite large depending on the number of origins/destinations that you specify.

Step 1: Turn on relevant tools:

The first step I needed to do was turn on the Network Analyst extension found on the Main Toolbar > Customize > Extensions and click the Network Analyst to add a check next to it.  Then I needed open the Network Analyst toolbar.  Main Menu Toolbar > Customize > Toolbars, click on Network Analyst.

Step 2: Create Network Dataset

In the Arc Catalogue, I navigated to the network I wanted to use as travel paths (the stream network layer), right clicked and selected New Network Dataset.  From there, Arc moved me through a series of windows.  The most important of which are to specify ‘any point’ under the connectivity policy.  The default ‘end point’ leaves a number of Origin points out of the analysis for some reason.  The other important window/step was adding the metric I wanted to use for the ‘cost’ analysis.  In my case this was the LENGTH_M variable, which is the length in meters of each stream segment in the network.  Note, that the name needed to match the variable name in the dataset exactly.

Step 3: Convert Dissolved Patch Habitats into Point Data.

Because OD Cost Matrix relies on starting points and ending points I needed to convert the polylines representing my patches into points.  To do this I used the tool Feature Vertices to Point. The tool itself is fairly straight-forward but requires a tradeoff decision on whether to convert the patches to a single “MID” for the mid-point of the patch or “DANGLE” for a point at each end of the patch. The Mid Point selection offers a simpler output from the OD Cost Analysis, and the “Dangle” offered a more precise measure of nearest distance, but cumbersome output because it had twice the data points to and from which distances needed to be calculated (more on that below). In the end I did both and used the mid-points as barriers (see next step).

Step 4: Load Data in OD Cost Matrix

In the Network Analyst toolbar I selected “OD Cost Matrix” from the dropdown menu, then, clicked the icon with a small flag overlaid on a grid.  This last step opens a new window adjacent to the table of contents. In that new window I right click the bolded “Origins” and selected “Load data” and selected the patch points I created in Step 3.  Then I repeat the process for “Destinations”.  Then for “Point Barriers” I loaded my mid-point patch layer.  It took me a few times to realize this, but the barriers data prevents the analysis from computing numerous unnecessary distances.

Step 5: Solve OD Cost Matrix

Once all the data is loaded I clicked the solve icon on the Network Analyst toolbar that looks like a chart with a upward line curve overlaid on it.

Step 6: Export Distances from OD Cost Matrix into New Layer.

Once OD Cost Matrix completes the analysis the Table of Contents is populated with a number of outputs including a layer called “Lines”.  This layer shows straight lines from every Origin to every Destination.  At first this was a little confusing because the lines suggest that these are Euclidian distances, but once opening the attribute table I was able to verify that they are in fact distances via the stream network.  I exported this as a new layer as patch_distances.

Step 7: Create Summary Table for Distances and Join to Dissolved Patch Layer

The last step I made was to add the new distance information to my layer of dissolved habitat patches and then add that information to the Habitat_patch layer.  To do this I opened the attribute table for the patch_distances and right clicked on one of the column headers and selected “Summarize”.  This opens a window with a drop down for what column to create summary data and with a number of options lower in the window for what information to summarize.  Here I used the patch orgin and destination ID and summarized by minimum, maximum, sum and average distances.  This then generates a new table summarizing each of those metrics by the Origin/Destination ID. I saved this table as Patch_Dist_Summary.  Then, I used the Join tool to add the summary information to the Habitat_patch layer.  Note doing this required that the table have an identifier for each distance that relates to the corresponding patch feature in the Habitat_patch layer so that it can associate (or add) the distance metrics appropriately.


Identifying Suitable Dam Habitat

Map 1 shows the results of the habitat selection based on the Suzuki and McComb (1998) HSI criteria and includes 15.8 km of stream length (2.3% of the total stream network).  Also shown are the dam sites that were observed during our pilot field season in 2017. Dam sites occurred across 21 stream segments for a total 2.2km of stream length, all of which fall within the bounds of the HSI criteria. However, as a predictive tool the HSI selection criteria also identified a larger number of stream segments that were observed as unoccupied in our site surveys, meaning that the model tends to ‘over predict habitat’ based on our observed dam sites.  One aspect that stood out, however was that the dams sites tended to occur on segments of suitable habitat that were contiguous to other suitable stream segments and/or separated only by small distances of unsuitable stream segments.

Map 1

Click to enlarge

Patch Length:

Map 2 shows all habitat patches, color coded by length with observed dam sites occurring among the longest patches.  These preliminary findings support the hypothesis that patch geometry may be a relevant factor in the beavers habitat selection for dam building.   It should also be noted, however that there are a few patches that were not surveyed so it is possible that unobserved dams exist in those locations.

Map 2

Click to enlarge

Patch Distances:

Map 3 shows the stream network distances generated from the OD Cost Matrix with lines showing the origin/destination points for all route distances calculated.  (NOTE: while the lines are straight, the distance calculations relate the ‘path distance’ or distance if traveling through the stream network) Here green lines indicate shorter distances and red lines indicating longer distances. Map 4 applies similar color codes to the patches themselves with red indicated a patches relative isolation and green indicting high connectivity to the nearest patch.

Map 3


Click to enlarge

Map 4

Click to enlarge

Distance weighted Length

Lastly, I wanted to consider both length and distance to nearest patch together and so created a final metric with Patch Length/Distance to nearest Patch.  The results are show in Map 5.  Overall there is not a large change either of these

Map 5

Click to enlarge

Critiques Critique of Habitat selection

I do not have a lot of input on this.  It’s a very useful procedure to quickly select out features of a dataset based on a fairly simple process.  The challenge, or course, is that SQL is a language and like any other can be fussy when first learning it’s syntax.

Critique of Habitat patching process

Overall, the dissolve process accomplished most of what I needed but with some notable caveats.  The most significant limitation is that the ‘unsplit lines’ function I used to combine stream layers only works where two line vertices overlaps.  In a handful of instances there were locations in the patches where three vertices came together at the confluence of a higher and lower order stream.  These cases are ignored by unsplit line function and remain ‘undissolved’. I found a work around by later adding a Patch ID to the attribute table by hand for these three segments and then dissolving by that common ID.  However, I’m not excited about applying the same work around where the number of suitable stream segments will increases from 158 in West Fork Cow Creek to over 11, 474 when I expand this procedure the rest of the Umpqua Basin (See Map 6 of suitable habitat segments in the greater Umpqua).

Critique of Distance Estimates

My initial efforts to identify patch distances began with the nndist function in spatstats package of R and the Near tools in ArcMap.  The main limitation for these is that they calculate the Euclidean distance (i.e. straight lines) between points and are not particularly realistic based on what we know about beaver movement in a watershed and their fidelity to streams for protection from predators (i.e. they tend not to waddle up ridges and into the next drainage).  Instead I needed a tool that would calculate the distance it would take a beaver to move from one patch to the next using the stream network as it’s travel corridor.

For my purposes the OD Cost Matrix seems very promising.  The greatest challenge I had with this procedure was relating the distance output layer back to the original patch layer. When deriving a new dataset from analysis of an existing one, Arc carries the original feature ID information forward but re-labels as “OriginID”  In my case, that means the Patch ID were carried forward in the conversion to point data, but when the point data was used in the OD Cost Matrix, and then subsequently Summarized, those Patch IDs were long gone.  As a result, I had to trace back the geneology and create a new Patch ID column in the summary table so that I could Join it with the original patch layer. Again, this is doable in a sub-basin context but when I apply this procedure to the entire Umpqua (Map 6) I’ll have to find a better solution.

Map 6:

Click to enlarge


Dunning, J. B., Danielson, B. J., & Pulliam, H. R. (1992). Ecological Processes That Affect Populations in Complex Landscapes. Oikos, 65(1), 169–175.

Suzuki, N., & McComb, W. C. (1998). Habitat classification models for beaver (Castor canadensis) in the streams of the central Oregon Coast Range. Retrieved from


Print Friendly, PDF & Email

No Comments

No comments yet.

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

© 2019 GEOG 566   Powered by WordPress MU    Hosted by