topic Conduit Configuration vs Circuit/Feeder Maps in ArcGIS Utility Network Questions

Conduit Configuration vs Circuit/Feeder Maps

Joshua_Moreno — Wed, 04 Feb 2026 19:01:47 GMT

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!

Re: Conduit Configuration vs Circuit/Feeder Maps

gis_KIWI4 — Wed, 04 Feb 2026 19:58:42 GMT

@Joshua_Moreno - When we went live we took a simplistic approach to recording conduits. Each conduit is a line on the map and the cables are associated to the conduits via containment association. 2 reasons why we did this - ease of updating and lack of information from the field (which duct in the duct bank, etc)

We have an improvement roadmap. One way we would consider this using Trench/Duct Bank (Structure Line) and the adding Conduits as non-spatial objects (Structure Line Objects) and then create association between the Conduits and cables.

There are a few considerations here if you wish to use the same method.

-To what level do you want to model this. Do you want to capture each transition? How to balance this with user experience and usability.
-The non-spatial objects don't have a "shape" so you will have to use the duct bank/trench object to infer the length when trying to answer questions like how many kms of conduit in feeder X or region Y.
-Use of attribute rules to enforce data integrity - a cable cannot be associated to multiple conduits within the same duct bank/trench.

Re: Conduit Configuration vs Circuit/Feeder Maps

Joshua_Moreno — Wed, 04 Feb 2026 20:10:37 GMT

Hmm, this is interesting and possibly the way we should approach it too. We were thinking of simply add an attribute field to show the value of conduits and size of conduits on the circuit but we have conduit digitized from CAD already in our structure lines.

Do you think I should change this conduit into duct bank structure lines and create non-spatial conduits per configuration, say 4 - 5 inch conduit associated to the line based on our as built plans then associate each circuit to the non-spatial conduits?

Re: Conduit Configuration vs Circuit/Feeder Maps

gis_KIWI4 — Wed, 04 Feb 2026 20:30:47 GMT

I think it just comes down to the business value it adds. We ended up agreeing just seeing the conduits on the map is good enough to go live. Adding the attributes is nice and simple way of doing things but you still don't get to establish those relationships between individual cables and conduits.

Part of the thinking was that if you had clear associations between the duct bank -> conduits -> Cables we could create cross section diagram using this. An internal world if you will.

I would definitely suggest tabling the above idea with the team/client. While it can feel complicated to edit and maintain I think think being able to model circuits and structures together adds huge value but it needs to be weighed against other priorities.

Re: Conduit Configuration vs Circuit/Feeder Maps

Joshua_Moreno — Wed, 04 Feb 2026 22:25:01 GMT

Would you have to add the association rule to allow for conduits to be associated with the duct bank/trenches? Testing this out at the moment with how the rules and connectivity work to see if this would be a possibility our team wants to take in doing so. I'd essentially like to be able to have a single line of duct bank (structure line) with non-spatial conduit objects representing the actual count of conduits within the duct bank line. Then associate the existing conductor lines to the conduits in which they occupy. Example below, do you know of or is your team looking to do something similar? I'd like to keep everything within the UN and not purchase ArcFM unless we really need to.

I've been looking into ArcFM Conduit Manager and I really like their capability of being able to associate conduits to their respective duct position within a manhole/vault which is what I am looking for.

Re: Conduit Configuration vs Circuit/Feeder Maps

gis_KIWI4 — Wed, 04 Feb 2026 23:27:08 GMT

@Joshua_Moreno - Yes you would have to add rules and create association roles.

I'd essentially like to be able to have a single line of duct bank (structure line) with non-spatial conduit objects representing the actual count of conduits within the duct bank line. Then associate the existing conductor lines to the conduits in which they occupy. Example below, do you know of or is your team looking to do something similar?

You can definitely do the above in UN but ArcFM goes one step beyond and express this information better visually. It's (possibly) using the connectivity and association data to create this representation.

