How to use the "electric edge object" table

[mshanaghan]

I am considering different ways to model my electric data, mainly deciding whether to represent conductors spatially or non-spatially.

If you utilize the "electric edge object" table, what does each row in the table represent for you? Do you represent conductors only non-spatially through this table? How do you represent duct banks, conduits, and conductors?

Any info anyone wants to share is appreciated. Thank you.

[JohnAlsup · Accepted solution]

Most electric utilities use one of two graphical representations of conductors, Single Line or Three Line.  They do want to see circuits on a map and be able to locate pad mounted or pole mounted equipment.  However, many electric utilities also want to track the details of each individual conductor.  Either from an asset management perspective or they have mixed conductor types within the same circuit segment and multiple conductors per phase.  This is important information for specific types of engineering studies.  Edge Object or Junction Objects can be easily used to represent these individual conductors.  Personally, I would use junction objects, as there significant unneeded overhead with using edge objects in this way.

Trying to layout a complete circuit using non-spatial would be very challenging for a number of reasons.

[JoaquinMadrid1]

There are many ways to model the elements you refer to and the Esri Electric Foundation already offers ready-made alternatives.

But one important consideration when using non-spatial objects is that, at the present time, Esri Web clients (Web Maps, Field Editor, etc.) do not provide OOTB support to navigating the Feature-to-Object associations. (As an example, the Web pop-up form for a feature does not show you its NSO contents. Your Line pop-up would not show conductor NSOs.) The Java SDK allows you to customize your own forms, though. 

[JohnAlsup]

If you don't use junctionobjects, the system will not automatically set the subnetwork name (supporting subnetwork or supported subnetwork fields).  Also, information in related tables is not included in an export subnetwork.  To use a related class would require a custom tool to assembly the information in to the appropriate place in the json for feeding systems like ADMS or OMS.