It is a common practice by Water Utilities to perform isolation trace to identify the valves that need to be turned off when isolating a section of the network or a pipe for repair/replacement etc. and then find the assets and customer connection points that will be impacted as a result of closing the valves.
Currently, this requires running Isolation Trace two times. First trace is to find upstream valves that need to be closed and is done with "Include Isolated Features" parameter set to False. The result will give only those valves that are currently open and need to be closed to isolate the section of the network. The trace results will not include any downstream valves or any other assets.
Then we need to run the same trace again, this time with "Include Isolated Features" option turned on. The result will tell us which customer connection points or meters that will be isolated as a result of closing the valves in the first trace. This is often used to notify customers of a planned or unplanned outage.
The nature of water network being in loops, isolation trace can take long time. It has to exhaust all possible paths to the subnetwork controller to find the upstream valves. In CBD areas of a midsize city, it can take 2-3 minutes. Doing the trace two times doubles the time. Since the trace is done by field crew and in a pressure situation if an unplanned outage, every extra minute adds to the stress. If an option is provided in the first trace itself if the feature traced is an isolating feature (meets barrier condition), then second trace can be avoided. It should only flag those valves that are upstream. There may be other valves that are downstream and shouldn't be flagged.
If the trace is run in ArcGIS Pro, it will be nice to select isolating features in a different color (e.g. yellow) than a normal selection color (e.g. cyan).
I would like to second this.
If both could be returned with some differentiation in the response it would be a good optimization. We have found being able to call 2 traces quite powerful, but it's not the best UX for crews in stressful situations.
We have exactly the same scenario, we are triggering multiple traces to return isolated & isolating assets. I think the foundation data model confuses people because it has isolating valves as an asset type, so it kind of gives the impression that it's doing both functions with a single trace, but in complex networks the isolating valves are extremely contextual to the area being shut down.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.