You should be able to drill down from Manhole -> Duct bank -> Conduit -> Conductor possibly even show that in the pop-up. But if you need a visual like the one above you will need ArcFM or need to develop a custom tool/widget.

I have a POC we did to demo this capability within the business, I will see if I can dig it up.

Re: Conduit Configuration vs Circuit/Feeder Maps

RobertKrisher — Thu, 05 Feb 2026 14:14:09 GMT

Great discussion here, and I agree with @gis_KIWI4 . Have some initial discussions, but table making any changes until you've had a chance to use the system for 6 months. Once you've had a chance to flush out all the items you want to add/improve in your model, you can then come up with a plan for a) how to model/configure it and b) how to change the business processes to ensure that the GIS is getting enough information to create and maintain this information.

If you want to get to the level of detail that is required here you will need to start looking at very detailed vault/conduit drawings to get the information on the GIS. Does your organization have this information? Is it all accurate and actively maintained every time something changes? How will reviewing this information impact your workload, will you need to hire another mapper to keep up with demand? You will also need to ensure that every time a cable is pulled or replaced (or new construction happens) that the vault/conduit drawings AND the GIS get updated.

Re: Conduit Configuration vs Circuit/Feeder Maps

Joshua_Moreno — Thu, 05 Feb 2026 16:28:50 GMT

Currently we plan to go through all the manholes and vaults and get internal images of them to start mapping out the current configurations of them. Although, I do believe the goal is to keep these up to date especially with spare conduits that will allow for expansion of our conductors into new buildings or areas.

I do also agree that this has been a great discussion and made me take a few steps back to think more big picture in our goals with creating detailed structures and anything else. Do appreciate the feedback from you both as this has been very insightful. Thank you!

Re: Conduit Configuration vs Circuit/Feeder Maps

Joshua_Moreno — Thu, 05 Feb 2026 19:27:10 GMT

Hi again Kiwi! I'm trying to play around with this layout of using non-spatial objects for conduit or ducts but running into a few issues. First mainly being that the supported subnetwork name is not being populated, am I missing something? I have my conductors within the edge object that is contained within the actual duct bank and has connectivity to the duct knockout. I assumed after containing the conductors within the edge object and running update subnetwork, that the supported subnetwork would have been populated but no luck. Any help here would be appreciated!

Re: Conduit Configuration vs Circuit/Feeder Maps

PierreloupDucroix — Thu, 05 Feb 2026 21:27:08 GMT

Hello,

We have opted for a different approach to managing conduits and pipes:

Duct banks are spatially modeled using a simple polygon to define their footprint.

Next, we modeled cross-sections with boundaries and structure points. The first element corresponds to the location of the cross-section on the map; this point contains a structural boundary representing a duct bank, which in turn contains one or more conduits in cross-section. Each conduit in cross-section may contain a cable.

Attribute rules and feature templates help maintain everything consistent. Furthermore, a dedicated tool allows us to determine the upstream and downstream equipment for each cable and displays this information on a label, so field personnel know which protective equipment to use when working on a manhole.

I suppose the "right approach" is to consider the usefulness of the modeling and first ask yourself what you need :

- Calculating ground footprint for tax purposes
- Managing field operations
- Calculating conduit lengths
- Understanding conduit occupancy rates

Hope this can help

Re: Conduit Configuration vs Circuit/Feeder Maps

Joshua_Moreno — Thu, 05 Feb 2026 21:49:36 GMT

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?

Re: Conduit Configuration vs Circuit/Feeder Maps

PierreloupDucroix — Thu, 05 Feb 2026 22:17:54 GMT

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.

Re: Conduit Configuration vs Circuit/Feeder Maps

Joshua_Moreno — Thu, 05 Feb 2026 22:31:20 GMT

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!

Re: Conduit Configuration vs Circuit/Feeder Maps

DamienPyne — Fri, 06 Feb 2026 00:30:21 GMT

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.

Re: Conduit Configuration vs Circuit/Feeder Maps

gis_KIWI4 — Sun, 08 Feb 2026 20:41:38 GMT

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.