"conjoint" Catchments - Catchments for an outflow vs catchments for a flow line

[rob-metalinkage]

A single outflow many have multiple upstream contributing catchments. There is thus a choice of modelling the catchment of the outflow, or the catchment for each notional flow path from upstream nodes to the outflow. The latter is required for flood forecasting. It is always possible to aggregate the outflow catchment from the set of inflow catchments. Both approaches have utility and can be modelled in HY_Features. HY_DendriticCatchment is specifically the catchment of a flow path, but the general HY_Catchment covers both cases.

This is complicated by the fact that the area of a flow path catchment is always arbitrary since there is never a perfect ridge separating flows - but the aggregate catchment may be more easily determined. The open questions are therefore: 1) does a catchment that is the total of the catchment area between the set of inflows and the outflows need a special name - and hence a class specialising HY_Catchment with an appropiate definition and constraint? 2) are "conjointCatchment" relationships to adjacent flowpaths necessary - and should these be a flag (a set of links embedded in each catchment instance) or a extensible class (implemented as a lookup table for example)

Discussions/Catchment conundrums.pptx has the examples discussed in the Feb 4 SWG call

[dblodgett-usgs]

The statement that 'the area of a flow path catchment is always arbitrary' isn't correct. While it may not be determined, we have the same situation with the overall catchment area in that while we may not know it, it is a recognized conceptual feature.

Given that, what we are saying is that there might be a catchmentAggregate that does not inherit all the properties of a catchment (does not have 0..1 inflowNode). What if we relax inflowNode to allow 0..* outfalls to be an inflowNode for a catchment? This would mean that the HY_FlowPath concept being the single linear representation of a catchment is no longer quite correct, but I think it's still OK. HY_FlowPath is still the concept of a link between inflowNodes and outflowNodes.

As long as a catchment can only flow to one outflowNode, I think we are ok relaxing the 0..1 on inflowNode.

This may be related in some way to my issue #6, as well as the text in the spec between figure 7 and 11.

[IrinaDornblut]

The Catchment is the topological link between inflow node and outflow node! A Flowpath starting at an inflow node directed towards the outflow node is still the linear representation of the catchment between them; the CatchmentArea representation of the catchment, spreads an aerial “bed sheet” fixed at infinite points around, but at least at one point on the bed frame to identify that this sheet is a bed sheet. -- There are representations covering the entire catchment, but there are also some representations (e.g. Flowpath) which covers only parts of a catchment which is entirely represented by another representation (e.g. CatchmentArea). To discover all representations (i.e. geospatial data products) relevant for the entire catchment, the embedding of sub catchments in an encompassing catchment should to be described.

The current definition of the CatchmentAggregate as a special catchment type allows to aggregate 1..* sub catchments (each may be represented by a single Flowpath) contributing to a single common outflow node (of the encompassing catchment), or vice versa to split an aggregate (e.g. represented by CatchmentArea) into many contributing sub catchments (each identified by an inflow node) irrespective of the behaviour between inflow nodes and the common outlet. This covers multiple inflows to the (encompassing) catchment; there is no need for relaxing cardinality to 0..* inflow nodes for the special CatchmentAggregate subtype. -- However, CatchmentAggregate currently does not support flows crossing an internal watershed divide between neighbouring catchments in an encompassing catchment. A “conjointCatchment” relationship will allow to identify immediately adjacent catchments to make other representations of them discoverable (e.g. Flowpath) by the identified inflow node, irrespective of the internal flow conditions.

[IrinaDornblut]

“Catchment to a line” vs. “Catchment to outflow node” ? What is really meant? --> model desgin

a) The Flowpath representing the catchment between inflow node and outflow node? --> the catchment contributes to the common outlet, the Outfall, and not to the Flowpath. b) A conceptual flowline (“curve described by a of moving particle of water”, IGH0885) “catching" water particles in terms of a common outlet to which all waters flow? --> flowline (not to be confused with the Flowpath representation) will specialize the topological concept of the Outfall. Note: Outfall may have any geometry, and may be joint/disjoint. c) A conceptual flowline built from an infinite number of succeeding reaches (“between two cross-sections”,IGH0987), i.e. between Outfalls, each forming the outflow/inflow node of a contributing/receiving catchment? --> flowline may be defined as an aggregate of reaches, associated with catchment via the cross section located in the catchment network (using the ReferencePoint).

[IrinaDornblut]

Model design - simple association vs. association class - some thoughts

1. Regarding model consistency: I prefer to add to the Catchment class a simple association "conjointCatchment", to not particularly over-emphasize one catchment property, as well as not pre-define with the "master" concept and terminology some specifics which are dealt in complexity and detail by hydrologic models, e.g. surface water, groundwater, flow models. -- There might be more relationships worthwhile to be considered as such, e.g. those to various sections, or storage. – to stay consistent would require a complete model review, probably a re-design. - furthermore, it might be somewhat difficult to communicate to implementers why just only this relationship is designed in this way.
2. Regarding discovery of data products representing a catchment: The principal intention of HYF is to make different data sets and products accessible by reference to exactly the catchment they multiple represent, e.g. the CatchmentArea polygon representing the catchment, and several Flowpath lines representing sub-catchments which are part of the encompassing catchment represented by the overall catchment polygon. – Does an extensible association class which will lead to various implemented interpretations would not unnecessarily complicate the search/discovery for/of data products representing a particular catchment ?

[dblodgett-usgs]

First, we need to try and focus the conversation if at all possible. These comments are diverging or do not follow a clear path. It would be helpful to follow a more assertion -> justification -> conclusion argument style rather than just stating things as fact or presenting ideas without context or summary.

