Utility Network Topology: When to Disable and When to Enable

Why is it Important Understand How to Maintain the Utility Network?

Understanding how to maintain the Utility Network is crucial not only to best serve your customers without interruption but also to keep the UN functioning optimally after it is live in production. To be fully prepared, you’ll need to determine the answers to these questions:

• Will downtime be required?
• Which scenarios require the network topology to be disabled?

Adding or Deleting New Utility Network Rules

To follow-up from the previous post on Resolving Network Errors, network rules may need to be added once your Utility Network is live as new business rules are formed.

Since adding or removing network rules is modifying the Utility Network, this requires the network topology to be disabled before the change is applied. The workflow looks like this:

  • Change Version Access to Public (if not already)
  • Disable the Network Topology
  • Add/Remove Rule
  • Enable Network Topology
  • Change Version Access to the Desired State (if public is not the “normal” operational state)

Tip: Version access of the Default Utility Network version must be “Public” to disable the Network Topology.

Bulk Attributes Updating with the Network Topology Enabled

There are a few supported ways to tackle bulk attribute updates while the utility network topology is enabled. For example, bulk changes to the attribute values in the Asset Group or Asset Type fields to another value that is defined in the subtype or domain do not require the network topology to be disabled. This type of change would result in new dirty areas being generated, just like any other edit.

Evaluation of the Utility Network to determine how a bulk attribute change impacts the number of data errors should be taken into consideration before the change is applied. Esri recommends disabling the network topology for attribute updates of a large number of records. If a Utility Network rule is not defined that allows the new connection or association, the result is an increased number of UN errors. (The resulting dirty areas would not validate without a new rule being defined.)

The snapshot below shows an example of a bulk attribute change while the network topology is enabled. This update modifies anodes in the device feature class from an Asset Type of “Unknown” to “Cast Iron”.

The purpose of this change is to resolve Utility Network errors by updating the historic anode data that previously did not have a material defined. This change improved the overall quality of the data. There are no dirty areas in the extent below because anodes of “Unknown” Asset Type connecting to services were defined in the network rule base to meet our client’s requirements.

FME Workbench was used to change the Asset Type from “Unknown” to “Cast Iron”. Note that only 64 records are being updated, posing a minimal time impact to the network’s rule validation of each edit that is performed with the network topology enabled.

Dirty Areas (denoted by purple squares) were generated by the Utility Network and are awaiting validation.

The Validate Network Topology tool is run to evaluate the dirty areas against the UN rules.

The dirty areas have been cleared and no new errors are generated.

Adding New Subtypes and Domains to Asset Group and Asset Type

In contrast, adding a new subtype or domain value to Asset Group or Asset Type requires the network topology to be disabled. If a subtype or domain was removed, any existing records containing the removed value in Asset Group or Asset Type will result in a data error (See error code 23), once the network topology is re-enabled.
Other considerations (but beyond the scope of this article) when executing a bulk attribute update are the impacts on downstream systems, how-to best handle annotation appending, and dealing with outstanding branch versions.

Appending a Large Number of Records to a Utility Network Feature Class

While bulk attribute updates and smaller data loads are supported with the Utility Network topology enabled, Esri recommends disabling the network topology before loading a large amount of data to a UN feature class. Why? Disabling the UN topology prevents the evaluation of the edits against the network rules until the network topology is re-enabled.

Loading a large amount of data to the UN with the topology enabled (as seen in the above example) results in the creation of dirty areas that would need to be validated against the rule base by running the Validate Network Topology tool. Currently, the runtime of the enable network topology tool is faster than the validate network topology tool, making disabling the network topology before data loading the recommended workflow.

So How Much Data Is Too Much to Load to the UN with the Network Topology Enabled?

Great question! Error counts and the impact on the network performance are a factor in the answer. Remember in the previous blog post on Resolving Utility Network Errors that the upper limit of data errors to the UN is around 100,000? The Locana team discovered that up to this threshold, we were still able to enable the topology and run validate network topology.

However, going beyond this number runs the risk of not being able to fully validate the network topology in a comfortable amount of time (less than 24 hours). Esri’s recommendation is to not allow more than 10,000 errors when running enable network topology.

It took some clever data processing and network configuration by the Locana team to reach Esri’s recommendation. The latest network dataset delivered to one of our gas clients contains just under 10,000 total network errors.

The Locana data team has provided some metrics on the time it takes to enable the UN at different error levels, visualized in the chart below.

The same dataset was used to form these benchmarks for accurate comparison. There are a few conclusions we can draw from the chart (ideally, some more data points would have helped). Note that between 5,729 and 9,091 data errors the time to enable the network only took one additional minute. Also, the time to enable this dataset took about 100 minutes per 10,000 data errors.

Wondering why it’s important to know how many errors your updates are generating? When planning system outages, having this knowledge ensures the adequate time is accounted for to re-enable the network topology.

Other Actions Requiring a Disabled Network Topology

Some other actions that require a disabled Utility Network state are when importing new:

  • Associations
  • Subnetwork Controllers

Don’t forget to take a look at the other posts in our series about using and maintaining the Esri Utility Network for gas:


Share this post

Become an insider

Sign up for quarterly insights on topics you care about, including GIS, geospatial, enterprise systems, open data and development, and more. We’ll share industry best practices, user stories, and relevant information you can use in your own work.