dblodgett-usgs
commented
10 months ago This is a snippet of an email to the HY_Features SWG email
[snip]
I’m starting to document some work we’ve been doing in the USGS [1], [2] as a logical model based on HY_Features – it will be in an engineering report for the SWG when ready. hydrofabric.png attached shows the core logical model and a heavily simplified ArcGIS class diagram of the data model we’ve settled on. I wonder if you could help with how you see HY_Features working in a specific case I’ve been struggling with.
We have a lot of linear waterbody representations that form a network and are critical to overall hydrologic connectivity but do not have any local drainage. These are things like levied rivers, underground conduits, and gravity driven concrete canals that flow along an elevation contour. We need to have linear referencing along these features, so need to think of them as part of a HY_Flowpath [3] [4], but do not want to have 0-area catchments for them. This diagram illustrates how we are thinking about mainstem in this context.
At one scale, these features are part of a flowpath (catchment realization) – e.g. a main flowpath (mainstem) of a drainage basin (catchment aggregate with no inflow) – parts of it can be features that do not have a local catchment. At a local scale, these features are not part of a flowpath (catchment realizations), they are just linear waterbodies with no local drainage area.
I’ve attached an attempt to model this out and figure out how to deal with it and I’m kinda stuck.
It seems OK to say that a mainstem (HY_Flowpath of a drainage basin) is a composition of flowlines and a flowpath (HY_Flowpath for a local-catchment) is an aggregation of flowlines. In other words, in this model, we want all flowlines to be part of a “mainstem” but to not recognize all flowlines as being part of the flowpath of a local-catchment.
This inset of the attached diagram (hdrofabric-hy_features.png) is what I’m talking about:
Note that both mainstem and flowpath are specializations of HY_Flowpath. Also note that mainstem is a composition of flowlines and flowpath is an aggregation of flowlines. That is, a flowline must be a member of a mainstem but a flowline does not have to be a member of a flowpath.
This feels a little off to me though. The issue is that this arrangement is saying that there are some mainstems (composed entirely of flowlines that are not part of a HY_flowpath) with a 0-area drainage basin. But at the same time saying that a flowline with no contributing catchment is not a HY_Flowpath.
I feel like we could also model this with a modification to HY_Features where we say that HY_Flowpath is both a subclass of HY_CatchmentRealization AND a subclass of HY_WaterBody and that the linear element for HY_Hydrolocation is actually a linear waterbody. But that has broader ramifications and feels heavy handed.
[snip]
[1] https://www.youtube.com/watch?v=VJRteEepH2c [2] https://www.usgs.gov/ngp-standards-and-specifications/3d-hydrography-program-product-specification [3] https://docs.ogc.org/is/14-111r6/14-111r6.html#_the_river_referencing_model [4] https://doi.org/10.1016/j.envsoft.2020.104927
Per https://docs.ogc.org/per/22-040.html#_flowline_feature_and_linear_referencing, there needs to be a way to have indirect position on a flowing waterbody that is not thought to be the flowpath of a catchment.
Two solutions have been suggested here.
1) Create a "flowline" class that "flowpath" can inherit from. In this case, flowline would NOT be a catchment realization but would relate to a waterbody. Flowpath would then inherit the linearElement association to hydrolocation from flowline. A flowline in this case would have to take part in a network of waterbodies such that there is a known upstream and downstream end. 2) Create a "flowline" class that is in parallel to "flowpath" and would be a linear representation of a waterbody. In this case, the linearElement association would be to one or the other of these linear waterbody representations. A flowline would have to take part in a network of waterbodies such that there is a known upstream and downstream end.
Option 1 is useful because it allows a given dataset to treat some flowlines as "plumbing" or just hydrodynamic features that don't have to obey the catchment data model.
Option 2 is useful because it has a stronger separation of concerns and would avoid confusion of the catchment and waterbody data models.