Just wondering if anyone has developed a nifty modeling solution to model "spans" between two poles and conductors that exist within that span. In this part of the world, it is called Spans and Bays.
I would imagine this will be a common requirement for all electric UN models. Most Enterprise / Work Management systems, Vegetation control systems etc. work with "spans" rather than electric lines. Work orders etc. are generated for spans and not for lines. SAP also uses "span" as a Functional Location and creates notification or work-order against the span.
The requirement here is GIS user should be able search / locate a span and find associated assets such as poles and electric lines. Or run a trace for a section of the network and identify spans and poles associated.
I have few options in mind to model Spans and Bays with UN.
1. Create StructureLine of AssetGroup OverheadSpan that gemetrically connects to two StructureJunctions of AssetGroup Pole. Also create Containment relationship between OverheadSpan and Electric Lines where OverheadSpan contains one or more ElectricLines. Using Feature Creation Group Template, creation of Poles and Spans and first set of overhead of electric lines can be easily automated. Addition of subsequent electric lines in the span will require user to manually set containment relationship with spans.
Two drawbacks in this model:
2. Use non-spatial StructureJunctionObject and StructureLineObject. StructureJunctionObject with AssetGroup "Bay" will represent "bay" on a pole. StructureJunction->Pole "contains" StructureJunctionObject->Bay. Also create a StructureEdgeObject with AssetGroup "OverheadSpan" that represents spans between two poles and connects to StructureJunctionObject->Bay. Then have a StructureEdgeObject->OverheadSpan contain ElectricLine->OverheadConductor. It still doesn't solve the problem of highlighting Poles when performing electric domain traces. Also, I am not sure if non-spatial objects will work here. All documentation about non-spatial objects alludes that it should only be used for the fiber/comms network.
3. Use a related table for ElecticLine, lets say ElectricLineSpans as a child table for ElectricLine. And have this table auto-populated using Attribute Rule when overhead line connecting two poles is created. But I am concerned about the performance of such auto-population using Attribute Rules and possible race-condition when adding features using group templates or interfacing using applyEdits etc. And still doesn't solve identification of the bay number.
Any suggestions and/or previous experience is much appreciated.
By adding these as features in the utility network class, you are significantly increasing the size of the network index. My first question is, why should the "spans" be in the network index? Are you tracing on them? Do you want the subnetwork names of the subnetworks the span contains?
We did add a new asset group in StructureLine called Aerial Span in the latest electric model. This could be used for this, however, doing so may impact performance of operations like trace and update subnetwork.