RCA confinement method issues

[jenna-walsh]

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]

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]

@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]

@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:

• Con_LEFT: A binary field set to 1 if the reach is confined on the left and 0 otherwise.
• Con_RIGHT: A binary field set to 1 if the reach is confined on the right and 0 otherwise
• Con_Type: Confinement type with categories "NONE", "LEFT", "RIGHT", and "BOTH" depending on the values of Con_LEFT and Con_RIGHT
• IsConfined: 1 if any confinement present (left, right, or both in Conv_Type) and 0 if no confinement (none in Conv_Type)
• IsConstric: 1 if considered constricted ("BOTH" in Conv_Type) and 0 otherwise

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]

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

• The first is based on the confining margins, i.e. where the buffered bankfull channel polygon intersects the valley bottom. This is how the attributes in the current output network are defined. As far as I can tell, the extent of the confinement on a reach is not considered.
• The second is what's labeled as "integrated width", which essentially calculates the "width" of the valley bottom and bankfull channel by dividing the thiessen polygon areas by segment lengths, then calculated the ratio of "channel width" / "valley bottom width".

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]

@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]

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

[tyler1218hatch]

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]

@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]

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 ***@***.***> 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 <#20 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFHZAUSUWDCO3O2BBMXFFO3RJFREVANCNFSM4LDGDO2A> .

-- Wally Macfarlane 435.512.1839

[mhallerud]

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

• Thiessen polygons are formed at network segment midpoints
• The thiessen polygons are clipped to the bankfull channel polygon and to the valley bottom polygon.
• The area of each clipped thiessen polygon is calculated and joined to the corresponding network segment, with BFC_Area as the bankfull channel area and VAL_Area as the valley bottom area for the given segment.
• For each reach, mean bankfull width BFC_Width and mean valley bottom width VAL_Width are calculated for each reach by taking the thiessen polygon area and dividing by the reach length.
• The confinement ratio CONF_RATIO is calculated as BFC_Width / VAL_Width
• In RCA, a confinement ratio threshold is then set to categorize "confined" and "unconfined" areas, with reaches with a CONF_RATIO value higher than this threshold being classified as confined. I set the default value for this threshold at 0.50 (i.e., reaches with a valley bottom less than or equal to twice the width of the bankfull channel will be classified as confined), but we can discuss this further if needed.

[jenna-walsh]

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]

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 ***@***.***> 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 <#20 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFHZAUUDYQ2LT34MWRCSGB3RJTNQHANCNFSM4LDGDO2A> .

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

[mhallerud]

@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]

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]

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

…

On Mon, Mar 30, 2020 at 5:03 PM jenna-walsh ***@***.***> 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 <#20 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFHZAUSBW3DMKNF6NRQRXL3RKEQMNANCNFSM4LDGDO2A> .

-- Wally Macfarlane 435.512.1839

[mhallerud]

@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]

That makes sense, thanks Maggie!

[mhallerud]

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]

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

[joewheaton]

@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.