*Will most likely be working with Enterprise v10.8.1, Pro 2.7, UPDM 2020
Been trying to find a solid answer to this architecture question for a Dev environment: Is it possible to have a single ArcGIS Server (1 site - single machine) be the host to multiple (e.g. 10) separate Utility Networks. The UNs would each exist in their own Ent GDB, with unique spatial references, and separate service areas.
(A secondary question of interest is if a single Enterprise GDB can host multiple UNs (different feature datasets, spatial references and UN objects - not talking about the different domains of a single UN)?
Thanks 🙂
Solved! Go to Solution.
There should not be issues with creating multiple UNs in the same geodatabase. The non-spatial object tables will be created with _1 appended to the end of them.
The UN system tables, domains, etc all use the OBJECTID from the GDB_ITEMS table for the utility network they pertain to as part of the naming convention. It might be a good idea to do the same for any user-defined domains that are created in the geodatabase to keep up the organization.
Here are a few domains with the naming convention mentioned:
Yes, it is possible for one ArcGIS Server to host multiple UNs as long as the UN models match ArcGIS Server. See https://pro.arcgis.com/en/pro-app/latest/help/data/utility-network/utility-network-dataset-administr... for compatibility between UN model version, Pro version and Enterprise version. We have a client in production using Sewer UN and Water UN as two different UNs with its own geodatabases in a single ArcGIS Server. We met some challenges creating a single Web Map App with tracing functionality for both UNs. Ended up with two separate Web Apps.
Re. single geodatabase to host multiple UNs, I would imagine this is not possible. Lot of system tables (UN_*) and system domains may conflict. But I will let someone from Esri officially confirm this.
Great info, thank you VishApte.
There should not be issues with creating multiple UNs in the same geodatabase. The non-spatial object tables will be created with _1 appended to the end of them.
The UN system tables, domains, etc all use the OBJECTID from the GDB_ITEMS table for the utility network they pertain to as part of the naming convention. It might be a good idea to do the same for any user-defined domains that are created in the geodatabase to keep up the organization.
Here are a few domains with the naming convention mentioned:
Thank you Melissa. I am glad you mentioned Domains. I am guessing that for each UN that you create within a single EntGDB the tools would create new (but duplicated) groups of domains for each UN, each with the new identifiers in the names. This might cause quite a bit of extra material in the DB? For maintenance at the DB level that alone might be a good reason to opt for separate Ent GDBs, each hosting its own UN?
Loren - Enterprise geodatabases should be able to handle the overhead of the extra utility network, but from an administration perspective you just need to be aware of how these are named and associated. I currently have several utility networks in a single enterprise geodatabase for internal testing.
It is up to you as the geodatabase administrator to decide if this is something that works for your organization. There are a lot of dependencies such as load, size, etc.