Gravity Based Networks - Advanced Configuration
In this article, we will examine some of the more advanced configurations that can be applied to gravity-based networks to answer more sophisticated questions and to improve data quality. We will look at how the utility network addresses these challenges through its use of subnetworks, terminals, and rules.
Is everything connected?
Being able to run traces to identify the flow direction in our system is a useful analytical tool, but a common question we need to answer is whether all our features are properly connected. The simplest, but least efficient, way to determine this is to place a trace location in your map and run a connected trace. This trace will identify all the features that are traversable to that location. This works well for small networks where everything is connected, but if your dataset is very large this trace will take more time and if your data is not all connected to a single connected system you need to provide multiple start locations to cover your entire network.
Below you can see an example of a stormwater dataset. Because only the catchment areas are modeled, and not the rivers and channels that connect them, a single connectivity trace cannot be used to identify disconnected features.
One of the ways the utility network can help identify disconnected features is by configuring subnetworks. A subnetwork represents a named subset of our utility network with a set of devices that are responsible for controlling the resources in that area. In the case of a stormwater network this is typically the outfalls that are controlling each catchment area.
If we were to turn all the outfalls for our catchment areas into subnetwork controllers we would be able to run a trace to find everything that was connected to our network. We can simulate this by running a connected trace using each outfall in our network as a starting location.
If we were to create a single subnetwork called “Stormwater System”, with each of these devices as a subnetwork controller, the selected features in the graphic above are what the subnetwork would look like. While this is useful from an initial quality assurance perspective, it would be a lot more useful if we modeled each collection of outfalls that governed an area as controllers for a specific catchment area. The engineers who rely on GIS data to maintain planning and engineering models already track this information outside GIS. By modeling catchment areas inside GIS, we can validate the changes we make are not only topologically correct, but that they also validate the information required by engineers or planners to produce their models.
Depending on the quality, complexity, and volume of data you maintain you may decide to just model a single subnetwork for your entire system, or you may decide to create separate subnetworks for each catchment area. We will be discussing the more difficult task of configuring separate subnetworks. These instructions will assume that when you ran the Migrate to Utility Network tool and you identified one or more layers as having controllers in them, if not, you will need to perform additional configuration to allow a feature to be a subnetwork controller.
Rules and Terminals
By default, the Migrate to Utility Network tool will configure subnetwork controllers in a sink-based network to only connect to features using their Upstream terminal. If you don’t model anything downstream of your outfalls, then you can move onto the next section where you see how to create your subnetwork controllers.
The first thing we should do is review the rules in our network using the network properties dialog. Below we can see a subset of the rules for our discharge points. If we look closely we can see discharge points have been configured to connect to every type of line in our model using their upstream terminal.
We can refine these rules so they more accurately reflect the way that our discharges should be connected to other features in the network.
- Outfall – These features allow a pipe to drain into an open drain
- Overflow – These features allow a pipe or virtual drain line to overflow into an open drain
- Standard Outlet – These features allow a pipe to discharge into a virtual drain line
- Terminal Discharge – These features allow a pipe or open drain to exit the system
We need to run the Add Rule and Delete Rule tools to get the rules configured to match these requirements. Once we’ve configured the rules and enabled our network topology, we are likely to see connectivity errors (the red lines in the graphic below) in our database for many of our discharge points.
Depending on your data and how you adjust your rules you will see two different kinds of errors: Invalid connectivity – There is not a rule that allows the two features to connect.
Ambiguous connectivity. – There is more than one rule that allows the features to connect.
While we could review each error individually and determine how to fix them one at a time, if there are more than a few errors it is more efficient to use the Analyze Network Data tool to give us a summary of all the types of errors.
In addition to creating a layer file that can be used to review our errors, the tool also outputs a RuleCandidates.csv file. This file contains any rules that could be added to the network to resolve connectivity errors. You will want to carefully review the list of rules before importing and only import rules for features that should be allowed to be connected. You may need to check with an engineer or field worker to determine what is appropriate. You can learn more about this process in the Refining connectivity rule article.
Once you’ve determined which rules you want to add, use the Import Rules tool to add the rules to your utility network. Remember that before you can add rules you must disable the network topology.
Once you’ve added the missing rules and enabled the network topology again, you will then need to use the Modify Terminal Connections tool to resolve any ambiguous connectivity. This is only required if you have a line that is allowed to connect to more than one terminal on a device.
If you want more examples of working through these kinds of connectivity errors you can find three tutorials to help guide you through this decision making process in the Editing and connectivity learning series.
Once our network topology is enabled and error free, we’re ready to move forward with creating our subnetworks.
Create a simple subnetwork
The first thing we need to do is identify the outfalls that act as subnetwork controllers for each catchment area of our network. This can be done by running a connectivity trace for an area of our network and stopping whenever we reach an outfall, which have been configured as subnetwork controllers. While we could manually select and add barriers for these features, it is often easier to use a condition barrier to automatically identify these features when tracing. To do this we add a condition barrier to our trace for features with a Category of Subnetwork Controller.
This will cause the trace to stop for any feature whose asset type has a category of Subnetwork Controller, in this case outfalls. This network category is initially populated by the Migrate to Utility Network tool for any mappings you designated as being controller. You can also adjust this later using the Set Network Category tool. We can see the results of such a trace below.
In this instance, we have an area that is all connected to a single outfall. Use the Modify Subnetwork Controller tool to set the upstream terminal of the outfall, the side that receives materials, a subnetwork controller to a new catchment area. The subnetwork controller needs a unique name, and this area needs its own unique name as well. If we discuss our catchment areas and outfalls with engineering or operations, they may already have specific identifiers that they want us to use. Using the same unique identifiers as other departments will also facilitate collaboration and communication.
After validating the change with the network, we can now run a subnetwork trace to see all the features connected to this outfall.
We can also use the update subnetwork tool to store the name of the catchment area on these features. This makes it easy for us to identify which features belong to a catchment area, and which do not.
After running this tool, we can see that all the features in this subnetwork have their subnetwork name populated.
And we can see that there is now a subnetwork line feature that represents all the lines in this catchment area.
Once you’ve used the Update Subnetwork tool to create a subnetwork line, that subnetwork will now appear in the Find Subnetwork pane when that line is in the current extent.
Now that we’ve seen how to create a simple subnetwork with a single controller, let’s look at how to handle a catchment with multiple outfalls.
Subnetworks with multiple controllers
Not every subnetwork has a single controller. Stormwater networks often have multiple outfalls that are responsible for discharging water from a catchment area, depending on how much water is in the system at a given time.
We begin the process the same way; by performing a connectivity trace in our network and treating subnetwork controllers as a barrier, this will cause the trace to stop at outfalls. Consider creating and using a trace configuration for this trace to help make the process easier.
In this instance we have a catchment area with three outfalls. We repeat the same process as above, uniquely naming each outfall, but we give each of these outfalls the same subnetwork name. This is because they are all sharing the responsibility of discharging water from the same area.
Note: If you do not provide a subnetwork controller name, the tool will automatically use the global id of the feature.
Once again, validate the network topology and run update subnetwork to finish creating the second catchment.
Repeat this process until all the features in the network belong to a subnetwork. This sounds easy, but let’s look at some of the most common problems that can arise.
Missing Controllers
Using this process provides a reliable, but manual process for identifying all your subnetworks. The most common problem you will run into is that the subnetwork controllers may be missing from your data, or data problems can cause a catchment area to appear much larger than it should be. Looking at the example below we can see what should have been a small catchment area is appearing as a much larger area.
If we zoom into the region called out in the image above, we can see that the problem is there isn’t an outfall between the pipes of the catchment and the open channel it drains into. This is called out in the graphic below.
To correct this error we would work with an engineer or field crew to ensure the GIS matches what is currently installed in the field. In this case we would create an outfall between the pipe and the river channel. We would then make this new outfall a subnetwork controller for our third catchment area.
If we look closely at the above screenshot, we can see that there is still a potential problem in this area. Some of the pipes north of this catchment don’t have any form of outlet. If we zoom in we can see that this area likely should be connected to the catchment area. We would need to confirm with an engineer or field crew that this is indeed the case, but once we’ve determined how/if it is connected, we can then update our GIS data to reflect this.
Conclusion
In this article you learned how to use subnetworks, rules, and terminals to improve your data quality. You saw how this allowed you to identify missing features, improperly connected features, and how to identify locations in your network without any outlets. If you’re interested in more advanced analysis tasks like watershed or sewershed management or managing sub-basins and catchments, let us know! If you have any questions about the utility network, be sure to ask them on the Esri Community site.
If you want to know more about using the utility network to manage gravity-based networks, like sewer and stormwater data, please explore the Learn ArcGIS Utility Network for Sewer and Stormwater learning series. This learning series includes tutorials and articles that demonstrate how to address the needs of the sewer and stormwater industry using the utility network.
