Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New logic for `oPBRC_UI` (Areas beavers can build dams, but could be undesirable impacts) #207

Closed
joewheaton opened this issue Oct 18, 2018 · 12 comments

Comments

@joewheaton
Copy link
Contributor

commented Oct 18, 2018

@banderson1618, after we manually implement some changes to oPBRC_UI in Conservation_Restoration.py, I want to strip apart the oPBRC_UI, oPBRC_UD, and oPBRC_CR into three seperate commands, which each populate their own tables and shapefiles, such that multiple versions of each can exist, each with its own dependencies. Lets wait to do this until we've manually played with (#206), got some feedback from the workshop participants and clients, and can confirm.

Dependencies & Order of Operations

So all three of the new components of Conservation_Restoration module require both the BRAT capacity runs (historic and current)

oPBRC_UD (Areas beavers can't build dams and why)

Related to #161

oPBRC_UI (Areas beavers can build dams, but could be undesirable impacts)

Related to #151.

oPBRC_CR (Conservation & Restoration with Beaver Opportunities)

Related to #175
[ ] Run new ConservationRestoration.py which fixes the logic for the

  • Manually update and populate the logic we defined in comments of lines 54-61 of Conservation_Restoration.py
  • Manually update and populate the oPBRC_CR such that anything that is currently a 'Easiest - Low-Hanging Fruit', 'Straight Forward - Quick Return', or 'Strategic - Long-Term Investment' is converted to a 'NA' if 'oPBRC_UI' Negligible or Minor (note @MatthewMeier that line 94 is already checking for this, so it might work correctly). We need to basically make sure that 'NA' is used everywhere that oPBRC_UI = 'Considerable Risk' or oPBRC_UI = 'Some Risk'

New Logic

oPBRC_UI (Areas beavers can build dams, but could be undesirable impacts)

Related to #151.

This is just the SQL syntax if doing this in Select by Attributes manually (needs refactoring to Py) to use as pseudo code:

            #row[0] = 'Considerable Risk'
            ("oPC_Dist" < 30 OR "iPC_LU" > 0.6) AND ("oCC_EX" >= 15)
            #row[0] = 'Some Risk'
            ("oPC_Dist" < 100 OR "iPC_LU" > 0.6) AND ("oCC_EX" >= 5 AND "oCC_EX" < 15) 
            #row[0] = 'Minior Risk'
            "(oPC_Dist" < 300 OR "iPC_LU" > 0.3) AND ("oCC_EX" > 0 AND "oCC_EX" < 5) 
            #row[0] = 'Negligible Risk' - What's left...

However, what we really need to do is make a separate, optional tool in the pyBRAT toolbox for running the 'Beaver Dam Risk Assessment, which populates the 'oPBRC_UI', which prompts the users for the following inputs:

  • Input 'Distance to Closest Infrastructure' (oPC_Dist) - allowing user to have different 'realizations' of oPBRC_UI (stored in different tables/shapefiles) based off different realizations of road inputs, railroad inputs, canals and then oPC_Dist). - I'm not sure where and when this gets run now, but we need to make sure that allows multiple realizations!
  • Name of realization (default is autoname oPBRC_UI_00n) where n just auto indexes 1, 2, 3... n)
  • Notes or Custom Description:

The user should not have any say in where the thresholds are in the logic above as they represent the categorical breaks in the symbology.

