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)
- Identify the connected shutoff valves that are joined to that pipe.(ie: ignore pressure reducing valves for example).
- Identify the connected pipes to each particular shutoff valve (conn_x). Ignore broken valves (unless they are closed)
- 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:
- Excellent network topology on your source data
- Network incremental change identification
- Calculate shutoff blocks process.
- Store shutoff blocks and relationship to the source network.
- 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.