Esri Utility Network – Data Model 101

August 9, 2016 — Skye Perry

As detailed by Ryan Potts last month, the Esri Utility Network was one of the hottest topics at the Esri UC this year. We’ve been participating in the Alpha program for this new and exciting product and while we can’t disclose any details about the software (the Beta will be out for customers late this year), we have been cleared to start educating our customers on the data model.

Understanding the data model will be foundational in beginning to use the new software (at Beta or beyond) and in understanding how your current geometric networks will eventually be migrated into the utility network. To guide you through this important topic, this will be the first installment in a new series detailing all the key areas of the utility network data model. Please feel free to ask questions via the comments or via contacting us directly. If you stick with us through this series, you should have the required skills to understand the utility network as soon as it’s released into Beta.

In this post, I’ll start with an overview of domain networks within the new data model.

Esri Utility Network Data Model

The above diagram is one you will want to get familiar with as it contains all the key terms we will use to discuss the utility network. First off, recognize that the new network still runs in an Esri geodatabase and is still made up of feature classes. However, this is also the first area of significant difference. Whereas the geometric networks we utilize for electric, gas, and water all contain different feature classes (i.e. pole vs. conductor vs. switch), the utility network will contain a distinct set of feature classes for each domain where the domains are defined as electric, gas, water, etc. Electric could also be broken down further into a distribution electric domain network and transmission electric domain network or they could be modeled as different tiers within the same domain network (stay tuned, tiers will be covered next month). Don’t confuse the utility network domain networks with field domains which are our traditional field picklists in the GDB.

Domain NetworkThese distinct feature classes include the Device, Line, Junction, Assembly, and SubnetLine. If you manage more than one network in your geodatabase today, you will actually create multiple different domain networks within the same utility network. For example, our good friends over at Memphis Light Gas & Water will end up having at least three domain networks – electric, gas, and water – created within their single utility network. Two key benefits to this approach are that you will be able to enable tracing across different domain networks (ex. electricity feeding a water pump) AND that multiple domain networks will share a single structure network (covered in more detail next month).

To hammer the domain network concept home, if I create a gas domain network named “GasNet” then I will end up with five feature classes including:

  • GasNetAssembly
  • GasNetDevice
  • GasNetJunction
  • GasNetLine
  • GasNetSubnetLine

So where will all of your feature classes from your geometric network go?

Generally speaking they will be mapped into a combination of the Assembly, Device, Junction, and Line feature classes. Each of these feature classes is then further subdivided by two key fields: AssetGroup and AssetType. The AssetGroup utilizes the Esri subtype behind the scenes and will generally be used to map your current geometric network feature classes. For example the SwitchBank and TransformerBank point feature classes in the geometric network today will both be mapped into the Assembly feature class and will have their AssetGroup (subtype) set to SwitchBank and TransformerBank respectively.

The next question is where all of your current geometric network subtypes go now that subtype is being used to track the AssetGroup. The answer is that you will now define these as AssetTypes. So my TransformerBank AssetGroup will be further broken down into AssetTypes of SinglePhaseOH, SinglePhaseUG, ThreePhaseOH, ThreePhaseUG, and so on. My WaterMain AssetGroup may be broken down into AssetTypes by material such as BareSteel, CastIron, Plastic, etc.

The next question you are likely to ask is why are all of these geometric network feature classes being consolidated into a single utility network feature class?

There are a couple of key reasons. First, by tightly controlling the list of feature classes that participate in the utility network, Esri can optimize the way that the logical network (the network topology) is created and cached. This speeds up network operations and provides for consistency at the macro level for different customers and different domain networks. And second, the visualization of the network will benefit because there will be less calls to the database (i.e. by condensing multiple tables into four tables, we need less distinct queries executing against the geodatabase to render the feature data).

This design does have some important implications for you to understand. You will not be able to add additional feature classes to the network. You will, however, be able to add additional AssetGroups and AssetTypes to the existing feature classes within the network allowing you to map your existing classes into the utility network. It will be the same data just organized slightly differently. Further you will be able to create individual feature (map) layers within your map document for each AssetGroup (i.e. individual layers for transformer vs. switch, etc.) just as you do now. So the end result is pretty close to how you view your geometric network today.

To start thinking about your model, here are some guidelines around moving to utility network (UN) from your geometric network (GN):

Line

Description: Contains all linear elements of the network regardless of type, size, etc.

Migration Thoughts: You will map all of your simple and complex edges from the GN into this class and will subdivide them by AssetGroup and AssetType. Therefore both services and mains will be mapped to Line in gas/water and both primary and secondary will be mapped to Line in electric.

Assembly

Description: Generally used for container/aggregation features that represent multiple devices/assets at a single location (ex. TransformerBank may represent 3 transformer devices or a RegulatorStation may represent multiple regulators).

