Subnetworks are updated to ensure attributes, network features, and connectivity are current and valid in a network. Updating a subnetwork also exposes inconsistences in a subnetwork, such as invalid features, disjointed or inconsistent subnetworks, and incorrect numbers of subnetwork controllers. The Update Subnetwork tool is used to update subnetworks that are marked as dirty after edits have been made, marking them as valid.
Subnetworks are marked as dirty when they're created and from validating the network topology after features and objects in the subnetwork are edited. When a subnetwork is updated with no errors, it's marked as clean. This is tracked by the Is dirty attribute in the Subnetworks table. See Dirty subnetworks to learn more.
Subnetwork properties inspected and updated
When a subnetwork is updated, certain properties and requirements are checked. There are also certain attributes that are updated for network features. Some of these properties are set in the subnetwork definition for the tier.
When a subnetwork is updated on the default version, the geometry, subnetwork name attribute, and the propagated fields of the SubnetLine feature class are updated. If executed against a named version, by default, these same updates are limited to features and objects that are edited within the version. The edit mode can be changed to use eventing in the Set Subnetwork Definition geoprocessing tool for utility networks of version 4 or later.
Dive-in:
The Update Subnetwork tool performs attribute edits in place for all network classes with the exception of the SubnetLine feature class. This means that the update subnetwork process bypasses eventing and will not prompt the evaluation of attribute rules. The default edit mode policy can be configured for both the default version and named versions as part of the subnetwork definition for the tier. The Edit Mode for Default Version parameter specifies the edit mode for subnetwork updates on the default version and with file and mobile geodatabases.Learn more about the edit mode used by the Update Subnetwork tool
Errors can be generated from updating subnetworks. To learn more about errors specific to updating subnetworks, see Update subnetwork errors.
The following subsections include information about the properties that are inspected when a subnetwork is updated.
Valid features and objects
As specified in the subnetwork definition, certain asset groups and asset types for each class are defined as valid for each tier in a domain network. Features and objects that violate the subnetwork definition are discovered when updating the subnetwork by inspecting the attributes of traversable features in the subnetwork. If invalid network features are discovered when updating a subnetwork, an error is created.
When updating subnetworks, the valid devices property for the subnetwork definition is not evaluated for boundary features that connect multiple subnetworks. These are subnetwork controllers that define the boundary of two different subnetworks, for example, an open switch between two circuits or a closed valve between two zones.
The following valid features and objects are specified in the subnetwork definition of each tier:
- Valid Devices
- Valid Device Subnetwork Controllers
- Valid Lines
- Valid Junctions
- Valid Edge Objects
- Valid Junction Objects
- Valid Junction Object Subnetwork Controllers
Subnetwork name attribute
The Subnetwork name attribute is used to track which subnetwork network features belong to. The value populated in this attribute field is derived from the subnetwork name of features that are set as a subnetwork controller. Additionally, features in the domain network have Supported subnetwork name and Supporting subnetwork name attributes. These attributes help track the subnetwork that a container or structure feature supports and the subnetwork that supports a content feature, respectively.
When a feature participates in multiple subnetworks, the Subnetwork name, Supported subnetwork name, and Supporting subnetwork name attributes are concatenated with each subnetwork name. For example, a boundary feature that connects multiple subnetworks would be updated by concatenating the subnetwork names separated by two colons, for example, subnetwork1::subnetwork2.
Learn more about the subnetwork name attribute
The update subnetwork process ensures that the subnetwork name is consistent for subnetwork features. Errors are generated for any inconsistencies. The following situations outline cases in which errors may be encountered:
Inconsistent subnetworks—When a subnetwork has multiple subnetwork controllers that are traversable and the Subnetwork Name attribute does not match, the subnetwork is considered inconsistent. For example, in a mesh network with five subnetwork controllers, four of the subnetwork sources have the correct subnetwork name, while the fifth has a different name. If inconsistent subnetworks are discovered when updating subnetworks, a warning is returned in the Update Subnetwork tool and errors are generated. The specific subnetwork names found to be inconsistent are returned and can be inspected using the Modify Subnetwork Controller pane and the Subnetworks table. Additionally, errors are created for the subnetwork controllers that have inconsistent subnetwork names.
Disjoint subnetworks—For partitioned domain networks, subnetworks with controllers that have the same subnetwork name and are not traversable are considered disjoint subnetworks. When updating subnetworks, errors will be generated for disjoint subnetworks if the subnetwork definition does not allow for this. This setting is defined within the subnetwork definition for the tier. Check the network properties to review the Tiers subsection of the specific domain network.
If any of the neighboring subnetworks are found to be inconsistent, a warning is returned during the update process listing the conflicting subnetwork names. To determine how to resolve the warning, neighboring subnetworks mentioned can be inspected using the Modify Subnetwork Controller pane and the Subnetworks table. Once the neighboring subnetworks are edited, the update subnetwork process can be executed again.
To learn more, see Subnetworks.
Is connected attribute
Every feature in the line, device, and junction feature classes as well as every object in the domain network's junction object and edge object tables contains an Is connected attribute. This attribute helps identify isolated network features and objects by maintaining information about their connectivity to subnetwork controllers. When a feature is created, regardless of its connectivity, the Is connected attribute is set to unknown. This attribute is modified for network features depending on the operation being performed.
When a subnetwork is updated, the Is connected attribute is modified based on the connectivity of features to a subnetwork controller; this is based on the Tier or Subnetwork Name parameters specified in the Update Subnetwork geoprocessing tool.
To learn more, read about the Is connected attribute.
Is dirty attribute
The Is dirty attribute is used to track the state of a subnetwork in the subnetworks table and SubnetLine feature class and also impacts the consistency of network diagrams. This attribute is managed using the validate and update subnetwork operations. The Manage IsDirty option is configured as part of the subnetwork definition for a tier. This provides the option to bypass management of the Is dirty attribute in the Subnetworks table and SubnetLine feature class. This also impacts the consistency of network diagrams. This is disabled by default when there are no subnetwork controllers defined for the tier.
To learn more about the Is dirty attribute, see Dirty subnetworks.
Summaries, propagation, and attribute substitution
Summaries that are configured in the subnetwork trace configuration of the subnetwork definition are updated during the update subnetwork process. When updating a subnetwork, the tool writes the results of the summaries into the SubnetLine feature class for the summary attributes. Also, if substitution or propagators are configured, they are considered when a subnetwork is updated.
Review the following for more details: Summaries, Attribute propagation, and Attribute substitution.
Update subnetwork policy
When the update subnetwork process is executed, there are several options available that control what network features are updated and how the edits are performed in the geodatabase. These options are configured as part of the subnetwork definition for a tier using the Set Subnetwork Definition tool.
Review your workflows and determine whether changes are needed to the default update subnetwork policy. The Update Structure Network Containers and Update Domain Network Containers options can be modified in the subnetwork definition to prevent issues where the supported subnetwork name field may be overloaded for structure and domain network containers. This can be helpful in situations where there is nested containment. If there is a workflow that requires geodatabase events to occur for the attribute edits made during the update subnetwork process, the subnetwork definition for the tier can be configured to use eventing for the edit mode for the default version.
Options available to set for update subnetwork policy are as follows:
- Manage IsDirty—Specifies whether the update subnetwork process will update the IsDirty attribute in the Subnetworks table and SubnetLine feature class. This also impacts the consistency of network diagrams.
- Update Structure Network Containers—Specifies whether the update subnetwork process will update the supported subnetwork name attribute for structure network containers. This option is checked by default.
- Update Domain Network Containers—Specifies whether the update subnetwork process will update the supported subnetwork name attribute for domain network containers. This option is checked by default.
Edit Mode for Default Version and Edit Mode for Named Version—During the update subnetwork process, various attribute edits are made to subnetwork features. The Edit Mode determines how the attribute edits are performed. Two options are available to control this behavior: With Eventing and Without Eventing.
- Without Eventing—This is the default for both the default version and named versions. When using this option, edits are performed as direct writes. By performing these attribute edits as direct writes, you bypass any events at the geodatabase level that update feature-linked annotation, or the evaluation of an attribute rule set on the insert or update triggering event. Note that while on the default version, all features and objects in the subnetwork are updated. In a named version, updates are limited to features and objects that are edited in the version.
- With Eventing—This option triggers events at the geodatabase level to update items such as feature-linked annotation, editor tracking, or the evaluation of an attribute rule set on the insert or update triggering event as well as the subnetwork name and propagated values for all applicable features and objects.
Note:
Certain parameters require a minimum Utility Network Version. Refer to the Set Subnetwork Definition tool for more information.