ArcGIS Utility Network

Analyze stormwater networks using the ArcGIS Utility Network

Managing stormwater infrastructure is about more than preventing flooding, it’s about treating water like the precious resource it is. Managing runoff is about acting as responsible stewards to ensure we convey water through our manmade infrastructure, and back into natural areas where it can begin the cycle once more. Throughout this journey, we must take care to manage both the quantity and quality of water as failing to do so will have long-term consequences for our health and safety.

Dense urban areas face the greatest challenges since much of their surface is covered in impermeable materials that prevent rainwater from being absorbed naturally into the ground. In this article, you will learn how GIS and the ArcGIS Utility Network can be used to better manage these precious water resources.

Aerial imagery depicting manmade infrastructure in the desert

The first step to answering these questions is to have an accurate model of the natural and manmade infrastructure used to capture and manage stormwater. GIS has long been used to catalog our observations of the natural world, and with the introduction of ArcGIS Online and the ArcGIS Living Atlas this has made finding and sharing the data essential to natural resource management easier than ever before. But what about managing the human infrastructure?

If you are interested in learning more about how data is stored and managed using the utility network, I recommend you read the first article in this series in which we introduce the basic concepts and terminology you need to understand to model stormwater data using the utility network.

If you’ve already read that article, or are familiar with those concepts, we can then continue the discussion of modeling and terminology with an overview of how to model catchments and flow in the utility network. You will find many of the ideas and configurations discussed here reflected in the Stormwater Utility Network Foundation, but this article serves as a reference for why certain decisions were made, and why the system behaves the way it does.

Sources or Sinks

To an outside observer the process for calculating flow seems simple, we should assume that water starts at every inlet and flows as directly as possible to each outlet. While at a high level this is correct, we must also consider how to represent the effect gravity has on flow or how flow may change when the system experiences a high volume of runoff. Before we get too far into the weeds of these more advanced scenarios, we’ll start with the basics of how the utility network can be configured to represent flow in the stormwater model.

One of the first decisions made when creating a domain network in the utility network is whether the flow will be calculated using sources or sinks (you can’t use both). This decision is important because it determines whether you will need to track and manage flow by managing a known set of inputs (sources) or a known set of outputs (sinks) in your system. Because a stormwater system may have hundreds of inlets for every outlet (not to mention natural infiltration through pipes), it is more manageable to model the domain as a sink-based network.

A table showing the properties of a stormwater domain network. The table shows the name and alias of the domain are stormwater, the tier definition is partitioned, and the subnetwork controller type is sink.
Stormwater domain network properties

To establish flow, all the outlets in the network must been registered as sinks within the network, this is known as enabling a feature to be a subnetwork controller. We will discuss subnetworks and subnetwork controllers a little later in this article. For now, all you need to know is that once you have established all your outlets as subnetwork controllers, downstream traces will identify the path to the nearest outlet, and upstream traces will identify all features that carry water flowing through the location being analyzed.

The graphic shows two example networks. The left network shows downstream flow originating at two inlets flowing towards channel outlet. The right network shows upstream flow originating at a channel outlet and flowing towards the two inlets.
Upstream and downstream tracing in a stormwater network

Now that we see how the system can calculate flow direction when performing upstream and downstream analysis, let’s look at how we can leverage this capability to model catchments and subcatchments by introducing a new concept from the utility network: the subnetwork. Much as a subcatchment represents a small, contiguous portion of a larger catchment, a subnetwork represents a connected, topologically distinct portion of your larger utility network.

In practice this is achieved by identifying all the outlets that receive runoff in an area of our network. This area is then turned into a subnetwork by configuring each of these outlets to act as subnetwork controllers for that subnetwork. Each subnetwork can have multiple controllers, so if your catchment or subcatchment has multiple outlets, each one can still act as a controller, they would just need to be configured to have the same subnetwork name (e.g. catchment or subcatchment name).

Below, you can see an example where the pipe and channel outlets act as subnetwork controllers for the catchment and subcatchment subnetworks.

This graphic uses polygons to represent the extents of subnetworks in a stormwater network. There is a box containing an inlet and subnetwork controller that represents the subcatchment subnetwork. The subcatchment subnetwork is contained in a larger box that also contains a pipe connection and a different subnetwork controller representing the catchment.
Subnetwork controllers and subnetworks for a catchment and subcatchment

The most obvious benefit of creating these subnetworks is that we can then use the utility network to do upstream/downstream tracing; however, several additional benefits become apparent once you become familiar with how subnetworks behave.

The first is that when a feature belongs to a subnetwork, the name of that subnetwork is recorded on that feature. This helps you to quickly identify which subnetwork a feature belongs to (without tracing) and makes it easier to identify and correct features that don’t belong to a subnetwork.

This graphic shows a map with a stormwater pipe selected. There is a popup that shows the pipe is a gravity pipe that belongs to a subnetwork called Catchment K.
Subnetwork names are stored on features in the utility network