HY_CatchmentAggregate and the conjointCatchment concept.

Regarding HY_CatchmentAggregate, it inherits from HY_Catchment which has a 0..1 inflowNode relationship with HYOutfall. So your statement: "This covers multiple inflows to the (encompassing) catchment; there is no need for relaxing cardinality to 0..* inflow nodes for the special CatchmentAggregate subtype."_ doesn't make sense to me. Maybe I don't understand class inheritance correctly?
Regarding the conjointCatchment, expanding the scope of the catchment model to support such ad-hoc, non dendritic, flow relationships that may be superimposed on an otherwise dendritic network certainly makes sense. Characterizing the nature of these connections would be akin to characterizing the nature of the HY_Outfall as a confluence, coastline, arbitrary point on a reach, etc. That has not been done and I don't think it should be. Given that, what we are suggesting is that there are inflow/outflow nodes that are not HYOutfalls, but rather HY???, which serves as the topological node to connect conjointCatchments?

Catchment to a line vs Catchment to a point.

I'm not really following this comment. What are you trying to get at? Is it, a, b, or c? Is it all of them? My understanding to date is that it could be all of them. What are the IGH####s in reference to? Is there a way to link to these?

Simple Association vs association class.

I don't think a simple association is right because we need to model the network consistently. We need to be able to trace the dendritic network OR trace walk the entire network using the same kind of information.
That said, I agree that this kind of scope increase would probably trigger a model redesign and we need to consider this carefully. The primary use case that I'm familiar with here is anthropogenic transfers of water from one hydrologic catchment to another. The feature in this case is not a hydrographic feature though. I basically disagree with some of the other types of conjointedness (hydrology domain features) that @rob-metalinkage references. Given these issues (requiring significant redesign of the model, primary use case being non-hydrologic, and vague hydrologic boundaries not being a strong enough case for a special model detail), I would argue that we should not have catchment relationships other than at HY_Outfall network nodes.

[IrinaDornblut]

Re: Multiple inflow into catchment aggregate

The general Catchment class (addressed from CatchmentRepresentation such as Flowpath or CatchmentArea) may be an aggregate of 1..* dendritic catchments, or the dendritic catchment which is part of an encompassing catchment aggregate (it’s an implementation choice).

a) Implementing a CatchmentAggregate, 1..* subCatchments contribute to the outflowNode of the encompassingCatchment. Having identified these subCatchments by their inflow node, multiple inflow into the CatchmentAggregate is described by the total of all single inflow nodes of the 1..* subCatchments (whereby the inherited 0..1 inflowNode of the catchment aggregate may be set to ”0”). – In this way, the several Flowpathes each starting at a subCatchment’s inflow node and directed to the common outflow node represent the CatchmentAggregate (irrespective of the flow crossing the internal divide between neighbouring “conjoint” catchments). – The “conjointCatchment” association may be used to indicate the existence of neighbouring potentially interacting subCatchments without the detail of flow models. -

b) Starting at the outflow node of a CatchmentAggregate, multiple inflow may be described by the total of inflow nodes of the 1..* subCatchments coinciding with the single outflow node of an upstreamCatchment. Each subCatchment may be considered as a “conjiont” to its neighbouring catchment. - Flowpathes starting at the outflow node of the catchment aggregate are directed towards a single outflow node of 0..* identified upstreamCatchments, which are conceptually located on the watershed summit line bounding the catchment aggregate (whereby a watershed line composed of infinite summits is not yet part of the current catchment model). -

c) concluding, I intend to define a jointCatchment association to Catchment to cover the aspect of interacting catchments across internal divides.

d) Although I'm not really sure that this was meant by D. Maidment, it might be worth to provide a concept for this. For example, INSPIRE Hydro defines a Watercourse as 1..* outlet of a DrainageBasin. - Outfall is the topo concept serving as inflow/outflow node for a corresponding catchment. I have to think a little bit more about a conceptual flowline which would serve as an Outfall.

[dblodgett-usgs]

OK. This is starting to make more sense. I struggle with the idea that a catchmentAggregate that has multiple inputs to it's subCatchments actually has 0 inputs of it's own. But I guess I can accept that as being a way to model it and that it makes sense. Because of this, there is no flowLine representation for a catchmentAggregate that has 0 inflowNodes associated with it.

On your jointCatchment idea. There is also the case that catchments separated by some distance can have water transfer between them through a pipe or a man-made canal. That is commonly known as an inter basin transfer. I don't think jointCatchment is intended for this type of association, but I think an association called 'transfer' or similar would be useful.

Let start a new issue for the flowline as outfall. I think there is more to discuss there but we should say the conjointCatchment issue is fixed rather than continueing discussion here.

When you have the proposed jointCatchment solution in the model and we check in the html, we can close this issue. If you consider the transfer association to be out of scope because it is non-hydrologic, I am OK leaving that out.

[IrinaDornblut]

OK, so we have to capture not only the internal flow within a “diffuse” catchment,

but the flow between catchments crossing an arbitrary boundary line. This line may be the divide separating adjacent catchments, or the diffuse divide between non-delineated sub catchments within an encompassing catchment, or a fictive line between distant catchments: --> "jointCatchment" association of HY_Catchment (source) to 0..* HY_Catchment (target).

This should cover also the transfer aspect across a fictive boundary between distant catchments, e.g. water withdrawn in catchment A and discharged after treatment to catchment B, or the summit reach of a canal, or a pipeline transferring water from A to B, ...

I will update the model accordingly. - We can close this issue now, I think.

[dblodgett-usgs]

Sounds good. When your model changes are committed, we can close.