ArcFM Pole-Conductor Relationships

The standard ArcGIS Electric data model and ArcFM Multispeak model define clearly how conductors and devices are connected in the geometric network.  They also define clearly how devices are related to the structures that support them.  However, the prescription for associating conductors with the structures that support them is left a little fuzzy.

This is not really a bad thing.  There are a variety of ways to tackle the task, and data requirements vary considerably between approaches.  In this post we’ll describe our experience with several of these approaches and offer some pros and cons along the way.

Our Working Requirement(s)

For the purpose of this post we’re going to assume there is a single fundamental business requirement to be met.   That is, return the set of poles supporting the overhead portion of a given named feeder for the purpose of directing a tree trimming crew or a pole inspection crew.  We’ll suppose that feeder segments will have been selected either by a trace or attribute query and that the selection set of segments will be used to select our poles.

Approach 1: Spatial Proximity

Many would argue that the most straightforward approach to the problem is to use the GIS as its intended to be used.  Specifically, perform a spatial search using a buffered polygon created around the selected segment geometries.  Below is an example.

Of course, the accuracy of this approach depends upon your mapping conventions and the size of the buffer.   If, for example, your standard is to ensure that overhead lines are offset no more than 20 feet from the pole line and you buffer 25 feet on either side of the segment, then you should have high confidence you’ll get all the poles.   You may also may well get some poles that fall in the buffer but don’t actually support the feeder in question.

Pros:

• No database relationships are required and none need to be built or maintained.
• No reliance on relationships that might be inaccurate or incomplete.
• No custom software is fully required, though some of the steps could be automated if the task is to be done frequently.

Cons:

• To ensure all poles along a feeder are obtained it’s likely that the process will include more poles than actually support the feeder.

Approach 2: Simple Pole-Conductor Relationship

There’s no saying you can’t create a relationship between poles and conductors.  It’s just that a simple one won’t do.  A pole can support multiple conductors and any conductor spans multiple poles.  This necessitates a many-to-many relationship.   A thing which is hard for any normal user to maintain using simply out-of-the box technology.  Let’s illustrate.

However, once you’ve got this relationship in place, and you’re confident its correct, then your query for poles supporting the circuit are quite straightforward.  As illustrated below, given your selected set of conductors all you need to do is open the table editor and navigate to the related poles.  They’ll be listed and selected.  Of course you put the steps in a geo-processing tool or an add-in if it’s something you do frequently – or if you have users who expect a minimum number of steps to accomplish any task.

Pros:

• If your data is right, you can be assured of obtain all the poles that support the overhead portion of your feeder – and only the poles that support the feeder.

Cons:

• Many-to-many relationships can be a challenge to maintain with out-of-the box software.

Approach 3: Full Structure Relationships

If the many-to-many pole-to-conductor relationship provides the ability to return (with correct data) a precise answer to the “which poles support this feeder?” question, then adding classes for a “structure location” and a “conductor node” and establishing relationships between them and with poles, conductors and devices can give us about as much information about “what supports what?” as one could ask for.   Let’s start by defining some terms:

• Structure location: This is a location on the surface of the earth and doesn’t by itself represent any piece of equipment. If you’re accustomed to “Enterprise Asset Management” system concepts, this might be considered an asset “location.” Colloquially, you might call it a “pole hole.”
• Conductor node: This is an end point of a conductor, or more specifically, where the conductor span is connected to the support structure. On a pole in actuality it might represent the insulator on the cross arm or other framing hardware. Importantly, this is a feature in the geometric network. When we trace the feeder we get, among many other things, a selected set of conductor nodes.

Further, the conductor node, as well as the pole class and any device classes will have a foreign key that links them to the StructureNode class.   Relationships will look generally like this:

So, given that, how does this work?  Interestingly, the StructureLocation class in ArcFM terms now becomes the “STRUCTURE.”  It  is the class that is assigned the STRUCTURE model name and to which relationships will be built when features like poles, conductor nodes, and devices on create or update if the ArcFM Structure Relate AutoUpdater is assigned.

What’s it look like?  Well, per the screen shot below, once you’ve got the structure location you’ve got everything.

So, finally, how does this help meet our stated requirement of finding poles supporting a selected feeder?  Here are the steps:

• From our traced feeder we have a selected set of conductor nodes connected to feeder segments.
• From the selected set of conductor nodes, select related structure locations.
• From the selected set of structure locations, select the poles.

Yes, it does include an extra step to meet this specific requirement, but this model can be used to answer just about any question about what is supported by what.  And as a bonus, you can use the ArcFM Structure Relate AutoUpdater to do most of the maintenance work.

Pros:

• Like approach 2, if your data is correct you can be assured of getting just the set of poles you want.
• The model supports answering many more questions about “supported-by” relationships.
• Use of the ArcFM Structure Relate AU can automate much of the relationship maintenance.

Cons:

• The model is complex, and requires understanding by map maintenance users to ensure its correct.

Summary

So there you have it.  Three viable approaches to associate conductors to poles.  From basically no modeled association to a fairly detailed one.  No wonder the standard models leave the choice up to the implementer.