Water Network Subnetwork Issue

[JimmyBowden]

I have implemented the Water Distribution Utility Network Solution.  The system and pressure subnetworks defined in this model use the Lifecycle Status (Does not include In Service and To Be Retired) as a condition barrier.  This has caused some issues creating subnetworks with approved to be constructed features and valves that are abandoned in the open position.  These features prevent subnetworks from being created correctly by stopping the subnetwork from continuing past devices with those Lifecycle Status values. It is fairly common in our water system that valves, tees, and other junctions are wet tapped into existing waterlines.

I'm considering adding a new true/false attribute to the feature classes and the network called "traceable".   Generally this would be true for Lifecycle Status In Service and false for Approved, Abandoned, Removed.  Then for junctions or devices that connect to in service lines set the traceable to true (the circled features in the image).  Then I would remove the Lifecycle Status condition barrier and use the traceable value as the condition barrier.  The obvious drawback of this is the some approved features will be included in subnetwork traces before they are installed.  Are there other unintended consequences that I'm not considering?

@MikeMillerGIS @RobertKrisher @JoelSmith3 

[MikeMillerGIS · Accepted solution]

Jimmy,

   Interesting idea.  What if you did it the other way.  Null Network Attribute get a pass.  So why not make a nullable field with one value, 0 = Barrier.  Then use an attribute rule to set that on items that should be barriers.  This could evaluate a number of fields, lifecycle, status, etc.  We need to make sure network attributes like these are inline to reduce database queries.  This would allow us to use a number of fields that determine if an item is a barrier or not and use a simple single value network attribute field.

[JimmyBowden]

Thanks @MikeMillerGIS I'm going to try this out and see if it meets our needs.

[RobertKrisher]

Based on the drawing provided it would seem like you would want to have approved and in-service be included in the networks (in your description you said you wanted to have approved be not traceable). Is there a reason why you wouldn't just modify the existing condition barrier to reference these different states? The only reason I could think of is that you are also considering using it to manage other situations / multiple fields, which is what Mike has alluded to in his comments.