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

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.