ArcGIS Utility Network Model: Understanding the Data Model
March 31, 2017
by Robert Krisher
Senior Consultant at POWER Engineers
This article was originally published as a LinkedIn Article
As many of you are aware ESRI is releasing a new Utility Network Model for use across all of their platforms and while many are excited about the potential of this new model, it certainly has raised a lot of questions. How will I get my data into the new model? Will I have to change how I model my features in the GIS? Is the new functionality really worth it? Through this series of articles I hope to not only answer all of these questions but to demystify the new utility network model and make a case for all the benefits the new platform will provide.
The only thing more immediate than the data model changes with the new utility network model is the terminology used to describe it. If you’ve attended any of the presentations about the new model you’ve probably heard the terms “Domain Network”, “Asset Group”, and “Asset Type” mentioned but never really had a clear picture of what these things are. All of these terms describe things that you are already familiar with, but because the new data model has re-organized and consolidated a lot of the objects from the previous data model Esri needed a way to describe the new structure. Let me give you an example.
The foundation of the new model is based on the concept of “Domain Networks”. Simply put, each domain network represents a schema that allows you to model the objects and behaviors for a particular style of network. Common examples of this include electric distribution networks, gas distribution networks, or even water networks. In the current data model this organization is achieved creating a utility network that references all of the feature classes in your model. Going forward this is modeled by creating what is known as a Domain Network. Each domain network consists of a utility network with a predetermined set of classes. Once you have built the domain networks required by your model you can then extend the classes and subtypes within each domain network to support your specific model and business needs.
There are three main benefits of the new model. The first benefit of this model is that it streamlines the data model. There is less room for variation in the model so that means it’s much easier for ESRI to focus their development and support efforts for utilities on the new model. The second benefit is with performance. By reducing the number of feature classes and tables in the database you are able to cut down on the number queries made to the database or web server for every operation being performed.
Because domain networks used a fixed number of feature classes Esri has provided a robust set of configurations and classifications that can be used to extend the base model to support each customer’s needs. This next section focuses on the terms Esri uses to describe how different objects are classified in a domain network.
Domain Network Classes
The first classification of an object in the utility model is the role in the domain network it belongs to. Each of these roles is represented by a single feature class that carries the name of the domain network along with the role of the feature. If you contrast this with the legacy utility network model where objects were separated into fine-grained classes based off of the objects they represent you will see that the new model is built around using a more consolidated and streamlined set of feature classes. In the new network model there are five different types of classes: device, device assembly, junction, line, and subnetwork.
Here are some of our previous object classes:
Here is the complete list of our new object classes:
All of the classes in the electric dataset have now been consolidated into two different domain networks: one for Electric Distribution networks and one for Structure networks. The structure network has a slightly different set of classes associated with it, and if you want to know why you’ll need to read one of my later article where I discuss structure networks in depth.
Even though all of the classes that were previously modeled have all been consolidated into a smaller number of tables some mechanism is still required to maintain the identity of each object in order to properly model it in our network. This is where Asset Groups and Asset Types come into play. In the new model each of these new domain network classes has a subtype field called Asset Group that it used to indicate the type of feature. In most cases these Asset Groups will match the classes used in the original model. Here’s an example of some of the Asset Groups (Subtypes) you can find on Electric Distribution Device:
Given that each domain network class uses the Asset Group subtype field to track the table that each object came from there still needs to be a mechanism for tracking the original subtype of the object, and that is precisely what Asset Type is used for. Each Asset Group has its own unique domain of Asset Types that allow you to further refine the classification of the asset. Here’s an example of the subtypes on the legacy Transformer Bank class:
And each asset group gets its own set of asset types. The following screenshot shows the asset type domain associated with the transformer asset group:
How much consolidation occurs in the new data model? One way of consolidating the legacy data model into the new utility model is to turn each of your existing network classes into an asset group within the appropriate domain class, then turn the subtypes that were assigned to that class into asset types for that asset group. The following table illustrates the results of this process:
This consolidation process turned the 20 classes with 72 subtypes in the legacy electric dataset into five different domain network classes with a grand total of 20 asset groups (one for each legacy class). Each of the 72 subtypes from the legacy model would then become an asset type domain that would be assigned to the asset group for the corresponding class. This approach would allow for a project that would minimize that amount of friction for implementation as it would allow for a more seamless transition into the new application with minimal impacts to the look and feel of the application. While this example intentionally leaves out the assembly, boundary, and subnet classes the methods for handling those classes will be discussed in later articles which deal with containment, structural attachment, and tiered networks.
So why did ESRI decide to consolidate all of the classes in the network? The answer is simple, performance. Not only does this cut down on the number of layers in your map documents but it greatly simplifies the ability to search / report on data because all of your features are sharing a common schema. One of the drawbacks of this approach is that anything that is specific to a particular type of asset needs to be represented in a related table, a practice already common to many electric data models. While this approach presents its own set of challenges with respect to labeling and attribute maintenance, if you read through this series I will describe a number of new features included in ArcGIS Pro that can overcome this challenge without any need to customize the application. The next article in this series will focus on using ArcGIS Pro to create map products and symbology in the new data model that is optimized for the best performance and user experience.
About the Author:
Robert is a Senior Consultant in POWER’s Geospatial and Asset Management group with over 10 years of industry experience. Robert excels at pushing the boundaries of what is possible with GIS and related technologies at utilities, often by repurposing proven technologies and methods in clever ways. As an active member of many early access programs across the industry and author of more than a dozen published articles, Robert is a recognized expert with Esri’s latest technology including ArcGIS Pro and the new Utility Network. He loves finding innovative solutions to complex challenges and sharing his insights with the GIS community. If you have any questions or comments for Robert, you can contact him at email@example.com.