1

I have made a network of Water Pipelines with valves of my town, now I want to carry out certain analyses like Pipeline Burst analysis to identify the least number of valves that needed to be turned OFF to stop water wastage due to a burst in the pipeline. The areas that will be affected if certain valves are turned ON or OFF.

I have worked with QGIS, PostGIS, GeoServer, and Leaflet in past.

How can I implement this analysis in PostGIS or is there any other way?

I am quite new in the GIS field.

2
  • Within the PostgreSQL/PostGIS environment you will want to dive into pgRouting. With a properly set-up directed network topology you will be able to implement most graph theoretical analysis - albeit with a certain degree of lower-level development.
    – geozelot
    Jul 18 at 10:19
  • I have used pgRouting earlier in one of my project but I am not able to think of a way for implementing the analysis I want like, If there is a Pipeline burst what valves should be turned off to minimize the water un-availability during repair or if there is any alternate network to divert the flow etc. Even with a directed graph, I can't think of a way to get required outcomes.
    – Chinmay
    Aug 8 at 7:55

2 Answers 2

0

"Any other way": Our RW Net 4 library has such a function, the method TNetwork.Trace will do exactly that.

0

Scale is important here - You say 'your town'. What size of network are we talking here? How many customers? How complex is the network? How many valves? If only a small number, then the solution could simply be a simple network trace where you manually deal with the exemptions. If a larger more complex network, or dealing with larger important customers then the above approach doesn't cut it.

(additionally, being that "I am quite new in the GIS field.", my recommendation would be a commercial solution, which I am happy to discuss outside of this forum.)

But to answer the question - You are looking for a solution to create 'shutoff blocks' dataset and im going to answer it from a larger complex network perspective, because why not.

Water networks are often integrated and have redundancy in them but are also dynamic, which means the valves required to isolate a burst water pipe, will be different in lots of different scenario, even in the same location but at a different time. (There are lots of other factors, such as whether the valve is broken, or currently closed etc etc).

The solution required, is to create what are commonly called 'Shutoff Blocks'. These can be created on the fly, or stored in a database, with incremental changes made as the network changes. Calculating these on the fly can be problematic for performance if you have a complex integrated network. (additionally, analysis across an entire network to identify problematic areas of the network, requires a stored maintained dataset). So the approach is pre-calculate and store the shutoff blocks in the database and relate them to the network.

In order to calculate these, your underlying network is going to need really really good network topology. Crossings, X-junctions and T-junctions all need to be topologically correct, along with pipes of different states (Decommissioned, proposed) or different purposes (raw water as an example)

Once you have that setup, you can then write a frontier valve calculation which will for each pipe (x)

  1. Identify the connected shutoff valves that are joined to that pipe.(ie: ignore pressure reducing valves for example).
  2. Identify the connected pipes to each particular shutoff valve (conn_x). Ignore broken valves (unless they are closed)
  3. Flag the conn_x pipe as having a source of water (True/False).

If the conn_x pipes have a source of water, then the valve should be flagged as a 'frontier valve' and can be closed to isolate the network.

NOW - here is where it gets tricky. How you determine that a pipe has a source of water is tricky. in my experience, if the above iteration of steps, out from a starting point hits:

  • A dead end (cul-de-sac) of the network
  • A closed valve Then its the end of the network and no source. Therefore that starting valve is redundant and does not need to be closed.

However IF the iteration steps connect with:

  • a dam/water tank/storage facility etc etc
  • OR the iteration goes X number of steps. then there is a source of water. Do this for all valves connected to the source pipe and the end result is the 'shutoff block'. (the X number of iteration steps is variable for every network. some sites might pick 10 iterations, others 20, this variable basically prevents the algorithm from having to trace the entire network all the time).

This iteration can be quite expensive computationally. But it is critical if the water network is an integrated distribution network (which the majority are). Some systems tend to run this calculation once, store it. Then perform it incrementally when the underlying network changes. (which will then of course require you to setup data structures and network change detection).

Phew! Hence why I believe a commercial solution may suit better here.

OK so to summarize:

  1. Excellent network topology on your source data
  2. Network incremental change identification
  3. Calculate shutoff blocks process.
  4. Store shutoff blocks and relationship to the source network.
  5. Update incrementally shutoff blocks.

Using the shutoff blocks as the data source in your 'what valves to turn off' calculation (outage calculation) is far easier, as you have a simple relationship between pipe and shutoff block and hence, valves.

So you can implement this in an end application fairly straight forward, in multiple end-user interfaces (Desktop app, web app service exposed via a web map) The end user will not have to wait for a network trace routine to run and calculate the result, the shutoff blocks dataset relationships allows for dynamic valve state changes AND whole of network analysis can be performed.

1
  • The scale for my project can be considered a small town (Dummy Data sets as of now) with an area of approx 1SqKM with 7 Major valves and 19 minor valves. I am getting your point, with a similar approach I had done a project on "Green Corridor for emergency vehicles" but this one is quite tricky. Anyway, I'll try to work on this approach.
    – Chinmay
    Aug 8 at 8:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.