Hi -
The UPDM model seems to represent squeeze-off events as features in a non-network class (outside the utility network.) Our current data has squeeze-offs as simple junction features -- so these locations can be identified by a trace.
Will we be losing functionality if we migrate our current squeeze-offs into the UPDM, non-networked, P_SqueezeOff class?
Thx,
Ed
Solved! Go to Solution.
Hi Ed,
In addition to Robert and Ayan's great comments, I do have one more for you. A P_SqueezeOff feature's purpose is to denote where the pipe has previously been subjected to the material stress of a clamp to "squeeze off" the flow of gas. The importance of this is to insure that a pipe is not squeezed more than once at a single location. If you are interested here is a document from Performance Pipe on best practice for polyethylene pipe squeeze-off. The document specifies multiple constraints on where a squeeze can be applied. One of which is the location of a previous squeeze off. As such, it should never be used as a barrier feature in an isolation trace, as that would likely lead to field techs applying a 2nd squeeze off at a location where one should not occur. Managing the P_SqueezeOff data as a simple point feature outside of the Utility Network, accomplishes its purpose which is to convey the location where a field technician should not apply a squeeze off.
Tom
By not being in the network they will not be included in the trace, but you'd need to talk to @TomDeWitte about the intention behind making squeeze off's non-network. It may be that the intention is that squeeze offs are not permanently maintained as network features, but are used as inputs (temporary barriers) during trace. Keeping them outside the network makes them easier to track and avoids issues with network rules or other topology errors while still allowing them to be used for analysis purposes.
The Utility and Pipeline Data Model (UPDM) supports multiple implementation patterns.
The model is flexible to allow for all these implementation variations. In some cases, this introduces redundancy as for Squeeze-off. The choice is up to the organization based on their business requirements.
Squeeze-offs maybe better modeled through Utility Network topology and rules - use as Pipeline Junction. However, some pipeline operators using APR-only, model Squeeze-off as LRS event using the P_SqueezeOff class.
Ayan -
I get it. Thanks for the info!
Ed
Hi Ed,
In addition to Robert and Ayan's great comments, I do have one more for you. A P_SqueezeOff feature's purpose is to denote where the pipe has previously been subjected to the material stress of a clamp to "squeeze off" the flow of gas. The importance of this is to insure that a pipe is not squeezed more than once at a single location. If you are interested here is a document from Performance Pipe on best practice for polyethylene pipe squeeze-off. The document specifies multiple constraints on where a squeeze can be applied. One of which is the location of a previous squeeze off. As such, it should never be used as a barrier feature in an isolation trace, as that would likely lead to field techs applying a 2nd squeeze off at a location where one should not occur. Managing the P_SqueezeOff data as a simple point feature outside of the Utility Network, accomplishes its purpose which is to convey the location where a field technician should not apply a squeeze off.
Tom