Some ideas for changes to Conflict Model

[joewheaton]

Background I would like to see our management model improved. Currently, we use the following lines of evidence:

• Distance to bridges/culverts
• Distance to roads (in valley bottom)
• Distance to railroads (in valley bottom)
• Proximity to developed or agricultural land use

We use the above to calculate a probability of conflict based on notion that the closer you are the higher the potential for conflict (simple transform function between distance and probability). We calculate this independently for each of these, but then just go with max probability (or worse of most conservative).

What we'd like I'd like to see us separate out: What are the potential impacts:

• Flooding
  • Backwater flooding or raised water level (urban/ or roads inundated in valley bottom)
  • Clogging flooding (culverts or crossings in small streams)
  • Dam break - downstream flood risk (big enough pond... maybe we only have that for if we do #15 )
• Undesirable Harvest of Trees
  • Damage from trees falling on infrastructure (proximity of good riparian veg/tall trees (veg ht) in proximity to infrastructure)
  • Harvest of ornamental (trees in back yards; trees in urban parks and recreational areas)
  • Harvest of ag orchards (trees in orchards)
  • Harvest of scientific monitoring equipment (e.g. USGS gages are, pit tag readers)
• Impacting Flow Diversion or Irrigation Works
  • Points of Diversion
  • Canals

What are the tolerances for beaver or mitigation: Could be:

• No tolerance (only good beaver is a dead beaver)
• Can't allow Beaver (e.g. Superfund sites)
• Some potential impacts, but willing to mitigate (start simple first, escalate only if necc.)
• Beaver can do no harm (even if flooding my land)
• Beaver Conservation Zones

To get started:

• Start with Property Ownership or Parcel Map
  • Assume all private property (assume worse... no tolerance)
  • Update as you have input...
  • Attempt to get by agency from specifically finding out....

Discussion Ideas 👍

• Another line of evidence could be - Proximity to higher capacity reaches.
• Also, we should lower probability where capacity is low!!!! Sara points out we should use logic from management model....
• Scott suggests changing from probability of conflict to potential for conflict
• Nick suggested using e_DamCt, eDamDens and eDAMPcC (from attribute table) to say if you already have lots of dams in close proximity, is conflict actually pretty low? Ask if mitigation taking place, or lethal removal, etc.?
• Nick mentioned thinking through how these intermediates and outputs can be used to guide building of an adaptive beaver management plan
• Bring Topology in (talk to @MattReimer) and look at Network Profiler and GNAT

[joewheaton]

@bangen and Scott Shahveridan I know have done a lot on this. Sara tie your commit histories to this issue please and provide update.

[bangen]

@joewheaton @wally-mac I made some edits to Scott's slides. They're attached below.

Scott did an awesome job reworking the management model. IMO, it's a huge improvement over the previous version and should be our starting point moving forward.

From the runs for the 5 basins in the Sierra Nevada I found there are some gaps/missing categories for:

• Instances where existing capacity is greater than potential capacity. For now we're designating those as 'Suitable Conditions: Maintain Habitat'. We came up with the name on the fly, so I'm sure we can come up with a better name
• Instances where reach doesn't fall within any of the current designated categories. Tend to be reaches where land use is moderate (i.e., agriculture between 20-50% and developed between 10-50%). This instance is only seen in very small number of reaches (<0.75% for a few basins I checked). For now we simply categorized these as 'Need Categorical Definition'

A few things to note:

• I made some edits to the slides, but left the 'old category' matrices that Scott put together untouched. I'm pretty sure they reflect the original management model and not the one that Wally and I re-worked a few weeks back
• The code for this version of the management model is not in the BRAT toolbox yet. Since there are currently some gaps and the prospect that we will make changes at the Truckee meeting it seemed premature to throw it into the toolbox.

I attached a kmz below for the Truckee

I was going to tag Scott here, but appears he isn't on Git?

BRAT_mgmt_new_categories.pptx

BRAT_ManagementModel_Truckee_051818_version..zip

[wally-mac]

@bangen Scott is now on Gihub @sshahverdian

[joewheaton]

I'm just now digesting some of @sshahverdian and @bangen work on this for first time. Really, really cool.

[joewheaton]

I am realizing that the changes you made are both to the 'conflict' model, but more focused on the 'management model'. This is a good discussion. @bangen lets break this out into remaining specific enhancement tasks. Its really hard to know what changes you made through what commits to address this one (you can go back and edit your commits to add reference to #16 here)...

[bangen]

Just realized I posted this to the incorrect issue. Should have been to issue #17. I'll copy it there.

[joewheaton]

See also #69

[wally-mac]

@joewheaton, I know you have thought a lot more about the potential conflict side of the BRAT model over the past couple of months. Can you please add your comments here or in a new ticket for our staff meeting next week (Week of July 22)? Thanks

[joewheaton]

Okay folks, the video below is my stab at the next step for changes to the conflict model. Please note that this includes many of the concepts we thrashed out above. Some highlights:

• This includes demotion of 'Conflict' layer from primary output into an Intermediate output under Human Beaver Conflict to not emphasize it so much.
• We ditch probability of conflict all together and recast it as what that layer really is (distance from infrastructure)
• The biggest work item is to create the logic combining oPC_Prob and oPBRC in a useful way. The map I show gets us 90% there, but I've got a bug on canals.
• What's missing is the 'Data Capture' for the tolerance, but we can get there.

Video: https://youtu.be/gpVwMSp59Ys

This is a HIGH PRIORITY as until this is refined, we should not be batching through runs! Lets get going on this.

[banderson1618]

I've made a branch for implementing these changes, with the name "new_conflict_model". I'd like to ask @bangen (and anyone else who ends up working on this) to work on that branch, so that the rapidly changing and probably buggy code that gets pushed doesn't affect the master branch.

[banderson1618]

Given the goals of this, would it make sense to implement the new conflict (or whatever we're calling it) as an optional tool that can be run after everything else? You mentioned putting it in the "Intermediates" category, but that's also misleading, because it's not intermediate to anything. Maybe we have a new category, called "Supplemental Outputs" or something like that, which could contain the conflict stuff?

[banderson1618]

It seems to me that there are some structural questions we should ask about this. What if we generated oPC_Score in the Conversation and Restoration Model (since it uses conflict as an input), and then have the conflict map that @joewheaton produced as an optional step? I'd appreciate thoughts on this, since it's hard to move forward on development without a clear idea of what the end product should look like.

[wally-mac]

@joewheaton, I just watched your video on your new approach to visualizing potential human-beaver conflict and I think it is spot on. Excellent work! @banderson1618, I think you also bring up some excellent follow up questions for Joe. I'd be very interested to hear what Joe thinks of your ideas. Also, I think we need some clearer "marching orders" in order to effectively address this very high priority task. What has been done? What is left to still "iron out? Who should be working on what components ? Let's keep the thoughts on this flowing...

[wally-mac]

@Albonicomt please read through this thread and watch Joe's video and work with @banderson1618 to come up with some solutions. Thanks!

[bangen]

Joe, I like the direction you want to take this. Several tasks are pretty straight-forward, but the more major changes are going to require more in the weeds detail.

Thoughts/Feedback

I agree with @banderson1618 that not all of these layers belong in 'Intermediates'. Distance to crossing/canal/road and land use intensity are intermediates (directly derived from inputs). The other 3 layers (areas of potential undesirable impacts from beaver, proximity of water course to human activities, potential source areas) are all outputs derived from those intermediates should be in the 'Outputs' folder.

Doing away with 'Probability of Conflict' as primary output

Easy enough. I'm more than happy to throw out 'probability' since it's not a 'true' statistical probability (just a transform function).

• In essence all we're doing is re-labeling this as 'Proximity of Water Course to Human Activities'. Might want to change this to 'Proximity of Water Course to Nearest Human Activities'.
• @joewheaton what breaks did you use to come up with the categories?

Areas of Potential Undersirable Impacts from Beaver

Not so straightforward in that we need to fine-tune the logic and thresholds

• @joewheaton what thresholds were you using here? Rather than take a stab in the dark, it would save use some time to get some in the weeds direction from you.
• I don't quite understand how 'Anthroprogenically Limited' equates to 'Negligible Risk'. This could be misleading.

Potential Source Areas for Beaver to Translocate

Here are the living with beaver categories and the conditional logic in the management model:

Living with Beaver (Low Source)

• occasional existing capacity + occasional or lower potential capacity + landuse intensity < 0.5 + conflict potential score between 0.25 and 0.75

Living with Beaver (High Source)

• frequent existing capacity + pervasive potential capacity + conflict potential score between 0.25 and 0.75
• pervasive existing capacity + landuse intensity > 0.5 + conflict potential score between 0.25 and 0.75

Some questions:

• Do we still want to run the old conservation model? @wally-mac I know you had some concerns about this, what are your current thoughts?
• There are some inconsistencies in the living with beaver conditional logic. Some of this had to do with trying to fit all possible outcomes into the management categories. If we're going the route of dropping the older management model (which I'm for) we need to update the living with beaver logic. I think this will be easier outside of the older management model since we can develop consistent logic without having to consider all the additional categories. Thoughts?

Distance from Infrastructure Layers

• IMO, the road crossing layer should have the same categories as the distance to canal and distance to roads layer. @joewheaton is there a reason you gave this layer different categorical breaks?
• Important Question: @joewheaton and @wally-mac We calculate distance to road crossings regardless of whether they are within the valley bottom. This makes sense since we assume crossings have a culvert or bridge that could be dammed/impacted. We calculate distance from adjacent roads only if they are in the valley bottom. Again, makes sense since here we're concerned about potential flooding. What has not made sense to me is why we only look at distance from canals that are within the valley bottom. If we're solely worried about the footprint of dam ponds capturing a canal this makes sense. But if we're worried about beaver impacting canals in other ways (e.g., damming, pulling material across) then we should be looking at ALL canals regardless of whether they are in the valley bottom or not. Thoughts?

[joewheaton]

Sorry for late response here @banderson1618: *** IN PROGRESS

It seems to me that there are some structural questions we should ask about this. What if we generated oPC_Score in the Conversation and Restoration Model (since it uses conflict as an input), and then have the conflict map that @joewheaton produced as an optional step? I'd appreciate thoughts on this, since it's hard to move forward on development without a clear idea of what the end product should look like.

Good point. We are talking about adding some additional attribute fields to a table. I don't know what table (or shapefile) makes the most sense to be honest. I'm fine with this whole 'Human Beaver Conflict' folder getting run in an 'optional' thing, and I like it having its own shapefile. All we need is to preserve a reachID so we can do a spatial join to the other original BRAT table. I think we've gotten a little stumbled up by trying to keep everything in one shapefile and its attribute table. So my suggestions here are: Make a new shapefile called AnthroConstraints.shp in the following path:

1. MyBratProject\Intermediates\AnthroConstraints\AC001\ where AC0001 is an autopopulated index for what realization of this is being run.
2. Build this shapefile with a new attribute field being defined for every one of the outupts I showed in video above, and don't forget to populate those as you go in documentation (see #129)
3. Get rid of oPC_Score all together and replace with a oAC for output Anthropogenic Constraints, which will be categorical and the 'primary' output of this AnthroConstraints.shp shapefile. Its categories should be: