Putting Water, Wastewater/Drainage all in One Utility Network

927
6
09-20-2023 12:26 PM
TaylorDixonSPU
New Contributor

Hi all,

I left the ESRI UC this year operating under the presumption that we would put Water, Drainage and Wastewater data all in the same Utility Network, but build different subnetworks for each using Tiers and Tier Groups.

I was told today by a solutions person that Water would be separate from Drainage/Wastewater, which sort of ruins the simplification we were hoping to have from all of our data residing within the same feature classes.

Can someone clarify all of this for me? Maybe it's theoretically possible but no one is implementing it all in a combined utility network? 

0 Kudos
6 Replies
MichaelParma
New Contributor III

Hi Taylor,
I agree with the direction you've been given about keeping those separate. First, water is pressurized and so operates differently than the gravity systems. Combining the databases but still allowing for different tracing functions would require significant work on the business rules and configurations. Think how you would prevent an isolation trace from running on sewer mains, for example. The number of connectivity rules would increase dramatically and become more difficult to manage. Theoretically possible, but not practical at this point in time.

We normally advise our clients to keep water, wastewater, and stormwater in separate networks. If you happen to have a combined wastewater and stormwater system, you might consider using wastewater as a base and extend the model to incorporate stormwater assets.

Hope this helps.

-Mike Parma
Axim Geospatial


RobertKrisher
Esri Regular Contributor

Let's look at the different approaches for separating or combining this data and the pros/cons of each. Firstly, Esri provides standard models to get you started for Water, Wastewater, and Stormwater (links and descriptions can be found in this article), and for the purposes of this discussion let's assume you're starting with one of those models.

Your initial approach of putting them all in one network and separating them out by tier would imply that you aren't using one of the Esri models, which separate them out into different domains (Water lines, sewer lines, etc). If you wanted to do this you would need to make your own model (which is a lot of work!) where everything has a single domain and as Mike noted doesn't really align operationally with how you manage these systems. In this situation all of your layers would have a single set of rules, fields, and drop downs that all users would share. Users would be able to view/edit all the data in the network, so you wouldn't be able to restrict editing of water data to water users or vice versa.

The second approach often considered is to combine the different domains of models provided by Esri into a single utility network. This sounds good at first, but because everything exists in a single-network that means that all your viewers and editors from each department will need to be able to view/edit all the data in the network. So water people will be able to edit wastewater data and vice versa. The same can be said of the administrative experience. This does make it easier to manage/maintain, but once again it typically doesn't like up with the way that organizations want to administer their systems (in this case IT systems and databases, instead of pressure zones and sewershed areas).

Finally, the most common approach is to create separate feature datasets and utility networks for each domain. These allows the user/administration privileges for each domain of data to be managed independently of the other network domains. It is still possible to trace between these separate networks by using tools such as the "Add Starting Locations" gp tool to turn the results of one trace into the starting location of another trace.

MichaelParma
New Contributor III

Good point, Robert. The administration/security considerations are another good argument for keeping separate!

-Mike

0 Kudos
CherylTrine
Occasional Contributor II

To extend the question a bit, the campus on which I work manages all of its utilities except gas.   I had planned to develop a utility network with each utility as a separate domain so that they could make use of the same structural network.  Frequently, various utilities share structures such as manholes, poles, conduit, ground boxes, etc., and I wanted this shared status to be obvious to those perusing the data, especially when conducting a trace.  If I were to create separate utility networks, I would have to maintain multiple copies of the structural network.  I could see that could become quite a headache to keep them synced. Currently, I am the only editor, but this could change down the road.  In this case, what would the recommendation be regarding multiple domains or multiple networks?

Cheryl

0 Kudos
RobertKrisher
Esri Regular Contributor

Cheryl,

 Ah, context is always important here. It would make sense for utilities that share the same structures (electric and communications) to be in the same utility network and feature dataset with separate domain networks. For your other domains it is less likely that they are sharing the same structures (e.g. potable water and reclaimed water) so there isn't as much of a benefit in keeping them in the same utility network.

 Just to reiterate one of the cons of combining within the context of your current situation. Having everything in the same feature dataset and utility network also means that any time you are administering one of the layers, you need to lock all the features in the dataset (meaning schema changes to water would require kicking editors from all departments out of the GIS). As you mentioned, this isn't a problem now because there's only a single editor, but the moment you start trying to bring in a second editor or have an admin and an editor you will need to be much more deliberate about coordinating changes.

I don't know which commodities you have on your campus, but I would expect electric/communications to share a network, the water networks to each be separate, and anything like district energy to also be in a separate network. You're free to combine them into a single network, but you'll experience some of the cons listed above and earlier in the article.

MichaelParma
New Contributor III

I'm curious to see Robert's response. That is certainly an argument for combining networks. My inclination is the complexity of adding all the necessary connectivity rules is much more difficult than syncing shared structures. In other words, not worth the effort, at least currently.

 

-Mike

0 Kudos