Add Network Attribute (Trace Network) Issues

[EdwardBlair]

Hi –

I’m seeing unexpected behavior after I add a new “Network Attribute” to a Trace network.   Here are my steps.

1.       Disable Trace Network Topology

2.       Add a new Network Attribute named “NormalPosition” of data type Long

3.       Use Set Network Attribute to assign this network attribute to a (Long) field named NORMALPOSITION_A

4.       Enable Trace Network Topology

5.       Change the value of NORMALPOSITION_A on a feature from “Closed (1)” to “Open (0)”.  Save edits and validate topology.

6.       Perform a trace with a barrier defined to stop at NormalPosition = “Open”.  The trace stops at the newly opened device, as expected.  All good.

7.       Change the value of NORMALPOSITION_A on the same feature back to “Closed.” Save edits and validate topology.

8.       Perform a trace with the same barrier condition and it STILL STOPS at the device which was changed to “Closed”

Any suggestions on what I might be missing would be much appreciated.

Thx,

Ed

[Robert_LeClair]

This behavior is almost always because the trace is still reading the old network-attribute value stored in the network topology, meaning the edit didn’t get fully incorporated by validation.

Try these checks:

1. Validate the full dirty area (not just current extent)- A feature isn’t guaranteed valid “until the full extent of the feature’s dirty area is validated.” If you validate by extent and don’t fully cover the dirty area, tracing can still use outdated attribute values.

2. Confirm a dirty area is created for the attribute change - Network attributes used by tracing are stored in the topology; when the source field changes, a dirty area should be created and then validation updates the stored value used by traces.

3. If this is a Utility Network tier/subnetwork workflow - Depending on tier configuration, validation may mark subnetworks dirty and you may need follow-on QC (for example, Update Subnetwork / evaluate rules) for analytics to fully reflect changes.

4. Barrier value: code vs description - Make sure the barrier is evaluating the stored numeric value (0/1) and not a coded-value description string (“Open/Closed”).

[EdwardBlair]

Robert - 

Thank you for the reply.

To be clear, this is a "Trace" Network, not a "Utility" network.

That said, I've followed your steps exactly -- to the point of making sure there are *no* dirty areas in the database after completing my edit and validating and saving.   I still get the same result.   If I change the normal position of a device from open to closed, then perform a trace which has a barrier condition of normal position being "open", then the trace still at the newly closed device.

FWIW - I've also made sure that the domain codes are as expected; Closed = 1; Open = 0.

Ed