Deep Dive: Network Attributes
If you’ve read about how tracing works with ArcGIS Utility Network, you’ve probably noticed that many of the capabilities require network attributes. These are the attributes that are used to define whether a device open/closed, in service/retired or any other characteristic of a feature that needs to be considered when the system is performing its analysis. The purpose of this article is to discuss some of the technical implementations of network attributes so you can make informed decisions about how you configure your utility network.
What is a network attribute?
A network attribute is an attribute that has been configured for use in analysis with a utility network. Network attributes can be used to as traversability barriers like condition barriers or filter barriers. They can also be used to control the output of tracing by creating an output condition or for summary functions. The only way to use a non-network attribute in tracing is to use the Feature result type to export the attributes association with a feature.
Setting a network attribute is a two-step process. First, you must define a network attribute in the utility network using the Add Network Attribute tool. This will not add any fields to your feature classes, it only defines an attribute that can be used in analysis.
To populate this network attribute, you must map a field from one or more of the classes in your utility network using the Set Network Attribute tool. The fields that are mapped to the network attribute don’t need to have the same name, but there are some constraints when mapping fields to a network attribute. If the field you want to set as a network attribute isn’t showing up in the dropdown, it is either because the field doesn’t have the correct data type or the field is nullable, but the network attribute is non-nullable. Fields used for network attributes that have domains assigned should have similar domain values to ensure behavior during analysis.
When a field is designated as a network attribute, this means that the utility network will store a copy of that feature’s value in the network’s system tables for use with analysis every time the feature is validated. This allows the network to perform analysis more quickly, since all the information required to make decisions during analysis without needing to query values from individual features. Storing more information in the network for analysis means more will need to be read from features when they are validated, more information must be persisted in system tables, and more information must be read from system tables during analysis.
Not all storage is equal, and in the next section we will discuss the different options for how to store network attributes and how they affect performance.
Performance
The most important decision when creating a network attribute is to decide whether it will be stored in-line or not. Network attributes that are stored in-line are stored inside the network topology, alongside connectivity, which allows for the fastest possible access during tracing since they are loaded as connectivity is loaded. Network attributes that are not stored in-line are still stored in system tables, but they are stored in secondary storage that is dedicated to network attributes.
The reason why there are two different storage mechanisms for network attributes is that there is only a small amount of space available for in-line network attributes. In-line storage should be reserved for attributes that are required for network traversal, like traversability barriers, and must be integer values. Network attributes that are used for summary functions or output conditions won’t benefit as greatly from being stored in-line.
You should also consider how often a network attribute is used before designating it to be stored in-line. Network attributes that are part of your subnetwork definition or are referenced by frequently used named trace configurations are good candidates for storing in-line. Network attributes, like summer or winter configuration, that are only used a few times a month are not as important to store in-line.
An important consideration when identifying network attributes is to remember that they must be validated, written to, and read from the database. The more network attributes you have, the longer it will take to enable/validate your network topology, trace your utility network, and update your subnetwork. The cost of each individual attribute is relatively small, but the costs can quickly add up for networks with many network attributes. You’re better off starting with a relatively small number of network attributes you know you need, then adding additional network attributes over time as you know you need them.
If you identify a field that you want to use as an in-line network attribute, you may want to make some changes to the field to make it more suitable for storage as an in-line network attribute. We’ll discuss some of these considerations in the next section.
Storage
Given that there is such a finite amount of storage for in-line attributes, it’s worth discussing what determines how much size is allocated for an in-line network attribute so you can design the fields backing your network attributes for ideal storage and performance. What follows is a summary of the ArcGIS Help topic for how to calculate the bit size for in line network attributes.
The first limitation for storing an attribute in-line is the data type of the network attribute and its field. While most data types can be used as network attributes, only short integer or long integer fields can be stored in-line. This is done because the network stores a binary representation of the values for the network attribute.
The second limitation is that an in-line network attribute must have a domain associated with it. The values in this domain determine the amount of space allocated for the field in the network index.
The amount of space allocated for the network attribute is equal to the amount of binary storage required to store the largest value in the domain. Because of this it is best that the domain is as compact as possible, with the largest value being as small as possible. If the network attribute and domain are designed for bitwise comparisons, then each value in the domain will represent a power of two (1, 2, 4, etc.). The initial storage size is calculated using the domain specified in the Create Network Attribute tool, but as the network attribute is assigned to different classes it may expand depending on the domains assigned to the fields it is assigned to.
Bit Size | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | … | 20 |
Max Domain Value | 1 | 3 | 7 | 15 | 31 | 63 | 127 | 255 | … | 1,048,575 |
Max Domain Value (nullable) | 0 | 1 | 3 | 7 | 15 | 31 | 63 | 127 | … | 524,287 |
If the fields assigned to the network attribute are allowed to be null, then the network attribute needs additional storage to represent an empty network value. When designing a model’s network attributes, it’s good to consider making the fields used for network attributes non-nullable to save storage space. This is why fields and domains that are assigned to network attributes often have a value of 0 for unknown, because this allows the field to be marked as non-nullable.
Conclusion
Now that you’ve read this article you should have a foundational understanding of how to create and use network attributes in a utility network. You should also be able to understand the benefits and limitations of storing a network attribute in-line and determine how beneficial it is to store a particular network attribute an in-line. With this information you should be able to confidently make changes to your own model, configuring network attributes to meet the needs of your model.
You can learn more about network attributes by reading the Network Attributes topic in ArcGIS Help.
If you have specific questions about how to solve different workflows, please visit us on the ArcGIS Utility Network channel on the Esri Community site. This is an active community with thousands of active members.