Migration Thoughts: You have the option to map your bank classes from the GN into this feature class. If no bank is present in the GN, then the source GN point class will likely be mapped directly to the Device feature class and not the Assembly. Assemblies in the UN will not be connected directly to lines but will contain other Devices that ARE connected to lines. Please note that this is not necessarily our final recommendation as we are still reviewing different migration patterns for banked GN features but will give you some thoughts on how it could work.

Device

Description: Will be used to model the devices that maintain connectivity to the lines in the network. There are different modeling options within the UN for the Device class. It could be mapped to the GN bank features and you could continue to model the individual devices as related (non-spatial) units but the general recommended approach is to move the units into this class so that distinct connectivity can be modeled to each individual device.

Migration Thoughts: For water and gas this will often be mapped directly to the point features within the GN except in the case of reg stations or other devices where related unit/asset records could be promoted to device features. For electric, your unit records should most likely be promoted to features within this feature class associated with the bank feature that is migrated into the Assembly class. We’ll talk more about how we’ll achieve this concept of promotion in future posts.

Junction

Description: This class is used for more generic point-based connectivity. It will always include a ConnectionPoint AssetGroup but should also contain other non-device points where connectivity needs to be established.

Migration Thoughts: In electric you will likely map any joints, splices, dead ends, or open points (non-switches) to this class. For gas and water, you will use this for non-operable connection points such as couplings, elbows, caps, tee’s, etc. (think of GN non-controllable fittings).

SubnetLine

Description: This class will be used to model a single linear feature per each sub-network in the future UN. For electric this will generally be circuits (at various voltage levels) and for water and gas this will be pressure systems, isolation zones, etc. These will be derived line features from the UN and not something you will migrate into. To be extra clear, this class will be completely system maintained. Users will never edit this data. The features in this class will be solely maintained by the application.

—-

To wrap up this month’s post, I am hopeful that this information gets you to start thinking about the utility network and how your data will be mapped into it in the future. We will continue to review each area of the network in the coming months with the goal of giving you all the intel you will need to jump right in when time comes. Once again, if you have thoughts or questions, fire away!

We Wrote the Book

The Indispensible Guide to ArcGIS Online

Download It for Free
Chairman of the Board

