search

Riverscapes / RCAT

Riparian Condition Assessment Tools
http://rcat.riverscapes.xyz/
GNU General Public License v3.0
2 stars 1 forks source link

RCA confinement method issues #20

Open jenna-walsh opened 4 years ago

jenna-walsh commented 4 years ago

The tool currently determines confinement based on a calculated valley bottom width and a user defined width threshold. Widths below the threshold are determined to be confined reaches.

Valley bottom width is calculated for each Thiessen polygon using the following formula: width = ((perim/pi) * area) / (perim*2 / (4 pi)) This is derived from the equations for perimeter and area of a circle.

The polygons used to calculate width are clipped to the buffered valley bottom. This means that the user needs to increase the threshold to account for the 30 m buffer. If we stick with the current confinement method, it might make more sense to either use the unbuffered valley bottom to clip the Thiessen polygons for this calculation OR buffer the user input.

This method is effective at determining confinement in headwaters, but cannot account for confinement in larger rivers, i.e. places where the Salmon and John Day Rivers flow through a gorge. We've talked about integrating the confinement tool into RCAT - not sure what state that tool is in right now.

Thoughts @wally-mac and @mhallerud ?

jenna-walsh commented 4 years ago

Another thing - why does the tool calculate RVD (but not RCA) for confined reaches? It seems logical to determine confinement before RVD so that the RVD outputs are also constrained to unconfined reaches.

mhallerud commented 4 years ago

@jenna-walsh This is just my two cents on the issue, but riparian vegetation departure seems like a more general output that wouldn't just be limited to confined areas. On the other hand, overall riparian condition is intended for comparisons between pre- and post-restoration condition. By flagging reaches as confined in this output, we're indicating to managers that significant changes would not be expected in these reaches because connectivity, riparian potential, etc. are already naturally limited.

mhallerud commented 4 years ago

@wally-mac @jenna-walsh The bankfull channel and confining margins tools have been added into the RCAT toolbox. They are both fully functional in both script and toolbox format, however confining margins is finicky with temp files. I have not incorporated the confinement output into RCA yet and I'm also behind on the documentation, but both tools are fairly straight-forward. Bankfull is essentially just needed as input into confining margins, so it shouldn't impact the standard RCAT outputs except through it's effect on the confinement categories. The confining margins provides the following output fields on the network:

The code determines the left and right confinement by looking at where the confining margins intersect with a buffered stream network. There is another tool within the confinement toolbox that calculates confinement per reach but I'm not sure if this is necessary. I'm not sure if we want to meet next week to look at how to add the confinement outputs into RCA.

mhallerud commented 4 years ago

@wally-mac @jenna-walsh In the confinement tool it's looking like there are two metrics of confinement:

Any thoughts on which metric will be more accurate/useful? At the moment I'm leaning more towards the second since it seems more quantitative overall, but there is the limitation of those widths being biased by short segment lengths.

mhallerud commented 4 years ago

@joewheaton @sshahverdian Do either of you have thoughts on how to calculate confinement for RCAT? Here are our options:

  1. Previously, RCA confinement was estimated by comparing the thiessen polygon "radius" (i.e. area/perimeter) which was highly biased by segment length, then comparing this to an arbitrary threshold set by the user.
  2. Currently, I have RCAT updated to run off the Confining Margins tool from the Confinement Toolbox, which is supposed to find confined areas by identifying where the buffered bankfull channel polygon intersects the valley bottom. However, I have run a few tests of this and I think it needs some additional work because increasing the buffer on the bankfull channel doesn't result in areas being added to the "confined" classes, but changes the spatial distribution of the confined areas. Another issue with the confined classes is that they segment the network wherever the confining margin breaks are, so the segmentation changes by running confining margins.
  3. Alternatively, confining margins calculates "integrated width values", which essentially are the width of the valley bottom and width of the bankfull channel for any given segment. These widths are calculated by taking the thiessen polygon area divided by the thiessen polygon width. Then a ratio between the two is taken, which can be used to set a threshold for defining confinement (for example, confined areas could be defined as those with [ valleyWidth / bankfullWidth < 1.5 ]).
mhallerud commented 4 years ago

@tyler1218hatch Do you mind weighing in on the above also?

tyler1218hatch commented 4 years ago

I'm not too confident on this issue since I haven't worked with RCAT before. I definitely think that option 1 isn't the best. Having a user defined threshold means that the outputs won't be consistent between uses, and limits the tool's userbase to people who already have a good understanding of what's going on. 2 and 3 both seem fine, although 2 seems a bit more accurate. How long do you think it would take to make it work? Would it be worth the effort?

mhallerud commented 4 years ago

@tyler1218hatch At the current moment it would be easier to make option 3 happen because option 2 is not operating accurately and I'm not yet sure where the issue lies. I agree that it may be the most spatially accurate but am wondering if it may be more transparent to go with option 3 because there would be attributes that end users could take a look at later to check the outputs. However, option 3 would still rely on a threshold of some form which is a downside. As far as effort at the moment, any alternative would be worth the effort because we need some measurement of confinement, and as it stands currently none of the three options are functioning in an unbiased manner.

wally-mac commented 4 years ago

Based on Maggie's assessment and budget/time constraints let's pursue option 3. Maggie please feel free to call me if you want/need to discuss this further.

Thank you,

On Tue, Mar 24, 2020 at 8:04 PM Margaret Hallerud notifications@github.com wrote:

