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.

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:

• Poles
• 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!