Hi everyone, I’m working with a Water Utility Network in ArcGIS Pro 3.5 and trying to implement a custom isolation trace behavior. Requirement We have control valves with a source attribute called: GroundCondition If: GroundCondition = "High Speed Road" then the isolation trace should NOT stop at that valve and should instead continue to the next valid control valve. Operationally, these valves are difficult/inappropriate to use for isolation. What I Tried 1. Added a new field IsolationEligible Values: * 1 = valid isolation valve * 0 = should be skipped Calculated using: IIF(Upper(Trim($feature.GroundCondition)) == "HIGH SPEED ROAD", 0, 1) 2. Added Utility Network network attribute Created a network attribute from IsolationEligible. 3. Updated Isolation Trace configuration JSON I added IsolationEligible as a network attribute condition in: * conditionBarriers * filterBarriers Example: { "name": "IsolationEligible", "type": "networkAttribute", "operator": "equal", "value": 1, "combineUsingOr": false, "isSpecificValue": true } Observed Behavior Connected Trace Picks up the new field but behavior is not consistent The trace stops devices where: IsolationEligible = 0 Isolation Trace Does NOT work as expected. Observed behavior: * Trace still stops at first control valve even when IsolationEligible = 0 * OR trace returns: WARNING 002535: arcgis un trace warning with no results. Important Finding After investigating Utility Network properties, I noticed: Control Valve -> Category = Isolating Device It appears the Isolation Trace solver inherently treats these valves as valid isolation candidates before the custom network attribute condition is evaluated. This seems different from how Connected Trace behaves. Steps followed: * Created a new field along with a domain * Added auto Population Rule to make sure new data updates accordingly * Updated all existing control values with correct logic (Calculate field) * Add Network Attribute * Validated network topology I introduce this IsolationEligible field to Supply Device FC and but values were calculated only for Control Value subtype which is the isolating device. For other types the value is "Null" Questions * Has anyone implemented similar “skip this valve during isolation solving” behavior? * Is there a supported way to influence Isolation Trace candidate valve selection using custom network attributes? * Is using separate asset types/categories the recommended pattern? * Are there other approaches people have successfully used? Any guidance or real-world patterns would be greatly appreciated. Thanks!

Please open a case with support on this. Seeing a blank error message like that means something unexpected is happening.

@gis_KIWI4 Here is the filter barriers added But it completes with a warning This is a generic warning. When I run connected trace I noticed sometimes the field IsolationEligible was working ok as a filter barrier.

@DonSanjeewaErangaJayaweera - network attributes are supported in the trace. You shouldn't need to re-index or anything. Are you able to share some screenshots of the devices being selected and the trace tool. That might help troubleshoot this further.

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; } } }

Isolation Trace - Skip Certain Control Valves Based on Attribute / Ground Condition

DonSanjeewaErangaJayaweera

Hi everyone,

I’m working with a Water Utility Network in ArcGIS Pro 3.5 and trying to implement a custom isolation trace behavior.

Requirement

We have control valves with a source attribute called:

GroundCondition

If:

GroundCondition = "High Speed Road"

then the isolation trace should NOT stop at that valve and should instead continue to the next valid control valve.

Operationally, these valves are difficult/inappropriate to use for isolation.

What I Tried

1. Added a new field

IsolationEligible

Values:

1 = valid isolation valve
0 = should be skipped

Calculated using:

IIF(Upper(Trim($feature.GroundCondition)) == "HIGH SPEED ROAD", 0, 1)

2. Added Utility Network network attribute

Created a network attribute from IsolationEligible.

3. Updated Isolation Trace configuration JSON

I added IsolationEligible as a network attribute condition in:

conditionBarriers
filterBarriers

Example:

{
  "name": "IsolationEligible",
  "type": "networkAttribute",
  "operator": "equal",
  "value": 1,
  "combineUsingOr": false,
  "isSpecificValue": true
}

Observed Behavior

Connected Trace

Picks up the new field but behavior is not consistent

The trace stops devices where:

IsolationEligible = 0

Isolation Trace

Does NOT work as expected.

Observed behavior:

Trace still stops at first control valve even when IsolationEligible = 0
OR trace returns:

WARNING 002535: arcgis un trace warning

with no results.

Important Finding

After investigating Utility Network properties, I noticed:

Control Valve -> Category = Isolating Device

It appears the Isolation Trace solver inherently treats these valves as valid isolation candidates before the custom network attribute condition is evaluated.

This seems different from how Connected Trace behaves.

Steps followed:

Created a new field along with a domain
Added auto Population Rule to make sure new data updates accordingly
Updated all existing control values with correct logic (Calculate field)
Add Network Attribute
Validated network topology

I introduce this IsolationEligible field to Supply Device FC and but values were calculated only for Control Value subtype which is the isolating device. For other types the value is "Null"

Questions

Has anyone implemented similar “skip this valve during isolation solving” behavior?
Is there a supported way to influence Isolation Trace candidate valve selection using custom network attributes?
Is using separate asset types/categories the recommended pattern?
Are there other approaches people have successfully used?

Any guidance or real-world patterns would be greatly appreciated.

Thanks!

Find more posts tagged with

Accepted answers

All comments

DonSanjeewaErangaJayaweera

Hi RobertKrisher,

Thanks for your inputs.
Just to confirm that I have already done below steps for this testing.

Created a new field along with a domain
Added auto Population Rule to make sure new data updates accordingly
Updated all existing control values with correct logic (Calculate field)
Add Network Attribute
Validated network topology

I introduce this IsolationEligible field to Supply Device FC and but values were calculated only for Control Value subtype which is the isolating device. For other types the value is "Null"

RobertKrisher

Once you've created the network attribute you must assign it to each field/class you want to associate with that network attribute then you must ensure that the field on each class is populated with the desired values.

DonSanjeewaErangaJayaweera

Thank you for your reply.
From the start I was using filter barriers.

Now I tested again using the exact condition:

Category = 'Isolating Device' AND IsolationEligible = 1

but the behavior remained the same. May be he filter barrier logic may only evaluate built-in/system network attributes and ignore custom-created ones.

DO you know whether custom network attributes are officially supported in filter barrier conditions for tracing/isolation workflows? If they are supported, are there any additional requirements such as indexing, schema registration, or publishing settings that need to be configured?

RobertKrisher

A condition barrier will prevent the trace from identifying sources, while filter barriers are used to identify candidate features to act as isolation equipment. For what you are trying to do, you want to configure a filter barrier. I'm just restating what @gis_KIWI4 said in a way that makes sense to me.

To be clear, there is no 'internal logic' or behavior of the UN with regards to condition barriers/filter barriers. We will only evaluate the attributes that are configured in the form. There are default condition barriers that are included in subnetwork definitions that are populated when you configure an isolation trace, but these are configurable and can be modified at will so therefore are not 'internal'.

GIS_kiwi4

Adding the condition barrier AND in FilterBarrier isn't going to be benficial.
If you want the trace to stop at a certain object then that condition belongs in the FilterBarrier sections.

You should use a AND condition in your FilterBarriers section.
So your condition might look something like Category = Isolating Device AND IsolationEligible = 1

This will mean that any Control Valve that is not on HighSpeedRoad will be treated as a Isolating Device.

As a crude test, I tried this on our electric Network.
I can confirm it skips any devices that are not subnetwork controllers and selects the one where ISSUBNETWORKCONTROLLER = True

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.