Esri Utility Network – Introducing the Structure Network!

September 13, 2016 — Skye Perry

We kicked off this new series on the Esri Utility Network last month with our post subtitled Esri Utility Network – Data Model 101. I’m excited to say that we had more reader engagement on this one post via our website and Linked In than we have on just about any other post in my 6 years of blogging for SSP! To me this is a clear indicator of the importance of the topic and we’re excited to forge ahead with the blog series. If you didn’t read last month’s post, please check that out first as it covers the basics of domain networks. This month we will dive in a new topic – the structure network model.

Esri Utility Network Data Model

Last month we briefly mentioned that while you may maintain multiple domain networks (ex. electric, gas, and water), you would only ever have a single structure network. The structure network may be a new concept to many utilities because it promotes data that was previously non-networked in the geometric network into network awareness within the utility network. Some examples of structures would include entities like:

  • Structure NetworkPoles
  • Pads
  • Vaults
  • Substations
  • Ducts
  • Trenches
  • Cabinets
  • Pits
  • Stations
  • Casings

The structure network will often contain any data item that you manage that relates to the domain network but is not actually connected to the domain network classes: device, line, or assembly.

Similar to our domain networks, the structure network is made up of several different feature classes including the StructureJunction (point), StructureLine (line), and StructureBoundary (polygon). Each of these feature classes has the same key fields as our domain feature classes including AssetGroup and AssetType. The AssetGroup corresponds to the Esri subtype field and is used to map the feature class type (i.e. pole vs. pad) and the AssetType would be used to model your current geometric network subtypes (i.e. Wood Power Pole, H-Frame, etc.).

So why are we adding structures to the utility network?

The answer lies in the new relationships we can establish to the attached or contained features. The relationships are called associations in the utility network because they differ from traditional geodatabase relationships (covered in more detail next month). While associations can also be applied to domain network feature classes such as devices, assemblies, and lines, we will explore them here with regard to structures. A structure will typically participate in one of two types of associations with the device/assembly features. An association role is configured at the AssetType/AssetGroup level of the model and will be set to either:

  • Containment Association – these structures contain devices and/or other structures. Any structure boundary, line, or junction (defined at the AssetGroup/AssetType level) can be set as a container for other features. An example would be that a substation yard could be defined as a polygon (mapping the fence line) and would act as a container for all the devices and assemblies within the substation. Another example in gas would be that a casing contains a pipe feature (this is an example of linear containment). The model is very flexible and will support containers within containers.
  • Structural Attachment Association – these structures have other devices or assemblies that are attached to them. It should be noted that only structure junctions support attachment. This would be the case where we’d model a pole structure that has a transformer, fuse, or switch attached to it. Another example would be a pad structure with a fuse cabinet or pad mounted transformer attached to it.

It is worth noting that a StructureJunction can also be connected to a StructureLine via implicit (geometric coincidence) connectivity to form a traceable structure network. This is very similar to the geometric network today. An example of this would be ducts connected to vaults to form a connected duct network.

By establishing structures in the network and building the associations into the data, we open up a whole new level of network analysis. A quick example should make this clear. Over the years, SSP has repeatedly built batch applications that create a structure to circuit join table via spatial proximity. This effectively associated our historically non-networked poles, pads, pedestals, etc. with the conductor that they are attached to which allowed for reports to be created. The reason we built this as a batch app was that the spatial nature of the relationship typically made the process very time consuming when performed in real time. Therefore, the batch app would cache the data to enable efficient report generation. This entire custom concept will not be required with the utility network. In the future we will be able to trace a circuit and have the out-of-the-box utility network framework determine which structures are attached to it in real-time. No customization required!

The final question related to structures that I want to address is why there is only a single structure network in any given utility network. The answer is pretty simple. The single structure network will be shared by the multiple domain networks therefore reducing duplicate data maintenance. For example, the same pole structure can have both electric and telecom attachments. If you are a single commodity utility (i.e. only electric), this won’t matter much to you. But if you have multiple commodities, this will provide you the ability to model your structures in a single location without sacrificing any relationships/associations or functionality.


This concludes part two of the utility network series. We covered the new structure network in this post which is a new concept to many of us and we’d encourage you to post questions and/or comments if you have them. We (SSP) monitor the comments feed regularly and also feed them back to our cohorts over on the Esri utility network product team. See you next month!

We Wrote the Book

The Indispensible Guide to ArcGIS Online

Download It for Free

Skye Perry is the CEO for SSP Innovations and has provided technical architecture, development, and management solutions for GIS-centered implementations since 2000. Skye’s roots tie back to Convergent Group, Miner & Miner, and Enspiria Solutions where he has focused on implementing Esri GIS customizations and system integrations. Today Skye is Read more


  • If this is working like I think it is, it is possible to draw your structural network at an absolute placement standard (such as a trench), draw your electric network at a geo-schematic placement standard (let’s say 5′ offsets on 3 cables laying in the same trench), and then link the electric cables to the trench.

    If you need to display the absolute placement of facilities, you show people the structural network. If you need a more easily read connectivity map, you show them the electric network.

    Am I thinking of this correctly?

    • David, you are following correctly. In your example the Trench would be a Structure Line and the Conductors would be Domain Network Lines. The network lines would be set up as content of the structure line (the container). You could definitely visualize it either way – showing the trench and/or the conductors. The real benefit is that you will be able to run a trace on any one of the conductors but have it return the trench in the result set which is pretty darn cool when you want to trace the absolute placement of the trench based on a conductor trace. All based on structural containment!

  • Nice job, again! The structural network shows a mature view of utility plant operations. I do wish Esri had thought about structural attachments across lines and polygons, and not just junctions.

    • Thanks Kurt! I know Esri would be very interested in hearing your thoughts about how structural attachments would be used for lines and polygons. Can you provide some examples for discussion? As a reminder lines, polygons and, point structures can be used with containment associations…

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>