Conduit Configuration vs Circuit/Feeder Maps

[Joshua_Moreno]

Hello, needing some help on how to go about a requirement for the team I created the UN for. We started from scratch and digitized a circuit/feeder map as accurately as we could to represent the connectivity between devices/structures.

Now, our team would like us to create a much more accurate representation of our underground conduit and the configurations within manholes/vaults and the number of runs of conduit. 

In order to represent this to our team, what should I rely on? Associating the circuits to the conduits? Separate views for conduit vs circuits in ExB? Not too sure how to go about this, we have a goal to use this for both reference and operations so accuracy is important to the team. How have those of you who utilize the UN for field operations gone about this?

Thank you!

[Joshua_Moreno]

Yeah, our main purpose of this is managing field operation more than anything. Being able to understand what is underground, where new cable can be inserted, and overall having a reference of the as builts instead prior to going out into the field.

Question for you Pierre, I'm trying to set up something similar in which I have a simple polygon duct bank that contains structure edge objects (conduit), that contains my conductors and is connected to the knockout points in a vault/manhole. I am having trouble with finding my flaw in connectivity here, I would like the supported subnetwork name to calculate in the structures but it is not. What else besides the conductors to I need to associate to this?

[PierreloupDucroix]

I assume the subnet name should be populated in the structure network if you enabled the "Update Structure Network Containers" option in the subnet definition.

My system doesn't use the object tables; everything is spatial. So I'm not certain about this, but it should work the same way with non-spatial objects.

Be careful with this option, as it can negatively impact subnet calculation/update time. Furthermore, you will have multiple subnet names in the same attribute of your containers (for example, SUBNAME1::SUBNAME2::SUBNAME3...), which can make them difficult to read.

[Joshua_Moreno]

I have that option selected in my subnetwork definition but no luck. Will troubleshoot further but thank you for the advice on the structure objects, might have to parse it out using arcade to clear things up.

Thank you for this information, as been very helpful!

[gis_KIWI4]

The only other thing I might check there is if the "Include Structures" and "Include Containers" options are set. They are unchecked by default. 

I agree with @PierreloupDucroix  - it should be the same behavior for spatial and non-spatial objects. 

[DamienPyne]

We came from 2 different companies with 2 different levels of granularity and maturity.  One with minimal detail (a line for the conduit, and arrangement but not maintained, and missing relationships from the conduit to the trench and to the cable), and the other with a rich dataset of maintained cross section detail.

We also took advantage to 3D enable our utility network.  Our end state is the trench modelled at z=0, and conduits and cables at depth (assumed at standard depths for migration, continual improvement through integrated design to correct over time).  For the source data with minimal associations we utilised the unknown conduit as a holding feature.

It seems like a similar model to what @PierreloupDucroix mentioned.