Document and Illustrate the utility of Segment by Roads

joewheaton commented 6 years ago

Can @Albonicomt zoom into a part of the network and make some maps of BRAT capacity outputs (#132) before and after this segmentation by roads (#66) takes place overlaid with the new road symbology (#134)? We should then make a documentation page that shows:

[ ] Nice figure comparing before and after segmentation how BRAT output changes
[ ] Lays out why you might want this and how it relates to comparing apples and apples with Field Data Capture events in Survey 123 where you stop at bridge and look upstream and look downstream and then compare the results.
[ ] Short video illustrating how to use Survey123 at a road crossing to get two BRAT reach data capture events, and how comparing that to unsegmented network would be problematic, but comparing it to segmented network is easy.

Albonicomt commented 6 years ago

Sure @joewheaton, I can give this a shot.

joewheaton commented 6 years ago

Thanks @Albonicomt. Note that #101 for @sshahverdian is much higher priority.

Albonicomt commented 6 years ago

@joewheaton, Here is a comparison figure attempt. Let me know what you think.

Albonicomt commented 6 years ago

Sorry, Here is the link @joewheaton Figure: https://usu.box.com/s/j60lcml4i7bmab4tn0l3bblu91jum309

bangen commented 6 years ago

@joewheaton @wally-mac

I am not a proponent of segmenting by roads. Joe, I understand your reasoning for wanting to implement this (e.g., constraints of road crossings on implementing restoration projects), but from a geoprocessing standpoint it introduces more issues and potential error than it resolves.

Mainly my concern stems from the fact that we use reach buffers to calculate many of our BRAT Table attributes. Splitting by roads significantly increases the number of reaches that are shorter than our analysis buffers. For example in the Truckee, splitting by roads increases the number of network reaches from 26,320 to 32,516. Of those 32,516 reaches, over 6% (2,012) have a length less than 30 m. That may not seem like a big deal. But, let's consider our slope calculation. We use a 30 m radius buffer to pull off the minimum elevation at both the US and DS extent of the reach. As a consequence of splitting by roads, 6% of the reaches in the Truckee could have a slope of 0 if the minimum Z value falls within that overlapping portion of the buffers. This has obvious consequences since errors related to underestimating slope will be propagated to our streampower and capacity estimates. Thoughts?

wally-mac commented 6 years ago

@bangen, you bring up some compelling reasons not to segment by roads that I think out weight the reasons to segment. So my vote would be to NOT segment by roads.

bangen commented 5 years ago

Closing this issue for now. Segmenting by roads is still an option in the BRAT table tool. However, in the lab we won't be segmenting by roads unless it's specifically requested,

joewheaton commented 5 years ago

WHERE is the documentation for this? I only wanted this as an option, but this ticket was to document it.

wally-mac commented 5 years ago

I agree. I think there’s been a misunderstanding. The new code is segmenting by roads. I personally do not know if there is documentation on this.

On Thu, Oct 18, 2018 at 9:03 AM Joe Wheaton notifications@github.com wrote:

Reopened #135 https://github.com/Riverscapes/pyBRAT/issues/135.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Riverscapes/pyBRAT/issues/135#event-1912521192, or mute the thread https://github.com/notifications/unsubscribe-auth/AU-QUnokaZXEe7pQkzVGz1AN50_dWdk4ks5umJglgaJpZM4VuYAM .

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

Riverscapes / pyBRAT

Document and Illustrate the utility of Segment by Roads #135