Isolation trace - Simulate whatifs scenarios

khem1000

Hi, we have a custom Experience Builder app with the OOB trace UM widget various configured named traces built in Arcgis 11.5. 

This includes the a valve isolation Trace in the water network, which returns the list of valves to close and list of impacted properties if a section of mains is isolated.

We now have a business requirement to enable users to simulate opening one or more nearby valves that would allow water to be fed from a different DMA so as to reduce the number of impacted properties in the event of a burst. 

 Thinking we may need to call a GP service which 1) identifies the valves which beëong to neighboring DMAs. If these are closed, then 2) change their status to open in a version 3) perform an isolation trace 4) return to user list of valves they can potentially open and corresponding list of impacted properties

 

Any ideas on the above requirements  

?

 

Thank you

PierreloupDucroix

Hello, I'm currently having the same thought process regarding opening closed valves to mitigate the impact of water outages.

Robert's proposed solution works best when the user needs to mark a valve as "inaccessible" or "unoperable." It's then possible to extend the isolation to the other side to simulate ignoring the valve. Even better, it's possible to add a starting point directly on the valve and specify the "Ignore barriers at starting points" option in the trace configuration.

Regarding opening a closed valve, it's not possible to force this object to be ignored as a barrier, since it's part of the trace's traversability parameters.

A simple solution I've considered is to temporarily modify the traversability during the trace to ignore closed valves. Using the Water Distribution UN Foundation dataset as an example, you can remove the conditional barrier "P:Device Status" = Closed. This way, closed valves will be considered open to supply a portion of the network, and previous valves on the network will be detected by the isolation trace.

However, there are drawbacks:

- The user doesn't explicitly choose which closed valve to reopen. However, they can explicitly designate a valve to remain closed by setting a break point on the map and specifying that it's a filter barrier.

- For the isolation trace to work, it needs to detect a subnet controller within a single subnet. Therefore, tracing must be done at the highest level (i.e., Water System); otherwise, more than one subnet may be detected.

- In reality, this will only work if you have sufficient pressure, so more tests would be needed to ensure that the pressure subnetwork on the other side of the closed valve is higher than the one being shut off...

Example, here a "normal" isolation trace in the Water Pressure tier, that finds closed valves (north) :

normal trace

And here is the same, at the Water System tier, without the Device Status barrier. The first open valve is detected instead of the closed one, a portion of the outage zone is now unimpacted : 

New trace without closed valves

I am open to discussing this further if other solutions are being considered.