nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Trace - Barriers are not honored by the Trace Tool

GIS_kiwi4

Hi Team,

Wondering if anyone has faced this before.
We have a Utility network service running but the trace does not seem to be honoring the barrier conditions.

The use case is simple I want the trace to stop in 2 scenarios - Switch Status = Open OR Feature is an End-Point feature. Let's ignore the End Point for now and look at the Open Switch.

This is what my Trace parameters look like -

(I have also tried changing "Open" to 1, as that's the number in the domain but no luck)

Result -

I would have expected it to stop at the switch.
Anything I might be missing here?

Thanks in advance 🙂

PS - I ran into this issue when creating subnetworks. Because subnetworks don't stop at these features, subnetworks with different subnetwork names overlap and the system doesn't like it. Updating the subnetwork definition with these conditions did not work so I using the Trace tool to troubleshoot.

Find more posts tagged with

Accepted answers

RobertKrisher

@gis_KIWI4 yep, that's the problem. A device with terminals will only act as a barrier for connectivity between the terminals, but if everything is connected to the same terminal the device can't act as a barrier because the connectivity is considered to not pass through the device.

The fact that you encountered this likely means that you either created your own model from scratch or altered one of the existing models and only added rules for one terminal of the device. Normally if you were to have a line that could connect to either terminal and you forgot to specify which one, you would get an ambiguous connectivity error that would force you to connect the lines to each terminal on the switch.

All comments

MikeMillerGIS

Those switches where not selected in your trace results. My guess is they are not connected to the network. Can you run a find connected trace and see if they are returned? If they are not, check the line to ensure there is a vertex at that switch location and that vertex is at the same XYZ as the switch.

JoaquinMadrid1

After you check connectivity as indicated by M. Miller, two other details come to mind:

(Possibly a silly question...) Is your switch snapped between the ends of two consecutive line segments? If it is snapped midspan to a single segment it will not act as a barrier.
Also, and only if your switches are configured with Terminals, make sure that the two lines converging into the switch are not connected to the same terminal. (Connected in the sense of their To or From end vertices to terminals.)

RobertKrisher

@JoaquinMadrid1 Your first statement is not quite correct. If a feature is snapped midspan on a line, it will still act as a barrier from a tracing perspective (e.g. features on the other side of the barrier will not be included). However, visually it will still include the line where the tracing stopped because the first section is included in the trace and the second section isn't, but we can only select the whole line.

JoaquinMadrid1

Thank you Robert... You are absolutely right. I'm glad you pointed that out.

GIS_kiwi4

Hi @MikeMillerGIS -

The switches are being selected in the trace, which is a problem.
I also tried running the connected trace and still the same result.

Result -

Expected Result -

RobertKrisher

@gis_KIWI4 Check to see if the two lines are connected to the same terminal, the condition barrier will only apply if the connectivity passes through the device.

MikeMillerGIS

Also, can you just select that line with the open switch. Is that all one big line?

GIS_kiwi4

@RobertKrisher - I hadn't made any terminal assignments assuming that it will still work as a barrier when the trace works its way though the devices.

I have tried to assign terminals - I can only assign the lines to Terminal 1 (Terminal two is greyed out).
When I connect both the lines to Terminal 1 and run the trace, it fails to stop at the device.

Can you confirm the following.

One line should connect to "Terminal 1" of the switch and the other to "Terminal 2" and that would mean it's passing through the switch?

GIS_kiwi4

Thanks @JoaquinMadrid1 ,
I agree with what you have said before. We took the time to evaluate the asset tpes that should have terminals and which shouldn't.
Essentially anything could be subnetwork controller (Circuit Breakers, Transformers, etc )gets configured with terminals. We modelled switches with terminals because we were advised that integrating without future ADMS would be easier. Similar to your observation, we decided to configure fuses, LV services, connection points without and Terminals.

Reading this answer has supported our thinking. Thanks for your input 🙂

Join the Conversation

Signed in members can post, follow updates, and more. New here? Register a free account.

Quick Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.