Select to view content in your preferred language

Downstream Trace Barriers - How to trace an asset type and stop at the next encountered asset of the same type

336
3
Jump to solution
08-17-2025 08:08 PM
gis_KIWI4
Frequent Contributor

Trying to run a downstream trace where the dynamic barriers are assets belong to Network Category = A. The problem is the starting point also belongs to Network Category A. 

The condition barriers are evaluated on the starting point and the trace stops there. 

The "ignore barriers at starting points" option only applies to barrier features that are placed before the trace.

I have also tried using the function barriers where "add" of that network category >1 then logically it should stop at the next asset belonging to said network category. This does not work because of the terminals. 

Terminal 1 -> Device A1 -> Terminal 2-------------------------------------------Terminal 1 ->Device A2 -> Terminal 2

If my start point is Terminal 1 and I use "add" of that network category >1 then it stops that the same device i.e A1. 
If my start point is Terminal 2 and I use "add" of that network category >1 then it produces the expected result and stops at Device A2. 

how can I achieve this?

0 Kudos
1 Solution

Accepted Solutions
gis_KIWI4
Frequent Contributor

Right - So I got some success.
I used Filter Barriers instead of Condition Barriers (Traversibility)

gis_KIWI4_0-1755644448823.png

Right, so I realized I was getting the concept of Traversibility Barriers and Filter Barriers mixed up. 
The way I have understood this is Traversibility Barriers are where the Network Trace can travel where as The Filter Barriers are where the trace should stop. 

Another realization has been that - if you are using the GUI to create starting points the terminals matter. I found I had to trace both terminals to actually get the trace to leave the device.  

If you scripting then best to create a start point feature class without TerminalID set.

gis_KIWI4_1-1755646335392.png

 

View solution in original post

0 Kudos
3 Replies
gis_KIWI4
Frequent Contributor

Right - So I got some success.
I used Filter Barriers instead of Condition Barriers (Traversibility)

gis_KIWI4_0-1755644448823.png

Right, so I realized I was getting the concept of Traversibility Barriers and Filter Barriers mixed up. 
The way I have understood this is Traversibility Barriers are where the Network Trace can travel where as The Filter Barriers are where the trace should stop. 

Another realization has been that - if you are using the GUI to create starting points the terminals matter. I found I had to trace both terminals to actually get the trace to leave the device.  

If you scripting then best to create a start point feature class without TerminalID set.

gis_KIWI4_1-1755646335392.png

 

0 Kudos
gis_KIWI4
Frequent Contributor

If anyone needs more clarification this can be found here - https://pro.arcgis.com/en/pro-app/latest/help/data/utility-network/barriers.htm

 


Filters

Filters are evaluated and applied on the second pass of a trace operation to allow the discovery of subnetwork controllers so that flow direction can be established. There are two types of filters: filter barriers and filter function barriers.




 

0 Kudos
RobertKrisher
Esri Regular Contributor

Are you looking for the first downstream device that is a smart switch OR open? or that is an open AND a smart switch?

When I ran a trace on a device with terminals and left its terminal ID blank, I got an error.

In terms of how filter barriers are applied, they have a special behavior when dealing with devices with terminals. They are only evaluated when we cross an internal edge of the device. This is why if you start at the downstream edge of a protective device we will stop on the device, but if you start on the upstream edge, we return the upstream protective device. Its this same behavior that keeps us from treating distribution transformers as potential barriers (unless you cross from LV to MV).

0 Kudos