I would like this to be output into its own shapefile (right now its just in regular BRAT table output... I don't want this: e.g. 17050202_BRAT_CR_P_beta.shp), which has its own table. Let's put this in its own shapefile we call BRAT_UI.shp and let all the place specific and realization version be taken care of in project file and by folder structure. The table should only brings in the fields relevant to this calculation:

  • Intermediates (copies of the things that oPC_Dist was based on)
    • iPC_Rail
    • iPC_RailVB
    • iPC_Canal
    • iPC_RoadX
    • iPC_Road
    • iPC_RoadVB
  • Inputs (passed from which ever realization as appropriate and noted in the project XML) required:
    • oPC_Dist
    • iPC_LU
    • ioCC_EX
  • Output
    • oPBRC_UI

@joewheaton joewheaton added this to the BRAT 3.2 milestone Oct 18, 2018

@joewheaton joewheaton added this to Not Scoped in pyBRAT Development via automation Oct 18, 2018

@MatthewMeier

This comment has been minimized.

Copy link
Contributor

commented Oct 18, 2018

@joewheaton @wally-mac
I was able to get the NFB roads clip layer package up and here it is on box for you to look at. The NF Burnt original roads layer is found here. I believe that with the symbology now figured out and some layer package issues that each one will probably take about 30-40 minutes. @Albonicomt this is the newest layer package but wait on the management outputs until we get some feedback. Joe if you could get back to us on this as soon as you can that would be helpful.

banderson1618 added a commit that referenced this issue Oct 23, 2018
banderson1618 added a commit that referenced this issue Oct 23, 2018
@joewheaton

This comment has been minimized.

Copy link
Contributor Author

commented Oct 28, 2018

Okay. This worked out really well for the John Day and Burnt out in Oregon. Now that @MatthewMeier ran through it manually, @banderson1618 it is a high priority to get this updated in pyBRAT 3.X before we run it elsewhere.

Here's an example of the output.
nf_burnt_river_brat_dam_conflict

@banderson1618, please have a look at the 'New Logic' above and post any specific questions you have. Otherwise, please scope and @wally-mac and I will work on prioritizing this relative to your other commitments.

@MatthewMeier

This comment has been minimized.

Copy link
Contributor

commented Oct 29, 2018

@joewheaton
@banderson1618 and I have implemented the code needed for this output and it is uploaded to the pyBRAT_master branch there are some minor edits that could happen. Such as the user control knob if you would like them to choose whether to eliminate the considerable and some risk segments in the "Restoration or Conservation Opportunities" output. I am sure this will be covered under a separate issue but I will upload the layer file to the master branch as a proposed push.

@banderson1618

This comment has been minimized.

Copy link
Collaborator

commented Oct 30, 2018

@joewheaton, as the tool is currently designed, the field oPBRC_UI is made and calculated in Conservation_Restoration.py (Matt and I implemented the commented code in commit 9652d6a). If I understand you correctly, you would like us to take that code, as well as the code that finds oPBRC_UD and oPBRC_CR and split them into three tools, each of which calculating one field. Is that an accurate summary?

@banderson1618

This comment has been minimized.

Copy link
Collaborator

commented Nov 5, 2018

@joewheaton, it'd be good to get your feedback on my summary, so that I can get started implementing it.

@wally-mac

This comment has been minimized.

Copy link
Collaborator

commented Dec 17, 2018

@banderson1618 and @joewheaton where are we on this front? Please advise.

@banderson1618

This comment has been minimized.

Copy link
Collaborator

commented Dec 17, 2018

@MatthewMeier and I have modified Step 6: BRAT Conservation and Restoration to create the three fields outlined in @joewheaton's post. However, we haven't implemented an optional tool that creates those field based on the user defined thresholds.

@wally-mac

This comment has been minimized.

Copy link
Collaborator

commented Dec 17, 2018

Thanks for the update. What it the "hold-up" on the generation of an optional tool that creates those field based on the user defined thresholds? Please advise and thank you.

@banderson1618

This comment has been minimized.

Copy link
Collaborator

commented Dec 17, 2018

When I last read this, I had a fuzzy idea about how this should be implemented, and was waiting for clarification from Joe about how to proceed. At this point, it might be better to slap something together on a separate branch and see if it's what he's looking for.

@wally-mac

This comment has been minimized.

Copy link
Collaborator

commented Dec 17, 2018

That sounds like a good plan to me. Please give it a go and thanks!

@wally-mac

This comment has been minimized.

Copy link
Collaborator

commented Jan 17, 2019

@banderson1618 per our conversation regarding "pulling back the curtain" on the conservation and restoration outputs it might be useful to re-read this post.

@banderson1618

This comment has been minimized.

Copy link
Collaborator

commented Jan 17, 2019

@wally-mac wally-mac closed this Jul 8, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
4 participants
You can’t perform that action at this time.