Hydrologic Modeling and River Corridor Applications of HY_Features Concepts

As shown in Figure 1, a hydrologic modeler seeks to understand control volumes at various hydrologic locations. Therefore, a clear and concise knowledge of modeling objectives driven by the spatial domain, functional needs, model complexity, and other factors must be provided; i.e., a collection of important hydrologic locations and a pre-existing catchment network. In many cases, the pre-existing network is an elevation surface (where grid cells act as catchments) and hydrologic locations are provided "pour points" where catchment outlets are desired.

Hydrologic connectivity is typically implicit in hydrographic datasets. That is, the geometric topology of the realized flowpath can be transformed into a feature topology that links realized catchment features. This is true whether the source of geometric topology is a collection of vector geometries or a path of high-flow accumulation derived from elevation data. For this use case, the hydrologic modeler must determine how the hydrologic network should be represented (as an edge list, an edge/node graph, strictly dendritic, etc.) and what hydrographic data are needed to produce the connected network.

Catchment characterization is the process of summarizing other spatial data to catchment areas through a summary function. In other words, polygonal catchment divides from hydrographic data sources are used to derive characteristics of landscape and geologic phenomena. The resulting values describe a single summary value for the interior of a catchment (HY_CatchmentArea in HY_Features terms). For the sake of this report, meteorological and hydrogeological data with a meaningful interaction with the surface are considered to be a type of landscape data that are a time varying "forcing" input.

Like catchment characterization, characterizing a river corridor requires a summarized set of field or coverage datasets for the river corridor region. Characterizing a river corridor is purpose dependent, and must be provided by a geomorphologist or hydroscientist. Part of the required information is the delineated "river corridor" as there is significant diversity in river corridor definitions. Such examples include, but are not limited to, the following.

Thus, it is assumed that the delineation specification is provided by a domain expert. Figure 1 shows a single "Geomorphic Data" source. However, depending on the specific application, river corridor characterization could concern ecological, hydrodynamic, biogeochemical, hydrogeological, or other domain-specific data sources.

Hydrologic locations are located "along" a flowpath of a catchment. Information observed at a hydrologic location can be affected by all catchments that comprise the sub catchments of the location’s drainage basin. The process of determining a hydrologic location takes this into account by requiring a hydrologist to determine the appropriateness of a given hydrologic location. On the other hand, a hydrologic modeler may want to find hydrologic data along the network of flowpaths of interest. In this case, a hydrologic location is a pre-existing link between a hydrologic model or analysis and data that are linked to that location.

A flow network location occurs along a flowing body of water that is meaningfully associated with the waterbody or its channel. Establishing a flow network location is similar to establishing a hydrologic location, however the information required to determine a location’s appropriateness is geomorphic rather than hydrologic. Any hydroscience application needing information linked to rivers could find utility in data associated with a flow network location. Figure 1 shows a single "Geomorphic Data" source for flow network location. However, this label is used to make a distinction with hydrologic data and could represent a wide array of data types associated with a flow network location.

Several of the information types can be categorized into "domain details." These details are information provided by an expert in the use case, such as modeling objectives for a given decision, or necessitated by the requirements of the use case. This information is included only for completeness and to fully describe the separation of concerns an analysis relies on.

Like domain details, information that could be considered attributes are presented only to illustrate a separation of concerns. These "attributes" include physiographic attributes of hydrologic features and constituent or characteristic attributes that might be derived through integrated processing.

Below we will describe key feature types needed to fulfill the objectives of the listed use cases. However it is important to recognize that HY_Features defines a catchment as a holistic unit where hydrologic processes can occur. Each catchment, however, can be realized in concrete ways to address specific needs or to encapsulate complexity. Realizations offer variable conceptual representation for the same real world holistic feature. In other words, a feature that is a catchment realization represents one aspect of the catchment that it is a realization of. The flowpath realization represents the aspect of the overall catchment concept that conveys flow from an inflow to an outlet. While the divide realization represents the aspect of the overall catchment concept that bounds landscape area that directly contributes storm flow and/or sediment.

