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; } } }

Regardingh Combined domain network of Water and electric utility in a single Enterprise SQL database

PragatiSingh

we are moving to arcgis utility network for our electric and water geometric network data to Postgres enterprise database. How we separate the two domain networks within the postgres instance? Do we need to create separate databases within the instance

Encontre mais publicações marcadas com

Accepted answers

VishApte_NGIS

Separate geodatabase for Water and Electric seems to be a good choice if two different teams edit and maintain it. There are few considerations though:

1. If you have to develop attribute rules that refer to common dataset such parcel or property polygon, city council boundary, bushfire zones etc. using functions like FeatureSetByName, they only work within one geodatabase. This means you will need to have two copies of the common data, one in each GDB. Or register data views across the database if the use for common data is read-only.

2. If you have common structural assets e.g. bridge or trench or other structural boundaries, this will be difficult to model without duplication.

3. Relationship between water and electric service points and common customer information such as critical medical customer relying on water and electricity like dialysis machine.

4. Workflow for converting abandoned water pipes into a duct for electric cable.

5. Power supply for water and sewer pumps and treatment plants, though currently there is no-cross domain traceability between the domains.

Keeping Water and Electric UNM in a same geodatabase but different feature datasets e.g. WaterUNM and ElectricUNM in also an option. However, from memory, it creates structural feature classes and tables as StructureJunction_1 etc. for the second feature dataset.

Keeping Water and Electric in a single feature dataset and single topology model is ok if editing user permissions is not a problem. But if topology needs tweaking in either domain, the whole UNM needs disabling, causing outage across both domains.

Hope this helps.

Cheers,

Vish

All comments

Ayan Palit

@PragatiSingh There are multiple considerations in making a design decision here. Electric and Water typically don't mix - best to keep them as separate databases/schemas, one for each domain network.

Organizations are unique in their mix of utility domains that drive functional requirements, workload separations, IT policies (e.g RDBMS platform), integration needs. Recommend a holistic approach factoring in all parameters.

JakeJacobs

We recently received advice from Esri to have our gas and electric UN's in one database but in separate schemas. @AyanPalit can you describe what the criteria are for deciding on separate schemas vs separate databases? Also PostgreSQL here.

RichRuh

I would base it on the structure of your organization. If one GIS group serves both water and electric, then putting them in a single utility network makes sense.

If most of your users are using water or electric, and you want different permissions for each domain (e.g., water GIS users can view electric, but not edit) , then it might make sense to split them up.

JakeJacobs

Oh interesting. How does that work with the permissions? I thought that was just managed at the portal level with what groups the feature service is shared with?

RichRuh

When you publish a utility network to a feature service, you need to include the *entire* utility network.

If you put both domain networks (water, electric) in a single utility network, that entire utility network is included in the feature service. You can only set permissions on the feature service as a whole.

If you split them up into two utility networks, you would publish them as two services, and could set different permissions on each one.

Another consideration is if you want to share the structure network between domains. While you don't often see water pipes attached to poles, they may share trenches or other facilities.

JakeJacobs

Interested still to know about the distinction between putting two utility networks in separate schemas (which Esri recommended to us recently) and two separate databases (which Ayan Palit recommended here). Seems like in that case it wouldn't be for permission management.

Ayan Palit

@JakeJacobsAVA As is evident in this thread, there are multiple parameters in play.

Organizations are unique in their mix of utility domains that drive functional requirements, workload separations, IT policies (e.g RDBMS platform), integration needs. Accordingly, one size/recommendation will not fit all. Advice community members to consider their unique requirements/circumstances to right-size the Utility Network design.

RobertKrisher

@PragatiSingh there's lots of discussion here. You have two domain networks, and the assumption is that you want them to be in separate utility networks You could put them in the same utility network if you wanted them to share structures or had some other compelling reason, but that is not typical for water/electric.

If you do want to have multiple utility networks, then you can have options. If you just want to manage one database, you can put them in the same database but give each one separate schemas. If you put them in the same schema you will get name conflicts on the structure classes (so you'll have structurejunction and structurejunction_1).

If you want to manage them in separate databases, then you are free to do that using however many databases, instances, and servers that you want because the two utility networks are not related in any way.

PierreloupDucroix

Interesting topic. I'm working on a migration project where the client manages an electricity and water network.

Their common use case is to use the unique identifier of the utility poles (an identifier that indicates the pole's position on the network) to locate each field intervention, including on the water networks, since they don't have addresses.

While it's possible to manage this without merging the two domains into a single unified UN, it could be useful to associate the water elements with their corresponding utility poles and use this association in tracing, for example, to easily find the nearest pole to send a field team to.

RobertKrisher

@PierreloupDucroix How would you configure the trace to stop at the first pole? Poles are part of the structure network, so they can't be used as barriers. I suppose you could trace to the first fitting or valve and see if it has a pole associated with it.

For performance purposes I would think carefully about whether I wanted to turn on the update structure/domain container during update subnetwork. Do you really want to put the system, pressure tier, etc from your water network on your poles? Not only is it of limited value, but it will also make update subnetwork take longer to run (since it has to update all the poles in the network).

PierreloupDucroix

Thank you for your advice; it was just an idea, as we're only in the pre-project phase.

I could configure the poles to only be part of the first tier to reduce update time. Another solution would be to use attribute rules instead, to retrieve the IDs of the nearest poles in the water network elements. In this case, there would be no requirement for a unified UN.

RobertKrisher

I like the idea of using Arcade to identify the nearest pole on-demand, you'll just need to make sure that your water editors have read-only access to the electric layers.

If you combine both networks, then editors will need to have full read/write access to both datasets, and both editors will need to be careful with how they edit data. You'll also get some annoying scenarios like removing a pole as part of an electric design will cause a conflict with a water version because the water user added an association to that pole to a feature in their version.

PierreloupDucroix

Having a shared infrastructure will certainly encourage these scenarios, just as they might occur in a telecommunications/electricity network for poles or trenches...

In my case, the same team will handle both water and electricity management, as it's a relatively small organization.

VishApte_NGIS

Separate geodatabase for Water and Electric seems to be a good choice if two different teams edit and maintain it. There are few considerations though:

2. If you have common structural assets e.g. bridge or trench or other structural boundaries, this will be difficult to model without duplication.

3. Relationship between water and electric service points and common customer information such as critical medical customer relying on water and electricity like dialysis machine.

4. Workflow for converting abandoned water pipes into a duct for electric cable.

5. Power supply for water and sewer pumps and treatment plants, though currently there is no-cross domain traceability between the domains.

Hope this helps.

Cheers,

Vish

RobertKrisher

@VishApte_NGIS if you do keep the utility networks in the same database, but put them in separate schemas you avoid the StructureJunction_1 type issue.

Participe da Conversa

Membros conectados podem postar, seguir atualizações e mais. Novo aqui? Registre uma conta gratuita.

Links Rápidos

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