Feature: Show affected subscribers when adding a leak on a pipe

[tudorbarascu]

Good morning

I had this in though for a long time.

When adding leak to a pipe it would be nice to show the affected users.

Another related feature: If a segment of a pipe needs to be shut down, qwat should present the valves that need to be turned off in order to permit that segment isolation (+ all the affected segments)

I am thinking this should be done in the data model so that it's easily available through web.

What do you think?

[3nids]

Yes, that should be feasible. It could then be triggered from QGIS.

I don't have so much time left right now for such development. It'll have to wait a bit. But if you go for it...you're more than welcome.

We could try to discuss together how to solve this though.

Let me know what you think,

Denis

On 04/02/2015 07:58 AM, Tudor Bărăscu wrote:

Good morning

I had this in though for a long time.

When adding leak to a pipe it would be nice to show the affected users.

Another related feature: If a segment of a pipe needs to be shut down, qwat should present the valves that need to be turned off in order to permit that segment isolation (+ all the affected segments)

I am thinking this should be done in the data model so that it's easily available through web.

What do you think?

— Reply to this email directly or view it on GitHub https://github.com/qwat/qwat-data-model/issues/26.

[tudorbarascu]

I think we should discuss it. I can allocate some time in the immediate future. Do you have any plans to go to the QGIS Developper meeting in Copenhagen? I have plans to come to the next QGIS conference etc. that you'll join so that we can discuss face to face.

Tudor

[3nids]

Sadly, I'll miss the next meeting because we're waiting for a child just a few days after the HF... We can start here or by mail if you like.

[tudorbarascu]

Congratulations, really nice!

It would be best to start here. Currently, the model can have valves not linked to a node and I think it would be better if we would enforce that any valve has to be linked to a node.

[3nids]

Thanks.

I don't think so. The norm is for us to never place a valve at the intersection of pipes but always on a pipe. So the valves close or open pipes. How do you work?

[tudorbarascu]

Naturally, we also don't place valves at the intersection of pipes. However, we split the pipes into segments --> node at each valve. This feels right for us because a closed valve splits a pipe into segments of functional and non functional pipes. I have thought this through and although there is a caveat in having more nodes, we could just style the nodes for the valves to be more hidden from the view.

Also, we think that even for the case of when a water lateral connects to a water main the water main should be splited there. Thus, at every possible pipe inflection (altitude related, or hydraulic related -- connected hydrants, valves, water laterals) there should be a node.

I am thinking also with the hydraulic modelling in mind.

Also, when thinking about nodes, I always felt we should add another column that constrains the nodes to their position. Something like "fixed" with a boolean value so that the users can only move certain parts of a pipe (that were not determined exactly). Basically.. a way to add constraints to the path/geometry of the pipe where applicable.

[3nids]

Well, we don't split pipes, and we have a recommendation not to do so. How is it in epanet? So, there is no node to apply.

I think that splitting pipe is not the best way to go. Near to a pipe intersection (3 pipes, 3 valves, 1 on each pipe), you'll get very short segment. This might lead to data errors when you update the data (might forget to look for the small one).

Rather than splitting pipes, we could think about having nodes at pipe vertices. Therefore, they could also be used for small installations (elbow, ...).

[tudorbarascu]

Yes, splitting pipes every time is not the best way to go but it suits us better than not splitting at all. At big intersections (as the one you above described) it is indeed is more crowded but zooming in and digitizing the system exactly like it is works quite nice for us. This being said I think we will always have regions with pipes that are small (discharge, bypass, and pipes that are used to take water samples). Yes, having other kind of nodes at pipe vertices or something alike should be the better choice.

[haubourg]

Hi, decision was taken to remove valves from nodes to avoid too much pipe fragmentation. QGEP model is very similar and offer materialized views that recreate a full topology for use cases that require that. Permisssion to close the issue (clean up time :)) ?

[tudorbarascu]

@haubourg The valves-node issue is just a discussion spawned of this issue. This issue is a reminder towards possible enhancements:

• showing affected subscribers when adding a leak on a pipe
• If a segment of a pipe needs to be shut down, qwat should present the valves that need to be turned off in order to permit that segment isolation
• "Also, when thinking about nodes, I always felt we should add another column that constrains the nodes to their position. Something like "fixed" with a boolean value so that the users can only move certain parts of a pipe (that were not determined exactly). Basically.. a way to add constraints to the path/geometry of the pipe where applicable."

[haubourg]

Hi Tudor, I had recent discussions about this feature and I agree that is mandatory for drinkable water pipe handling.

@psc network routing to identify subscribers affected by a leak or identifying a zone affected by closed valve seems mandatory, as said in last general meeting. Is it a requirement for you? How do you handle those use cases currently ?

[ponceta]

To be mentionned in the routing point of next Tuesday.