@tyler1218hatch https://github.com/tyler1218hatch At the current moment it would be easier to make option 3 happen because option 2 is not operating accurately and I'm not yet sure where the issue lies. I agree that it may be the most spatially accurate but am wondering if it may be more transparent to go with option 3 because there would be attributes that end users could take a look at later to check the outputs. However, option 3 would still rely on a threshold of some form which is a downside. As far as effort at the moment, any alternative would be worth the effort because we need some measurement of confinement, and as it stands currently none of the three options are functioning in an unbiased manner.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Riverscapes/RCAT/issues/20#issuecomment-603598806, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFHZAUSUWDCO3O2BBMXFFO3RJFREVANCNFSM4LDGDO2A .

-- Wally Macfarlane 435.512.1839

mhallerud commented 4 years ago

Confinement is now calculated as follows (see commit #6b67a5b):

jenna-walsh commented 4 years ago

When running the Bankfull Channely tool, if a drainage area raster is provided, is a DEM still necessary? The tool currently requires a DEM input regardless.

wally-mac commented 4 years ago

Good point. I agree, I don’t see why it would be necessary in that situation. Maggie what are your thoughts on this?Maggie what are your thoughts

On Fri, Mar 27, 2020 at 11:16 AM jenna-walsh notifications@github.com wrote:

When running the Bankfull Channely tool, if a drainage area raster is provided, is a DEM still necessary? The tool currently requires a DEM input regardless.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Riverscapes/RCAT/issues/20#issuecomment-605127408, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFHZAUUDYQ2LT34MWRCSGB3RJTNQHANCNFSM4LDGDO2A .

-- Sent from Gmail Mobile Sorry for typos and brevity courtesy of my phone.

mhallerud commented 4 years ago

@jenna-walsh @wally-mac It will not be used for anything but will still be required in the code. I think it may cause some confusion to have it as an "optional" input since the tool would throw an error if neither a DEM or drainage area raster is included.

jenna-walsh commented 4 years ago

In the bankfull tool, the variable create_bankfull_channel is neither a user input nor defined in the script. Which change would make sense? Or should it always be true for the RCAT toolbox?

wally-mac commented 4 years ago

I think it should always be true for the RCAT toolbox. Maggie?

On Mon, Mar 30, 2020 at 5:03 PM jenna-walsh notifications@github.com wrote:

In the bankfull tool, the variable create_bankfull_channel is neither a user input nor defined in the script. Which change would make sense? Or should it always be true for the RCAT toolbox?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Riverscapes/RCAT/issues/20#issuecomment-606296766, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFHZAUSBW3DMKNF6NRQRXL3RKEQMNANCNFSM4LDGDO2A .

-- Wally Macfarlane 435.512.1839

mhallerud commented 4 years ago

@jenna-walsh Sorry about that, I removed it. I was going to just use the fields appended to the network for confinement and include that as an option so that we could skip creating the actual bankfull channel polygon, but realized it made more sense to just use the bankfull channel polygon so that the calculations were consistent with the valley bottom.

jenna-walsh commented 4 years ago

That makes sense, thanks Maggie!

mhallerud commented 4 years ago

The confinement tool is now updated to use thiessen polygons instead of the valley width. Future updates should work off the confinement_dev branch to implement polygons divided by the segmented network in place of the thiessen polygons.

The function divide_polygon_by_segmented_network is very close to running, but there are a few things to look into:

  1. There is a critical error with the spatial join of the polygons to the network on line 218. The spatial join as currently parameterized using the 'SHARE_A_SEGMENT_WITH' match method never finishes running after 15+ hours on 64-bit python. I attempted to change this parameterization to a simple 'INTERSECT' match method, but this creates overlap in polygons between adjacent stream segments. I also attempted with the 'WITHIN_CLEMENTINI' match option but that also ran for 12+ hours on 64-bit python without ever finishing. I'm assuming this has to do with a file size and/or matching complexity of so many components, but am not entirely sure. UPDATE: The spatial join with the 'SHARE_A_SEGMENT_WITH' finished on my test watershed for the bankfull channel after ~18 hours of running. Given this timeline I'm not sure if the improvement is worth the amount of time to run a single watershed, especially since this process needs to happen twice (once for the bankfull channel, once for the valley) in the confinement tool.

  2. Originally, the merges on lines 202-205 was combined into one merge. Coded this way, it crashes, never completes the function (after 12+ hours running), or outputs a shapefile that has only merged edges for about half of the watershed. When split into two merges it works well and it also runs fine when the second merge is excluded. However, the second merge is necessary for the current spatial join match method ('SHARE_A_SEGMENT_WITH') to work. If another spatial join option can be determined, only the first merge will be needed, however I have explored options and the 'SHARE_A_SEGMENT_WITH' or 'WITHIN_CLEMENTINI' seem the most intuitive.

  3. The arcpy.Densify_management function is used at the beginning of the divide_polygons_by_segmented_network function (lines 144-146) which doesn't seem to serve much purpose (see here for function documentation). Given the coarseness of the 24K NHD we typically use, I don't think this function changes anything. Exploring whether this function is necessary and if it is, optimizing the distance parameter, would help speed up the process.

wally-mac commented 3 years ago

@tyler1218hatch and @DylanBaum the Apr 10 comments by Maggie are still relevant and we'll need to address them.

joewheaton commented 3 years ago

@philipbaileynar and @KellyMWhitehead I'm not sure if either of you have seen these threads? Some of it may have some relevance to the refactor of VBET and Confinement you're both working on.