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

[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:

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