The information required for the above use cases are primarily hydrologic and hydrographic features. Features in this context are an "abstraction of real-world phenomena" per OGC Abstract Specification Topic 5 [ISO 19101]. Although a feature, by this definition, can have a vector geometry representation, the simple features geometry specification does not apply. That is, a feature could have many highly nuanced geospatially tied representations or even no geometric representation at all as in a schematic of a watershed.

Hydrologic Locations

Hydrologic locations are features such as monitoring locations that occur along a flowpath. By tying these point locations to a hydrologic system, we can associate the entire drainage basin to that point. This is significant both in terms of measuring system response, as with a streamgage, as well as understanding system impacts on infrastructure, as with a bridge.

Hydrographic Locations

Hydrographic locations are very similar to hydrologic locations, but are not associated with a specific upstream drainage basin. For example, monitoring / sampling locations in a backwater channel of a floodplain do not capture all flow from the upstream basin but are located along a linear flowing waterbody (flowline). Such locations can have an indirect position expressed as some distance along the flowline but this position does not have to be the outlet of a drainage basin.

Flowpaths

HY_Features (OGC-16-032r2) defines flowpaths as one of several possible "catchment realizations". A flowpath is a linear geometry that can be associated with a coincident waterbody and channel feature. Both the waterbody and channel concepts of HY_Features include constraints "waterbody-flowpath and channel-flowpath" that: "whenever a flowpath exists as part of a network, the waterbody [surface depression and surface channel] should be recognized as a flowpath. Geometrically represented as a curve, waterbody-flowpath [channel-flowpath] will support to 'measure' a position on, or along, the waterbody using a centerline as shape."

As alluded to in the measure detail of the waterbody-flowpath constraint, the flowpath feature is also used as the "linear element" for the indirect position of a hydrologic location. Importantly, only the flowpath feature is allowed as the linear element of an indirect position as HY_Features does not support indirect positioning along a waterbody.

Flowlines

Flowlines are not, strictly speaking, hydrologic features. They are the result of fluvial geomorphic and human-influenced channelization that divert or otherwise convey water in a way that may go counter to classic dendritic assumptions. In hydrologic analysis, systems of flowlines are either encapsulated within catchments or treated as water withdrawals or additions.

Three specific cases where the "flowline" feature type is useful are: rivers with many channels, alluvial fans and distributary systems in deltas, and natural or built levees. In the first two, an abstract flowpath could provide an idealized representation of how water flows through a catchment. In the third case, however, there are often true "interbasin" transfers where, at some scale, water is diverted outside the catchment and cannot be idealized by a flowpath. In these cases, there is a diverted flowline and the receiving flowline does not realize a catchment.

In contrast with diverted flowlines, a hydrologic nexus can have more than one receiving flowpath (catchment realization) — causing a hydrologic divergence (a diverted flowpath with an associated catchment not just a diverted flowline). In this case, both receiving flowpaths would have a catchment and host of catchment realizations.

A logical data model that includes a class adhering to the flowline concepts described here is compatible with the concepts of HY_Features. This would be achieved through association to surface hydro features that form hydrographic and channel networks. However, since indirect positions can only reference flowpath features there would be no unifying linear representation of channel and waterbody other than flowpath for linear referencing. For this reason, the flowline concept may warrant being added to the HY_Features conceptual model.

Divides

Catchment divides provide a polygon partition of the landscape. In hydrologic (water budget) modeling, there is an expectation that the partitioning provides a complete coverage of the domain. However, this requirement presents a problem if every catchment is to have a nexus represented by a hydrologic location. This is important in catchment divides that are adjacent to major bodies of water and have no concentrated outflow and also inland (endorheic) catchments with no discernable terminal hydrologic location.

This issue relates to catchment divides in a somewhat indirect way. The requirement that a catchment divide encompasses a frontal or endorheic catchment brings this issue to light. In these cases, a logical or physical data model based on HY_Features concepts, is forced to create additional (conceptual) nexus realization feature types to accommodate diffuse frontal outflows and outflows of indeterminate internally drained catchments.