Next, just like connectivity is validated when features are edited in the utility network, so are the subnetworks. As your data is modified, you can keep track of which subnetworks are affected by those changes and take appropriate steps to perform quality assurance in those areas of your network.

The graphic contains a table representing subnetworks in a stormwater domain network from the sample dataset. There are catchments from A to M shown, along with the DuPage river basin. Catchment H has an icon with a white exclamation point in a red circle next to it indicating an error. Catchment K has an icon with a black exclamation mark in a yellow triangle next to it indicating a warning.
Example list of stormwater subnetworks, including subnetworks that are dirty and have errors that need correcting

This then raises an interesting question, if the subnetwork name is stored on the feature, how does the system represent the fact that a feature belongs to both a catchment and a subcatchment?

To answer this, we will use some new terminology then define and discuss the new terms in the following sections of the document: Catchments and subcatchments are considered different “tiers” in the network and that the stormwater network can be configured to be hierarchical. Tiers allows each feature to belong to both a catchment and a subcatchment at the same time.

Tiers

First, let’s cover what a tier represents in the utility network. To do so we will examine the concept of a subnetwork more closely. A subnetwork is a collection of features that represent a common area of flow within the network. In addition to the subnetwork name and its controllers, another important characteristic of the subnetwork is its tier.

Each tier contains a subnetwork definition, which is itself a collection of rules that govern what types of features can act as controllers for that kind of subnetwork, which features are allowed to participate in that kind of subnetwork, and any special behaviors that need to be considered when performing analysis within the subnetwork such as how to behave during heavy weather events.

The graphic shows the set subnetwork definition geoprocessing tool. The tool is pointed at the stormwater utility network, stormwater domain network, and stormwater management area tier. It shows that this subnetwork supports disjoint subnetworks. The form has several collapsed sections for Valid Features and Objects, Subnetwork Trace Configuration, and the Update Subnetwork Policy.
The set subnetwork definition tool lets you view/edit the subnetwork definition for a tier in your utility network

Each tier also has a rank, which allows the system to understand whether it should be treated as upstream or downstream of other tiers. Rank 1 is always the ultimate source/sink of the system, so in a stormwater system the catchment is rank 1 and any subcatchments are rank 2. This means that a subcatchment is always upstream of a catchment, and a downstream trace from a subcatchment can be set to either stop at the outlet for the subcatchment or at the outlet for the catchment.

The graphic shows a table describing the definitions for two tiers in the stormwater domain network. The first tier is the catchment with a rank of 1. The second tier is the subcatchment with a rank of 2.
Example of tiers and ranks for a subnetwork domain network that includes subcatchments

We also mentioned that stormwater networks are hierarchical. This is another property of the domain network called the tier definition, which allows a system to be either partitioned or hierarchical. The difference between these two types is that features in a partitioned network can only participate in a single subnetwork, while features in a hierarchical network can participate in a single subnetwork for each tier.

This graphic has two charts comparing the structure of a partitioned network and a hierarchical network. The graphic on the left represents a partitioned network where each subcatchment is represented as a rectangle and points to a circle that says catchment. The graphic on the right represents a hierarchical network where each subcatchment is represented as a circle contained in a larger circle that says catchment.
Graphic demonstrating the difference between a partitioned and a hierarchical network

If you only care about the path to the nearest outfall, and don’t think about your systems in terms of catchments and subcatchment, then a partitioned domain will meet your needs. If you want to differentiate your subcatchments from your catchment and want to be able to trace from an inlet to the terminal discharge point(s) downstream of that location (and not just the nearest outlet) then you will want to make sure your domain network is configured to be hierarchical.

This graphic shows how subnetworks are represented in a hierarchical subnetwork using arrows. It shows two subcatchments: one that extends from the inlet to the pipe outlet and another one that extends from the pipe outlet to the channel outlet. It shows the catchment starting at the inlet and extending to the channel outlet.
Graphic showing the extent of catchments and subcatchments in a hierarchical model

Conclusion

Once your utility network is configured and calibrated to model flow, you will find the editing workflows for the utility network allow you to keep your model valid more easily. All network edits are validated against the rules for the model and your subnetworks make it easy to identify disconnected features. These checks, along with any business rules you have configured, will give you confidence that everyone in your organization can trust the data and the results of the analysis they perform. Because the utility network is supported in mobile, web, and desktop applications this means that everyone in your organization will be able to benefit from access to this data regardless of whether they’re in the office or in the field.

What else can you do once you have your data in the utility network? Consider using it to simulate rainwater/flooding using ArcGIS Pro. Talk with your engineers about how to better incorporate the as-built GIS model into the software they’re using for design and planning. If you want to learn more about using the utility network to model water, wastewater, and stormwater datasets check out the Learn ArcGIS Utility Network for Water Utilities learning series.

About the author

Robert Krisher is a Product Engineer with Esri who has over 15 years of experience implementing Enterprise GIS for Utilities.

Connect:

Next Article

What's new in ArcGIS Workflow Manager 11.3

Read this article