Subnetworks are updated to ensure attributes, 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 subnetwork features 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, these same updates are limited to rows that are edited within the version.
Errors can be generated from updating subnetworks. To learn more about errors specific to update subnetwork see Error management.
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. This default edit mode policy can be configured as part of the subnetwork definition for the tier.Learn more about the edit mode used by the Update Subnetwork tool
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 dataset 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 features are discovered when updating a subnetwork, an error is reported and error features are 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 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 a supported subnetwork name attribute. This attribute helps track the subnetwork that a container or structure feature is supporting.
When a feature participates in multiple subnetworks, the subnetwork name and supported 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. Error features are generated for any inconsistencies. The following situations outline cases where 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, an error is returned in the Update Subnetwork tool and error features 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, point error features 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, error features 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.
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 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 if changes are needed to the default update subnetwork policy. The update structure and container features options can be modified in the subnetwork definition to prevent issues where the supported subnetwork name field may be overloaded for structures and containers. This can be helpful in situations where there is nested containment. If there is a workflow that requires geodatabase eventing 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:
- Update Structure Features—Specifies whether the update subnetwork process will update the supported subnetwork name attribute for structure features. This option is checked by default.
- Update Container Features—Specifies whether the update subnetwork process will update the supported subnetwork name for container features. 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. By performing these attribute edits as direct writes, you will bypass any eventing at the geodatabase level. Examples include feature linked annotation, or the evaluation of an attribute rule set on the insert or update triggering event. The default behavior is without eventing, to perform attribute edits as direct writes.
Note:
Update subnetwork policy options require Utility Network Version 4 or higher. The Edit Mode For Default Version and Edit Mode For Named Version options are only applicable to enterprise geodatabases.