Network Configuration Data Model Version Last Update Configuration Location Data Loading Tools Location Migration Tools Location
|Electric (Distribution & Transmission)||4.0||May 2021||http://esriurl.com/elecmigration|
|Gas / Hazardous Liquid Pipeline (UPDM)||1.2||May 2021||-|
|Water Distribution||4.1||May 2021|
This table shows the current status of Utility Network Industry Configurations and data loading tools. It will be kept up to date.
Resource specific data models for the utility network are contained in the corresponding Network Configuration. For example, if looking for the water distribution data model for the utility network download the Water Distribution Data Management for ArcGIS Enterprise.
UPDM and the Gas Pipe Utility network configuration was made with material as the Asset Types to build rules to control which types of pipes, fittings, etc can be connected. Do you not require rules by material in your implementation?
besides cathodic protection I don't see a benefit for connectivity but we all have CP so maybe good to have the material in. Just strange that water and gas see in differently.
I'm not sure if this is the most effective place to mention this, but we've spotted a glitch in the latest water distribution asset package (3.2) - it is designed to report the "service connection count" per subnetwork but isn't correctly configured to do so within most of its tiers. It turns out to be quite easy to fix - by editingthe relevant records in the "B_Subnetwork_Summaries" table of the package GDB before applying it to the enterprise GDB.
Similarly, the transsubnetworklength and distsubnetworklength summary attributes should be based on the summed lengths of lines with an asset type of 1 and 2 (respectively) - rather than asset groups 1 and 2.
This can be fixed in an existing utility network (with topology disabled) by running Add Network Attribute, Set Network Attribute, and Set Subnetwork Definition.
Is there a way to incorporate cardinality rules in the utility network that define how many edges can be connected to a single device/junction. An example of this would be limiting the maximum number of edges that can connect to a X-Junction (cross junction) to 4.
The Utility Network does not model cardinality, but it can be enforced, restricted or flaged as error with an Attribute Rule. Here is an example of a constraint rule I created to reject too many related features by type. This could also be done as a validation rule where instead of preventing the edit, it would just mark the issue as an error when the rule was violated.
Thank you for the link to the item within your git repo. The other rules in this repo are very interesting and will definitely be looking into some of these in the future.
Just a quick question - How much overhead to the user do these cause? Especially when it comes to looking up values from other feature classes (eg. restrict editing rule looking up the user access from the fgdb)? Is the delay noticeable everything it fires on the insert/update/delete?