Approved Features Interfere with Utility Network

[GlenColgate1]

When new features are created in GIS to represent future facilities, they are introduced to the Utility Network with "Approved" lifecycle status value. This status distinguishes these features from the rest of the network as they are not yet in service or possibly not even constructed. This is an important stage of the construction process and these new features should be available to edit, analyze and map along with all of the other features.

Their inclusion is presenting us a problem building our subnetworks in a way that allows us to include/exclude approved features. Adding approved features as a condition barrier, then connecting approved to active lines will prevent traversability when trying to build the subnetwork. If we don't include approved as a condition barrier they are returned in subnetwork tracing.  This makes the result incorrect since the new approved features should not affect the network until the features are active in the field and provided an "In Service" status in our GIS.

Our idea is to allow the network to IGNORE features of a designated condition (lifecycle state = "Approved") and let the remainder of the utility network to function as if they do not yet exist.

[RobertKrisher]

Can you provide a screenshot or graphic that shows exactly how the approved construction is interfering with your traces?  There are several techniques for handling approved/proposed construction, and it will help to see how you are currently modelling your features.

[JimmyBowden]

Replying for Glen since we are working on this together.

For context we are using a modified version of the Water Distribution Solution.  The system and pressure subnetworks have a condition barrier "Lifecycle Status Does not include any (bitwise AND equals False) Specific value In Service and To Be Retired".

In the image below the cyan are approved features and the blue are in service.  When we go to build the subnetwork the approved valve, cap, and coupling act as barriers (as expected based on the condition).  Everything to the right will not be included in the subnetwork.

[RobertKrisher]

Ah I see now. Modelling in-line proposed install/retired features is one of the trickier items to model because, as you noted, the system treats the new features as barriers (to ensure they are not included in the subnetwork). If you are going to be at the Esri UC I would love to sit down with you at a whiteboard with someone from our water industry solutions team to draw out several of the ways you can handle this.

[GlenColgate1]

Unfortunately, I don't think we have anyone attending this year. Would love to setup a virtual meeting if possible. Or if you can point us at any online white paper / video that might describe the methods you are thinking about?

[RobertKrisher]

There should be a blog coming out in the next week or two that shows how to model in service, proposed, and proposed remove features concurrently in the network model and how to trace the different states of your model. You don't need to adopt everything outlined in the article, but it will provide a good description of why things are behaving the way they are and how to leverage this behavior.

[JoelMa923]

I'm interested in this article as well, can point me to the post?

[Brian_Colson]

I would be interested in this as well @RobertKrisher .  I think it is this article,  but can you confirm that?

Thanks!

[RobertKrisher]

@Brian_Colson that's the article! Sorry for not responding to this thread earlier, I must have missed the notification two weeks ago.

[Brian_Colson]

Thanks @RobertKrisher !

This is article. 

FYI
@JoelMa923 , @GlenColgate1 , @JimmyBowden