nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Putting Water, Wastewater/Drainage all in One Utility Network

TaylorDixonSPU

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?

Trouver plus de publications taguées avec

Accepted answers

RobertKrisher

If you want to have different utility networks in the same geodatabase, create different users/schemas for each utility network. As an example, in SQL Server you would use the Create Database User tool to create a Water User, Wastewater User, and Stormwater User. Each utility network would be placed in its own schema and published as a separate service.

All comments

MichaelParma

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

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

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

-Mike

CherylTrine

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

MichaelParma

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

RobertKrisher

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.

joyoung_kerrvilletx

How is it possible to have multiple Esri Utility Network models in one database? My organization is working to move our geometric networks for water, wastewater, reclaimed water, and stormwater to utility networks. Esri's local government information model schema gave everything unique names to avoid conflicts. However, in the utility network models I am seeing some tables with the same name. For example, StructureEdgeObject and StructureJunctionObject. I do not want to end up with is a bunch of tables with a "_1" or "_2" at the end of them.

Is it best practice to deploy each model to its own database or rename all the duplicate named tables?

RobertKrisher

joyoung_kerrvilletx

@RobertKrisher creating a unique user/schema for each utility network works for me. I want to have each utility in its own network but stored in the same database to make database management easier. Thank you.

Rejoindre la conversation

Les membres connectés peuvent publier, suivre les mises à jour, et plus encore. Nouveau ici ? Inscrivez-vous gratuitement.

Liens rapides

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.