In a previous post on GIS utility data modeling we discussed electric conductors. This post will address the related topic of modeling neutral wires.
While three-phase power can be delivered in either a Wye or Delta configuration, the majority of most North American distribution systems are Wye – differentiated from a Delta configuration by the presence of a grounded neutral wire. From a sampling of our customers one mid-western company has 98.7% Wye, a rural northeastern company has 89.8%, an urban Midwest company has nearly all of its system, and a western company has 99.8% – which is nearly all, too.
So, the question of the day is, how do we model all these neutral wires?
In our experience, overheard neutral wires are represented in any of three ways in ArcGIS Electric database models, as follows:
- One approach provides for the ability to store “NeutralSize” and “NeutralType” fields as properties of the primary overhead line feature. Seems a little inelegant or imprecise at first. The neutral is a wire like the other wires strung on the pole, why not store its properties in the ConductorInfo table with the other wires? Well, one thing it does do is describe the case of a “common neutral” – where one neutral wire serves two distinct circuits on the same pole line. The approach lets us know there’s a neutral with the span and lets us know its properties.
If we put the neutral in ConductorInfo, then we’d have to have a many-to-many relationship to accurately associate the neutral to a primary span. Or otherwise we could create a separate table just for neutral wires and have a one-to-many relationship from that table to the primary span. Given those alternatives, putting properties of the neutral on the overhead primary span itself look pretty reasonable.
- An alternate approach is to say “to heck with the common neutral problem.” Putting neutral properties directly on the primary makes it *really* hard to query – and gives an inaccurate count at that. Given that both primaries on the pole line will report a neutral, it’s almost impossible to know how many neutral wires there are. So this method puts the neutral wire in ConductorInfo, relates it to a span (yes, only one span if there are multiple on the pole line) and gives it a phase code of  to indicate it’s a neutral.
- Finally, we have to be aware of the case of overhead spans containing only a neutral and no phase wire. Unusual yes, but it happens. For this case we’ve created a “Neutral Only” subtype with PhaseDesignation value of  Neutral and with a value  Non-Traceable for the Feeder Manager Non-Traceable field (FdrMgrNonTraceable). Both of these conventions support graphic representation of the line and prevent it from be traced by Feeder Manager tracing.
|For an accurate accounting you need to take care of conditions such as the common neutral – but this data structure makes an accurate accounting possible.|
|While in some ways it might be tempting to create a separate feature class of neutral-only wire for this purpose, it’s been found more convenient to change properties of the line if phase wires are added or removed than to delete a feature from one class and add a feature to another in the event, say, phase wire(s) are added to a previously neutral-only wire changing it to, say, an energized “Three-phase Overhead” subtype.|
While what we’ve discussed above is in terms of primary conductor the same would apply to secondary. For example, the conventions we described for our third case – neutral-only wire — will prevent cases where a Feeder Manager trace might connect two different feeders via a connected neutral – as illustrated below.
So, there are some options for neutral wire modeling to chew on next time you’re building, upgrading or re-designing your electric distribution database model.