Catchment Network

In HY_Features, the catchment network model involves a system of catchments and nexuses. A catchment can accept flow from one - and only one - nexus and give flow to one - and only one - nexus. A nexus can take flow from one or more catchments and give flow to one or more catchments. Two important details were encountered in the work leading to this engineering report: 1) headwater catchments can be thought of as graph nodes, and 2) the inclusion of nexuses in the catchment network graph requires that they be represented as edges or that associations between catchments and nexuses be represented as edges. The importance of these two factors is especially relevant when considering that a catchment network has an associated network of features representing flowpath realizations.

In all drainage basins, a flowpath is not discernable in the most upper reaches of the headwater region. Therefore, if an application is to include flowpaths, there must be a threshold at which a flowpath begins. Considering the definition of "HY_Flowpath" from HY_Features (OGC 16-032r2): "The HY_Flowpath feature type realizes a catchment specifically as a path connecting the inflow and outflow of the catchment it realizes. HY_Flowpath specializes HY_CatchmentRealization with respect to an implied linear geometric representation including a straight or curved line. Topologically, the flowpath connects the inflow and outflow of the catchment, and is understood as an edge bounded by an inflow node and an outflow node,…​" This definition implies that, for a flowpath to exist, the catchment must have an inflow. For headwater catchments, no inflow exists and no flowpath exists. This logical interpretation of headwater catchments is compatible with the HY_Features model and could be considered as part of a logical implementation of the concepts.

Given that headwater catchments will have no inflow nexus and no flowpath, representation of a headwater catchment in a graph representation of a catchment network is most naturally accomplished as a graph node. It may feel most intuitive to represent nexuses as nodes and catchments as edges, but in practice, this is not feasible. In fact, if nexuses are included in the network explicitly, a network terminus is always a nexus and, therefore, a graph node as well. The fact that a complete catchment network must start at a headwater with no inflow nexus and terminate with a nexus leads to the finding that a graph implementation of HY_Features should treat both catchments and nexuses as nodes and the associations between them as edges.

HY_Features includes one conceptual representation (realization) of the nexus concept, a hydrologic location, which is idealized as a point. If the outlet of a catchment network must be a nexus and that nexus is idealized as a point, coastal (or otherwise "frontal") and indeterminate internal network outlets present a problem. As described in HY_Features Change Requests, addition of frontal and internal nexus realization conceptual feature types to HY_Features may be warranted.

Waterbody Network

A network of waterbodies coexists with a network of catchments and their flowpath representations. The complexity of this relationship can be daunting, but in practice, it can be approached pragmatically. If a flowline is a linear representation of a waterbody and a flowpath is a special type (perhaps a subclass) of flowline, then we can start with a highly resolved network of waterbodies and consider all of those on the main hydrologic path to be flowpaths. The two networks (flowpath and waterbody) then, have an explicit relationship defined by the "main paths" through the waterbody network. Additional network representations (e.g., lidar derived vs legacy DEM derived) can be conflated via the main hydrologic paths. Integration of a complete waterbody network (as opposed to the more general hydrologic network) would require additional, more nuanced, integration.

Integration of hydrologic and waterbody networks is promising to facilitate stability of hydrologic networks and associated data and while enabling interoperability of less persistent (changing or improving) networks of waterbodies. For instance, a system built to track the location of features such as dams, streamgages, hydrologic model intercomparison locations, etc. can exist on a stable backbone of hydrologic features that intersects with one or more representations of channels and waterbodies that relate to the hydrologic network.

A final note on waterbody networks concerns flow connectivity. While a hydrologic network will most often be a directed acyclic graph, a network of waterbodies may not be directed at all. Coastal and confluence environments may have backwater channels that flow either direction. Despite this, the representation of channel bathymetry and location of data along such channels must still be supported. This drives the need for an indirect position capability that takes into account the nuances of non-hydrologic waterbodies.