joewheaton
commented
4 years ago Right... tools like BRAT, WRAT, and RS-Context it is value to segment the NHD drainage network beyond its default segmentation by tributary junctions, confluences and diffluences. Yes, it does make sense to provide default segmentation. I would say the most common and useful are:
- 250 m
- 300 m
- 500 m
- None
Those could be just four different geometries that get auto produced. Three additional variants for further segmentation that would be helpful would be:
- Default (no additional segmentation)
- Road & Railroad Crossings (i.e. culverts and bridges) + Deafult
- Jurisdictional (Ownership) boundaries + Crossings
- Parcel boundaries + Jurisdictional
This would create 16 variant geometries. I wouldn't clutter the Riverscapes Context projects with all of these. I would just include 3 in that: - None, 300 m, & 300 m + Ownership (which includes crossings). Those three cover 95% of our use cases and needs. I would just have the methods available where these become the parameters for running a Riverscapes Context project. If it made sense, you could put all 16 in a national project, but that might be overkill. Thoughts?
The Riverscapes context project currently contains the original NHD network flow lines. Tools that use these lines perform their own segmentation on these flow lines:
There are two problems with this approach; i) Each tool that segments the flow lines is slowed down by this step, and ii) the tools are not using the same segmented network which could lead to inconsistency. (We never intend to rely on the segmented reach IDs, but it would be helpful for development if these IDs were somewhat consistent across tools.)
We know that down the road we will be implementing more sophisticated segmentation strategies than the simple distance based segmentation we are using today. For example the old GNAT approach, or some other topographic, transportation or land ownership derived segmentation.
But for now, we are wondering if it makes sense to perform the distance based segmentation in riverscapes context where all subsequent tools can use the same segmented layer. We could perform a series of segmentations (e.g. 300m, 400m, 500m, 1000m) and store all these layers in a single geopackage (a bit like we do with VBET outputs).
Note that the strategy being proposed here is analogous to the way that RCAT used to work. The old segmentation tool was part of RCAT not buried in BRAT. The only reason it got moved into BRAT is merely the sequence in which we have tackled the tools.
Thoughts @joewheaton, @MattReimer, @KellyMWhitehead?