21 comments

  • Andrew McColgan says:

    Skye,
    Quick question: Will the utility network feature classes be in addition to the feature classes that are currently being edited, or will all of the current feature classes be folded into the 3-4 UN classes? Just curious how it will affect the editors. Great article, and Thanks!!
    -Andrew

    • Hi Andrew, the existing geometric network classes will be migrated into the new 4 utility network classes (per each domain). The new UN classes will replace the existing GN classes and will not be added in addition to the existing classes. The editors will then maintain their network data directly (and solely) within the new UN classes. Hope that clarifies.

      • Thomas Brown says:

        Further clarification… a domain network’s data model may only consist of the four classes devices, junctions, lines and assembly (excluding the 5th class subnetline), but how these classes are presented to users is accomplished by layers in the application. When authoring a map, one will have layers representing each “assettgroup” from each domain network class – assettgroup is the attribute name which is a geodatabase subtype. And each layer (such as a transformer or switch) can use the unique value render with the assettype attribute.

        In summary, end users will continue working with the same collection of layers they’ve become accustomed to in ArcMap – without needing to understand how the content is managed and persisted in the data model/database.

        Thomas Brown
        Esri

  • Abdelrahman Melegy says:

    Thanks for this informative post, as some who is working for one of ESRI’s distributors in my region I’m certainly glad to learn about this. GIS users here mostly prefer to stick to their old routine instead of shifting to something new but if the difference in the performance is huge I’m sure a lot of users will reconsider. I’m following up with this series and I’m going to wait for your next post, have a good one!

  • How might the Assembly Class be used for butteryfly valves? I’m thinking in my instance of how we are GPS’ing our valve (lids) to achieve better main line positional accuracy, and this results in us having to draw in an offset between the main and the butterfly valve when it has been located with centimeter accuracy. It can kind of be thought of as a remote “key” attached to the actual valve inline with the main.

    • Hi Joe, this is an interesting question. You wouldn’t actually have to use the assembly class in this case unless it tuly made sense to have a container entity in the case of the butterfly valve. However, when it comes to connectivity in the new network, you will not need to have geometric coincidence between the valve and the main. Therefore, you could actually model the butterfly valve as a “device” instead of an assembly and could still offset it from the main. Then you could model a “junction” at the ends of each of the gas mains and establish connectivity from each junction to the valve device. We’re jumping ahead a bit here and will cover more of these concepts in coming months so stay tuned!

  • Great post Skye – I feel like I have learned more in the last 5 minutes reading this than I have in the last 18 months of asking questions about what this is going to look like.

    My chief question still remains though – will there be tools provided to move proposed features buried down in Designer versions into the new feature classes and set the “lifecycle attribute” to “proposed”? We have some code that does much of that version combing already…but it would be nice to have a tool to do it.

    • Thanks Dave, glad you liked the post!

      I’m sure there will be varied solutions out there but Esri has challenged SSP to ensure our All Edits State 0 projectware will work for exactly this purpose. We have already performed several projects recently where we have recreated design versions in a brand new GDB with db name changes, schema changes, etc. Versioning still remains in the future GDB where the utility network exists (though it’s been optimized) and your theory is correct. We will need to migrate the current design versions into the new model within new versions while setting the lifecycle attribubte. Our All Edits State 0 (AES0) tool should work perfectly for this process based on how we use it today. Here are a couple links if you are interested in reading more on AES0…

      Migrating to a New GDB with Versions Intact

      The Big State 0 Theory

  • Skye,
    Thank you for the very clear explanation. My state of mind about the new UN is moving from nervous fear to nervous excitement. It really tied together all the information I‘ve been hearing over the last couple years. I’m looking forward to the upcoming articles.

    SubnetLine – Is this populated from attributes on the other UN Domain classes (i.e. Voltage)? Can you have multiple SubnetLine classes in the same network (i.e. circuit, voltage, fault zone)?

    • Hi Duane, thanks for chiming in!

      The SubnetLine features are tied to a tier within the network (covered in future months) and will be created/maintained by the UN software (we can’t talk much about that yet). Electric tiers will often be based on voltage levels and a set of features can participate in more than one subnetwork (i.e. a secondary network would be a subset of the medium voltage/primary network). Therefore you will have multiple subnetline features at the same location. This may not totally answer your question but I think this will become much clearer once we start posting on the beta software down the road. Hopefully this helps for now…

  • Skye, Thanks for the article. Will Network Analyst and Editing tools be available in ArcMap, or only available in ArcGIS Pro? Thank you.

    • Hi Kevin – the utility network functionality will not be available in ArcMap. It should be noted that Esri is developing most of the product as services-based which will be exposed via ArcGIS Server & a portal (ArcGIS Online or Portal for ArcGIS). ArcGIS Pro will then consume the services to allow for desktop editing in Pro. But this will also allow other partners to develop web and ArcGIS Runtime applications that ALSO consume the same UN services. So know that this is coming in the future… The short answer to your question though is that all of the functionality tied to the data model I am describing will absolutely be available in ArcGIS Pro and not ArcMap.

  • James Stevens says:

    This is great stuff, I concur this answers some questions I’ve been asking for months as well. I’ll be following this very closely as we move forward with our future roadmap planning.

  • Konstantin Malakhanov says:

    Thank you for detailed information. It helps a lot!

    What I don’t quite understand, what happens with all attributes we have now at the features of geometry networks. Assume we model the pipelines with three different feature classes with different sets of attributes. Now all of three feature classes will be moved into the Line feature class. Will the Line feature class have to combine all the attributes of three original feature classes?
    Thank you.

    • Hi Konstantin, this is a great question we haven’t really addressed. Your assumption is correct though. We would need to combine the attributes of the individual feature classes in the geometric network into the single linear class in the utility network. We would then hide attributes at the feature layer level in ArcGIS Pro that don’t apply to the specific asset group / asset type. The end representation (attribute wise) will be very similar to what we see today in ArcMap with the geometric network.

  • Chris Sambol says:

    Hello, I have read all the great information about what is coming forward and firstly wanted to thank you for providing such great insight into what is coming. I have a question about security/editing, we have different users responsible for editing Sewer Infrastructure vs. Water Infrastructure. With everything now being combined, is it even possible to separate out user specific security within the new model. Thanks in advance.

    • Thanks for your question Chris. The short answer is yes, you will still be able to separate out the user specific security. To accomplish this for your organization, we’d recommend creating two different domain networks for sewer and water (they can still refererence/connect each other if needed). Then you will publish ArcGIS Server services for each domain network separately. This will allow you to maintain control over the respective domain networks at a user basis via your portal/ArcGIS Server security. So it’s a bit different than today since this is all moving to be web service oriented but you’ll have the same level of security controls available.

  • If I want to migrate relationship class from present geometric network to utility network how can we do this ?

    • Skye Perry says:

      You would migrate the primary and foreign keys and then recreate the relationship class in the destination UN geodatabase. Relationship classes still exist in the new geodatabase… no major change there.

What do you think?

Leave a comment, and share your thoughts

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>


This site uses Akismet to reduce spam. Learn how your comment data is processed.