Latest Contributions by RobertKrisher

If you’ve used the Migrate To Utility Network tool to migrate your sewer or stormwater data into a utility network, you’re likely asking yourself: "what configuration do I need to perform on this utility network to make it behave like a gravity-based network?" These systems rely primarily on gravity to move various types of fluids through pipe networks. Analysis workflows for these datasets often involve determining the potential sources and destinations for fluids, analyzing the maximum capacity of a location, as well as identifying how the system behaves during different loads (dry weather, wet weather). GIS users typically focus on using the system to do upstream and downstream feature analysis, and the data managed by GIS editors is used by engineers to create models for the more sophisticated engineering analysis activities. In this article we will show you how you can take a network produced by the Migrate To Utility Network tool and extend it to support some of these basic workflows. Tracing One of the most common forms of analysis in a stormwater or sanitary sewer network is to identify all the features that are upstream or downstream of a location in the network. In this section we will show you how you can answer these questions using the tracing capabilities of the utility network. Let’s start by looking at an area of a stormwater network that has a series of conduits or pipes (light green lines) connected to several detention basins (blue polygons) that discharge at an outfall (point symbol) into a nearby river (blue lines). You can see this image below: When lines are drawn to represent the flow direction of fluids from a high point to a low point in the system, flow direction can be visualized using the digitized direction of the line. Notice how each line in our network has arrows on it? That is because the lines are symbolized using their digitized direction. This is important because each of these lines has been drawn from its high point to low point, or from high pressure to low pressure, allowing the digitized direction of the line to represent the flow direction in the network. Calculating the actual flow (volume and direction) of fluids in a network using gravity, pressure, etc. is the domain of an engineer using an engineering analysis tool. However, by maintaining the flow as the digitized direction of the line in the GIS you can use this to control the analysis of the utility network. You can identify the areas that provide fluids that will discharge into the river by running an upstream trace from the outfall using the trace tool. Because the digitized direction of the lines in this dataset accurately reflects the flow of materials in the network, you check the Use Digitized Direction parameter. In the example below, the analysis starts at the outfall, shown with a green circle. The utility network includes the ability to trace using the digitized direction of lines. If you’re curious to learn more, you can read this article published about how digitized direction tracing works. Now that you can see which features discharge into the river, the next question is to identify the final discharge point in the dataset. This can be answered using the same starting point and a downstream trace using the digitized direction of the line. In the example below we are analyzing the same outfall from the same location, shown with a green circle. By performing a downstream trace from an outfall (green circle) we can visualize the infrastructure downstream of this location. If we look closely at the downstream trace results, we can see several outfalls in this area that aren’t connected to the network, indicate with red arrows. These are important structures that need to be regularly inspected and may even have discharge permits associated with them. Running this trace allows this problem to be easily identified so that field verification of their locations and elevation can be gathered. This will ensure you have a complete, have a high accuracy model that can be used to support engineering and operations. Named Trace Configurations If you have a trace you use often in your utility network, you should consider creating a named trace configuration for it. Name trace configurations allow you to run a trace using the Trace pane without the need to select all the parameters in the tool every time you want to run the trace. Tracing in the web and mobile environment also benefits from the creation and sharing of named trace configurations. In the case of gravity networks, you will likely want to create a named trace configuration for the upstream and downstream traces using digitized direction, for the reasons we discussed above. To do this, open the utility network’s Add Trace Configuration tool, give the trace configuration a name, then configure the trace you want to run. Below you can see the downstream trace we configured above. Creating trace configurations makes it easy to share traces with web and mobile users. Note: If you want to include structures, containers, or non-spatial content in your trace results be sure to check those options. We include an example of why you may want to do this in the Containment example below. After creating named trace configurations, they will appear in the Named Configurations tab of the Trace pane (see graphic below). To use them, add a start location for a trace using the Start tab on the Trace pane, select the named configuration you want to use on the Named Configurations tab, then click Run. Desktop users can access trace configurations using the Named Configurations tab on the Trace pane. Containment Features in the structure layers represent locations where structures in your network are supporting infrastructure. While they don’t directly participate in the connectivity and tracing of the network, there are benefits to being able to identify the structures associated with a particular trace. Let’s look at an example in a stormwater network. In our stormwater network there are many detention basins, that are used as a best management practice area for improving the capacity of the system during a wet weather event. There are pipes that drain into these areas, and outlets or overflows that allow them to spill over into the rest of the network once they’ve reached capacity. Below is an example of a detention basin with five pipes that discharge into the basin and one overflow that allows it to discharge into a nearby manhole. A detention basin is commonly modeled as a structure boundary. This allows us to visualize the extents of the basins and infer its inlets and outlets. When you run a trace that passes through this basin, the basin itself is not selected. This is because the basin is not associated with any of the features in the network. If you want to associate a basin structure with other network features, you must determine the role of the structure in the structure network, then you must add rules that determine which features the basin is allowed to be associated to. In the case of the basin, because it is a structure boundary it is already configured as a container. This means it can contain other features. You want it to contain the discharge points that discharge into it or drain water out of it, so the first step is to add a rule that allows it to contain those features. Adding a rule allows us to model an explicit association between the detention basin and the discharge points that represent its inlets and outlets. Once you’ve added the rule, you can then use the Modify Associations pane to add the discharge points as content of the basin. Creating containment associations between discharge points and the detention basin allows us to identify the inlets/outlets for the basin through analysis. This allows us to unambiguously represent this relationship even if an outlet isn't contained within the detention basin polygon. Note: The box next to each feature in the Visible column is checked. This allows it to be visible which enables you to see the discharge points on the map even when you aren’t explicitly viewing the contents of the container. After running the trace, you can see that a downstream trace that passes through the basin will now select the basin as well. Creating a containment association also means we can include the detention basin in our trace results. You can control whether to include structures, contains, and content in traces in your trace configuration. Outfall connections Maintaining spatially accurate outfalls and open channels in your GIS can create technical challenges where outfalls don't physically connect with the centerlines of open channels such as canals or rivers, despite discharging into these waterways in the real world. Outfalls and canals are often not spatially coincident in a utility network because the canal line represents the centerline of the channel while the outfall is typically located on the edge of the canal which may be dozens of feet away. While some customers choose to address this by creating an artificial pipe or channel that connects the outfall to the channel, a utility network can be configured to allow features that are not spatially coincident to be connected through the creation of a junction-junction connectivity association between them. In this instance you would place a junction on the channel where we want the outfall to connect, then create a connectivity association between that point and the outfall. Before we do this, add a connectivity rule must be added to the network that allows these two features to be connected using this type of association. To do that you must first disable the network topology, a common requirement for making most changes to the utility network’s rules. You then add a rule allowing for a junction-junction association between the outfall device and the preferred channel junction. In your data model the outfalls are in a Discharge Point layer and the junction you are using is a Stormwater Network Junction. Adding a juction-junction connectivity rule allows us to connect junctions or devices that are not spatially coincident. One interesting option on the Add Rule tool is that you need to specify which terminal on the discharge point is allowed to connect to the network junction. Devices in a utility network can be configured to use terminals to manage connections. When a device has terminals every connection to that device must specify which terminal it is connected to. In the case of this outfall, because it is a subnetwork controller you need to specify which features are connected to the upstream or downstream side of the outfall. This information must be manually populated because the utility network does not use elevation for its analysis, and in certain scenarios features with a higher elevation (like an overflow) will be on the downstream side of a device. Setting the upstream/downstream features properly is critical to ensuring correct results for upstream and downstream traces. Once you’ve added the junction-junction connectivity rule defined above, re-enable the network topology. Going back to the original location you will need to create a junction feature on the river to act as the location where the outfall will connect to the river channel to act serve as the location where the outfall will connect. Next, you can connect the outfall to the junction feature using the modify association tool, making sure to select the outfall’s downstream terminal. Creating a junction-junction connectivity association between two devices or junctions allows them to be connected even though they are not spatially coincident. After validating the edit you can see that a downstream trace from the area upstream of the outfall will pass through the outfall, continue through the channel, and continue to make its way downstream through the system. The utility network considers both the spatial coincidence (implicit connectivity) and associations (explicit connectivity) when performing analysis. If you want to see all the associations within your current extent you can click the View Associations button on the Associations group on the Utility Network tab. This displays dashed lines that represent all the connectivity and attachment associations within the current extent. The View Associations command allows you to quickly visualize associations, like junction-junction connectivity, on your map even though the associations themselves have no geometry. Conclusion In this article you learned how to use a utility network to perform directional traces using digitized direction to simulate the flow direction of water in a gravity system. You also learned how to turn these traces into repeatable tasks using named trace configurations and how associations can be used to manage the connectivity of your outfalls and contents of your basins. If you’re interested in more content covering advanced analysis tasks like watershed or sewershed management or management of sub-basins and catchments, let us know! If you want to know more about using a utility network to manage gravity-based networks, like sewer and stormwater data, please explore the Learn ArcGIS Utility Network for Sewer and Stormwater learning series. This learning series includes tutorials and articles that demonstrate how to address the needs of the sewer and stormwater industry using the ArcGIS Utility Network. As always, if you have any questions about utility networks, be sure to ask them on the Esri Community site.       ... View more

If you’ve used the Migrate To Utility Network tool to migrate your gas or water data into a utility network, you’re likely asking yourself: What configuration typically do I need to perform on this utility network to make it behave like a pressurized network? These systems are typically used to move liquids or gases through pressurized pipe networks. Analysis workflows for these datasets often involve determining how to isolate portions of the network, analyzing the maximum capacity of the pipe network, and how well the network supports the intended area. In this article we will show you how you can take a model produced by the Migrate To Utility Network tool and extend it to support some of these basic workflows. The examples in this article show a water dataset, but the concepts and techniques apply to any pressurized network. Network Categories One of the most important network analysis business requirements for water and gas customers is the ability to perform an isolation trace on their network data to identify customers impacted by an outage, regardless of whether it’s planned or unplanned. The geometric network was able to perform an approximation of an isolation trace using its connectivity model. Using a utility network, we can recreate this behavior by using a connectivity trace that is configured to stop when it encounters a valve. Below you can see an area of the network we want to isolate to repair a fitting on the main below. The area we need to isolate is indicated on the map with a green circle. Isolating a water main. The green dot represents the area we want to isolate.  By starting a trace at the location we want to isolate (the green circle) and running a connectivity trace that stops at system valves you can reproduce the same result as seen with the geometric network. You can do this by adding a condition barrier to the trace that tells the trace when it should stop the analysis. Fortunately, the migration tool creates network categories for each asset group that can be used when configuring traces. Running a connected trace that stops at system valves is an approximation of an isolation trace. However, an isolation trace should consider many valves (emergency, bypass, etc), not only system valves. While you could configure our trace to reference all the different asset group and asset type combinations, it would be quite cumbersome to list them. Fortunately, the utility network allows you to create and assign network categories to asset types in your model, to control tracing. In this way it can identify and interact with common types of equipment, without the need to remember all their codes. To do this, you start by creating a new network category for isolating equipment called Isolation using the Add Network Category tool. The add network category tool adds a creates a network category in a utility network. Once you’ve created the network category, then use the Set Network Category tool to assign it to all the asset types that are considered operable devices during an isolation trace. The set network category tool assigns one or more network categories to an asset type. Once this network category has been assigned to the different types of isolation equipment, you can now run the trace and reference the single network category instead of the individual asset types. Once a network category is created it can be used when tracing. Any features with that network category assigned will be found by the tool. Now that you’ve got the isolation trace working like it did in the geometric network, let's look at how we can take it a step further and take advantage of new features included in the utility network. Create a Subnetwork Controller It makes sense that when data is migrated from a geometric network to a utility network that this same behavior is present, with all the same limitations. In the geometric network isolation traces often relied on the basic network connectivity trace, meaning they didn’t have any knowledge of network sources. As a result, the isolation trace wouldn’t be able to recognize features downstream of the isolated area as also being isolated. You can see an example of this below. A connected trace only approximates an isolation trace because it isn't aware of the sources of water in the network. This means it can't identify and downstream areas that are also isolated. The utility network solves this problem by allowing the definition of sources and sinks in networks, referred to as subnetwork controllers in the utility network. A subnetwork controller is responsible for a subset of the entire utility network known as a subnetwork. If you identified layers in your utility network as subnetwork controllers during your migration, or if your geometric network contained sources or sinks, then you will have the configuration in place to turn features in those layers into subnetwork controllers. If you didn’t define any asset types as controllers during mapping when you ran the Migrate To Utility Network tool, you will either need to rerun the tool with the option selected or  manually configure at least one asset type as a subnetwork controller using the instructions outlined in the Set a subnetwork controller page in the online help. In the case of this dataset, you can create the water treatment plant as a subnetwork controller for the entire water distribution system. To do this you can use the Modify Subnetwork Controller pane to set the downstream terminal of the treatment plant as a subnetwork controller for a new subnetwork called the Naperville Distribution System and name this subnetwork controller the Firemens Treatment Plant. Use the modify subnetwork controller pane to enable a feature to be a subnetwork controller. After clicking apply you can see that a dirty area Is created for the treatment plant that we need to validate to ensure the network is aware this new subnetwork controller exists. Enabling a feature as a subnetwork controller modifies the network topology, so it must be validated. After validating the new controller, you can now take advantage of all the trace types in the utility network that require a subnetwork controller. This includes subnetwork, subnetwork controller, upstream, downstream, and isolation traces. By selecting the subnetwork you created in the Trace tool and clicking run, you can see all the features that are connected to this treatment plant, which should be the entire network. A subnetwork trace will select all the features that belong to that subnetwork. Returning to our original example, you can now produce the correct result to return isolated areas downstream of the isolated area by taking advantage of the directionality of flow the controller provides. First, select an isolation trace and tell it to use the sources of the Water System tier in the network. An isolation trace requires subnetwork because it uses the subnetwork controllers to identify the features that are used to isolate the desired area, as well as all the affected features. Second, configure the trace to isolate the area using the isolation category you configured earlier. If you were to try and use a condition barrier, as above, you will get an error communicating the need to specify at least one filter barrier (see graphic below). This is because isolation traces use filter barriers to identify the features that are isolated, while condition barriers are used to identify the features that define the extent of the trace (e.g. the subnetwork trace). You must specify a filter barrier to identify the features that should be used to isolate the area. By using the isolation category as a filter barrier the trace first identifies the subnetwork controller(s) for the water system and then filters the results to include the features downstream of the filter barriers. By default, the tool will only select the features that isolate the area (e.g. the filter barriers). By default, running an isolation trace will identify the features used to isolate the desired area (green dot). To see all the pipes and customers that are isolated you can choose the Include Isolated Features parameter on the trace. Check the include isolated features option to include the isolated features as well as the features used to isolate the desired area (green dot) This now gives you the correct result, isolating the immediate area along with all the features downstream that can no longer access a source. Network Attributes If you migrated your data from a geometric network and look at your subnetwork trace dialog you will notice that there is a condition barrier set up on the Enabled field. This means that features with an Enabled value of False will act as barriers to tracing. Condition barriers often rely on network attributes to control the behavior of tracing. If you were already relying on this field for tracing, then your traces will continue to behave as they did in the geometric network. However, if you were managing information like this in another field and would like to use that field to control tracing instead of, or in addition to, the Enabled field then you can configure the utility network to act this way with just a few steps. Pressurized systems use valves to direct the flow in the network. The field that represents whether a valve is normally open or closed is often called Normal Position or Normal Status. You may even have a field called Current Position or Current Status, but this is typically used to represent the temporary status of the network according to field crews or a network operator. So how do you incorporate this information into network analysis? You make the attribute a network attribute. The first step to doing this is to create a new network attribute that is managed by the utility network. To do this you must disable your network topology and run the Add Network Attribute tool. When you create the network attribute you must first select a data type.  This is an important selection because any field in your data you want to use to populate this attribute must have the matching data type. Adding a network attribute to your utility network allows you more control over tracing and analysis in your system. Note: It is currently not possible to create a network attribute for a string field, so if your status field is a text field you will need to either create a new integer field for managing status or you should consider just using the existing network attribute configured for the enabled field. You will see there are also additional options in this form that control how this network attribute is stored in the system tables. Storing an attribute in-line is best for performance during tracing, but there is limited space for how many attributes can be stored in-line, so you should only choose this option if you will be using this attribute frequently and it is a Boolean, such as a yes/no value. In the case of our Normal Status field, we can take advantage of this behavior! Because this field in your table is nullable you need to ensure that you configure the network attribute to be nullable as well, otherwise you won’t be able to pick the field. When making an attribute in-line, you must specify a domain. For more advanced workflows you may want to set up additional attributes such as Operable (whether a valve can be operated), Current Status (the status used by network operators), or even Pinchable (whether a pipe can be pinched). But for now, let’s skip over those attributes and focus on assigning the new network attribute using the Set Network Attribute tool. Next open the Set Network Attribute tool to assign the new network attribute to the NormallyOpen field on your table. Setting a field on a table as a network attribute allows the utility network to read the values from that field and use them during network analysis. Now that you’ve created a network attribute that allows the normal position of a valve to be considered when tracing, you’ll want to configure the network to use this attribute whenever you trace the subnetwork. Set Subnetwork definition To do this, open the Set Subnetwork Definition tool and select your utility network, domain network and tier. Next, scroll down to the subnetwork trace configuration section of the tool and select your network attribute in the condition barriers. In this example you will be replacing the Enabled field with the Normal Status field. Fortunately, both treat the value of 0 as a barrier (Disabled / Closed). The condition barriers in a subnetwork definition determine where the subnetwork trace stops. It is most commonly used to identify closed valves and proposed equipment. Note: If you assign a domain at the class level for your network attribute fields you will see a drop down with the values from the coded value domain instead of needing to manually type in the corresponding domain codes. Once you’ve updated the subnetwork definition, any time you run a subnetwork trace in this tier, it will automatically include this condition barrier in the trace configuration. The Set Subnetwork Definition tool has many properties that control the behavior of the subnetwork. These parameters are discussed in greater detail in the advanced configuration article. Trace configuration We saw how changing our trace configuration made it easier for us to run subnetwork traces, but what if you have several different traces that we frequently run. By using the Add Trace Configuration tool, a trace configuration can be saved to the database so users in the desktop, web, and mobile can use the same trace you’ve just authored. To do this, open the Add Trace Configuration tool, configure your trace, name it, and run the tool to make it available to others. In our case, we will be creating three separate trace configurations, one to show valves to isolate an area and another one to show everything that is isolated. Creating trace configurations is a quick and easy way to share tracing capabilities with web and mobile users. If you wanted to, you could create additional trace configurations to select only the customers isolated by creating and assigning a network category for customers then adding an output condition to the trace for this network category. Use the output section of the trace configuration to control which features from the trace are returned. Once you’ve created all your named trace configurations, you can quickly access them using the Named Configurations tab on the Trace pane. This is not only more convenient than launching the trace tool, but traces run through this tab are actually faster! The Named Configurations tab is a quick and easy way for desktop users to run named trace configuration. Conclusion This covers the initial set of configurations that can be applied to a pressurized network, such as those found in the gas and water distribution industries, to help get you started with analysis. If there are other, more advanced configurations like pressure zones or cathodic protective structures that you want to know more about, let us know! If you have any questions about utility networks, be sure to ask them on the Esri Community site. If you want to know more about using the utility network to manage pressurized networks, like gas and water systems, please explore the Learn ArcGIS Utility Network for Water Utilities and Learn ArcGIS Utility Network for Gas and Pipeline learning series. This learning series includes tutorials and articles that demonstrate how to address the needs of these industries using the utility network. ... View more

If you’ve used the Migrate To Utility Network tool to migrate your electric data into a utility network, you’re likely asking yourself “what configuration do I need to perform on this utility network to make it behave like an electric distribution network?” These networks model the path that electricity takes from a medium voltage circuit breaker located in a substation to the low voltage customers in the network. Analysis workflows for these datasets range from looking at the load on the circuit breaker or transformer, to ensuring protective equipment is properly sized to handle potential faults in the system. In this article we will show you how you can take a model produced using the Migration toolset and extend it to support some of these basic workflows. Note: Before making configuration changes to your network, you should ensure you have addressed all topology errors discovered because you cannot trace in areas of your network that contain errors. Fixing topology errors after you’ve enabled your network topology or deployed your utility network will limit your ability to use tools like Apply Error Resolutions to automatically correct errors. Connectivity Tracing The first, and most basic kind of trace in the utility network is a connected trace. To perform a connected trace, you add a starting point on a network feature to the map, then run a connected trace. This style of trace will return all the features that are traversable from the given location based on the configuration provided for the trace. A connected trace without any additional configuration is likely to return your entire dataset, as you can see below. A connected trace returns all features connected or traversible to the start location While this is a convenient test to identify disconnected features, a more realistic trace would consider a device’s status (open/closed), electrical phasing, and whether a feature is in service or proposed. This can be simulated by manually adding barriers to your trace to represent these conditions, however, the recommended way to do this is to define condition barriers for your trace. If you use the Migrate To Utility Network to create your network, you will see that every feature has an enabled field. If you migrated data from a geometric network this field is populated with a value indicating whether it should act as a barrier. In the example below we perform a trace using data from a geometric network and treat all the disabled features (open devices) as barriers. Adding a condition barrier to a trace allows the trace to stop when certain criteria are met, like an open switch You can see that unlike the initial trace, this trace returns all the features that are electrically connected to the feature associated with the starting point. Evaluating these condition barriers during a trace allows us to discover the extent of the circuit from the starting location. While it’s perfectly acceptable to use the enabled field as a condition barrier, you may not be used to maintaining an enabled field and want to use a different field to maintain your switchable device status. This is discussed in the next section. Device Status To include attributes from your features in tracing or analysis, create a network attribute so the utility network can reference them. Let’s walk through an example of creating a Device Status network attribute that can be used to manage tracing. The first step is to identify the field from our data that we want to use. In this case we will be using the NormalOperatingStatus field in our device class. This is a short integer field with a domain assigned to it that indicates whether the device is open (1) or closed (0). Most electric data models have a Normal Status field on switchable devices that indicates whether they are open or closed. Now that we’ve identified the field, data type, and domain we want to use, we can create the network attribute. First, we add a network attribute to the utility network that matches the data type of our field. Because this field will be used in almost all of our traces, we want to store it in-line, so it performs better Creating a network attribute for device status allows the utility network to use this value during tracing. Read the online help topic on network attributes for more information about their use and effect on the behavior of your utility network. Once the network attribute has been added to the utility network, the next step is to select which fields to associate with the attribute. We aren’t required to associate a network attribute with each class in our network, but each network attribute can only be associated with a single field from each class. If we have multiple status fields, we can only select a single field to associate with this network attribute. Use the Set Network Attribute tool to define which fields in your tables are used to populate network attributes. Once we’ve associated this field with our network attribute, we can then use it to define a condition barrier for our traces. Because the device status attribute is now populated by the normal operating status field, and it has been configured as a condition barrier for the trace, the connected trace now stops at all open switches. Any time a user modifies a field associated with a network attribute the feature will generate a dirty area that must be validated to update the network with the new value. We can see an example of this below where we are tracing through a closed fuse (1) and after setting the device status of the fuse to open and after validating the edit the trace then stops at the newly opened fuse (2). Here is an example of what it looks like when you trace a close fuse (left) and an open fuse (right) This strategy works well when you have a single status field, but what about when you maintain a different status field for each phase? We will discuss this in our next section. Multiple Status Fields In the previous section you saw how you can use a single field to model the open/closed position of a device. However, if you have fields that allow each phase of a device to have a separate status, you will need to consider one of several solutions. It is common for electrical models to use three separate fields to manage the open/closed status of a device. Each of these fields corresponds to a different phase of electricity (A, B, or C), and this model allows the network to model the status of each phase of a device separately. Some models have multiple status fields. One for each phase of electricity for the device. When using the Migrate To Utility Network tool, a device must be treated as gang operated. This means that the device is either considered to be open or closed, it cannot have a mixed status. If you need the ability to model devices with a mixed status you will either need to model them as separate devices or you will need to migrate your data into the Electric Utility Network Foundation. There are several ways to make this work using the Migrate To Utility Network tool. The easiest way is to continue using the enabled field (or create a single device status field) to control tracing and populate this field using your existing status values. To do this you need to know a few things: What fields do you use to represent the status of each phase of a device? What values represent open and closed? What field do you use to represent the phasing of a device in your network? What values in the phase field are applicable to each status field? Using this information, you can use the Select By Attributes tool to identify all the equipment that should be open or closed. Let’s look at an example of this below. What fields do you use to represent the status of each phase of a device? Status Field Name A Phase Status POSA B Phase Status POSB C Phase Status POSC   What values represent open and closed? Status Value Open 0 Closed 1   What field do you use to represent the phasing of a device in your network? PhasingCode What values in the phase field are applicable to each status field? Phase Value A 4 B 2 C 1 AB 6 AC 5 BC 3 ABC 7   With this information we can write three queries: Query Expression Devices that should be Open (Enabled=False) ENABLED=1 AND (((POSA=0 AND PHASINGCODE=4) OR (POSB=0 AND PHASINGCODE=2) OR (POSC=0 AND PHASINGCODE=1)) OR (((POSA=0 OR POSB=0) AND PHASINGCODE=6) OR ((POSA=0 OR POSC=0) AND PHASINGCODE=5) OR ((POSB=0 OR POSC=0) AND PHASINGCODE=3)) OR ((POSA=0 OR POSB=0 OR POSC=0) AND PHASINGCODE=7)) Devices that should be Closed (Enabled=True) ENABLED=0 AND (((POSA=1 AND PHASINGCODE=4) OR (POSB=1 AND PHASINGCODE=2) OR (POSC=1 AND PHASINGCODE=1)) OR (((POSA=1 OR POSB=1) AND PHASINGCODE=6) OR ((POSA=1 OR POSC=1) AND PHASINGCODE=5) OR ((POSB=1 OR POSC=1) AND PHASINGCODE=3)) OR ((POSA=1 OR POSB=1 OR POSC=1) AND PHASINGCODE=7)) A query to identify equipment with a mixed status (PHASINGCODE=6 AND ((POSA=0 AND POSB=1) OR (POSA=1 AND POSB=0))) OR (PHASINGCODE=5 AND ((POSA=0 AND POSC=1) OR (POSA=1 AND POSC=0))) OR (PHASINGCODE=3 AND ((POSB=0 AND POSC=1) OR (POSB=1 AND POSC=0))) OR (PHASINGCODE=7 AND ((POSA=0 AND POSB=0 AND POSC=1) OR (POSA=0 AND POSB=1 AND POSC=0) OR (POSA=0 AND POSB=1 AND POSC=1) OR (POSA=1 AND POSB=0 AND POSC=0) OR (POSA=1 AND POSB=0 AND POSC=1)))   Let’s look at an example of applying this technique to our data. First, run the query to identify features with a mixed status in your network. If this query identifies any features, then you will need to consider how you want to support devices with mixed status going forward. If acceptable, use a single status field and manage multiple fields accordingly. Otherwise, you will need to consider other options, like using the electric utility network foundation. Next, select all the devices in the network that should be Open (Enabled=False). You can use the select by attributes field to identify features where every applicable phase is open or closed. Then, set the Enabled field on these features to be Disable/Open. The attributes pane is an easy way to quickly set devices to be open (false). Note: If you have a large dataset you should consider disabling the network topology and any attribute rules on the device layer before applying these edits. Once you apply the edits this will create dirty areas in your network that need to be validated. Before you validate your edits, repeat this process to identify any devices that should be Enabled/Closed. This is because the Enabled field is a network attribute, so changes to it must be validated using the Validate Network Topology tool. Once you’ve validated all the dirty areas in your network, or re-enabled your network topology, your traces will now respect this new value. Using the attributes pane to quickly set devices to be closed (true). Now that we’ve talked through several techniques for modeling device status in an electric network, let’s look at how the utility network models circuits and why the utility network refers to them as subnetworks. Electrical Phasing Managing the energized phases is an important requirement for tracing and analysis for many electric customers. If you keep track of the phasing of every line and device in your system, then you should follow these steps to include your phase information in your network so you can use it during tracing and analysis. To perform this configuration, you will need to identify the following information: What classes and fields contain phasing? Do you represent phasing using an integer value? What domain do you use to represent phasing? With this information you can create and assign a network attribute used to track phasing in your network. The first thing you’ll need is a coded value domain to represent all the combinations of phases in your system. Because the utility network calculates and propagates phasing using bitwise operations, the field needs to be an integer if you want to use it to manage phase. If you don’t care about using phasing for quality assurance or analysis purposes, just for reporting purposes, you can represent it using a non-integer value. For both the basic and advanced articles we will be using an integer with a coded value domain designed for use with bitwise calculations, shown below, to represent phasing. You can learn more about how the utility network propagates attributes in the Attribute propagation and attribute substitution in subnetwork management article. An example of a coded value domain for electrical phasing. Its values are designed for bitwise calculations. The next step is to make sure that your device, junction, and line class each has a single field that uses this domain to track phase. Once you’ve done this, you’re ready to configure your utility network to use this field. First, you’ll add a network attribute to your network using the Add Network Attribute tool. Consider this rewrite: As with many utility network administration tools, it is necessary to disable your network topology before you can run the tool. When you mark the attribute as in-line you’ll need to make sure you pick the data type and domain you identified above. Add a network attribute for electrical phasing for use in analysis. Once you’ve added the network attribute to your utility network, you need to tell the utility network which classes and fields correspond to this network attribute. To do this use the Set Network Attribute for each class in your network that manages phase. This usually includes the Electric Device, Electric Junction, and Electric Line classes in the network. Setting the phasing field as a network attribute will cause it to populate the corresponding network attribute with the values from your features. With this completed, you will then be able to use this field when running traces using your network. The easiest way to use this attribute is to use it to act as a filter or barrier when you are tracing your network features. Below is an example that will return all the features that have an A phase on them. Using the electrical phasing network attribute to filter your output is a simple way of using electrical phasing for analysis. Note: If you assign the phasing field at the field level for the corresponding network attribute of your classes, you will see a drop down instead of needing to type in a number manually. This is a convenient reporting mechanism, however if we want the subnetwork to consider the phasing when determining what features are energized, we need to perform additional configuration. That topic is discussed in the advanced configurations article. Create a subnetwork Most electric distribution circuits originate at a circuit breaker or recloser located in a station. Everything downstream of this circuit breaker is part of the same circuit. In utility network terminology the circuit is a subnetwork, because it is a distinct subset of the network that is important for analytical purposes. The devices that act as sources/sinks for a subnetwork are known as subnetwork controllers. In the case of most electrical networks, the circuit breaker (or recloser) is a subnetwork controller, and most circuits have a single subnetwork controller. At a higher level, the distribution domain network is source-based. This means that the circuit breaker is the source of flow for the subnetwork, and it is upstream of all the features in the subnetwork. We can determine the extent of a circuit by running a connected trace, with barriers for Disabled/Open features and circuit breakers. Below are the results of a trace with this configuration, originating at a circuit breaker: A connected trace starting at a circuit breaker and stopping at open devices. Up until this point all the traces performed have been connectivity traces. That is because to perform an upstream, downstream, or isolation trace you must have subnetworks defined. There are two ways to create subnetwork controllers in the utility network. The first is to use the Modify Subnetwork Controller pane to select a feature and manually create a subnetwork. Going back to our original example. Because we know that circuit breakers control our circuits, we should have checked the “Is Controller” option for that mapping in the Migrate To Utility Network tool. This will configure the resulting asset types in our utility network to act as subnetwork controllers. If that was not done, we will need to manually configure the circuit breaker asset type to be allowed to act as a subnetwork controller using the instructions on the Set a subnetwork controller page in the online help. Once circuit breakers are allowed to be subnetwork controllers, we use the modify subnetwork controller tool to turn the circuit breaker into a subnetwork controller then validate the dirty area it creates. We can then run a subnetwork trace for that circuit, using the same condition barriers we’ve been using, and we will get the extents of the circuit. Setting a circuit breaker as a subnetwork controller allows the system to identify all the features connected to the circuit breaker as belonging to a specific subnetwork. In an electrical model subnetworks are most commonly used to represent feeders. Note: If you do not apply the condition barriers for Enabled/Device status to your trace you will not see the correct results. We will discuss why, and how to correct it in the Subnetwork Definition section. We can also run upstream and downstream trace within that circuit, and if we apply our condition barriers the traces will succeed. Upstream and downstream traces also require creating subnetworks since they use the path to the subnetwork controller to determine the direction of flow. Now that you understand how to manually create subnetworks, the next step is to look at how you could import a collection of subnetwork controllers into the utility network. This is an important step for many electric networks as they may contain hundreds or thousands of circuits/subnetworks. Importing Subnetworks The second way to create subnetworks is to import a csv file containing information describing all the subnetworks in the system. Both approaches are valid, but for most electric customers it is relatively easy to produce a csv file defining all their subnetwork controllers. You can learn more about this process in the Import a subnetwork controller page of the online help. In this example we have created the following CSV file. An example subnetwork controller CSV representing all the feeders in a subnetwork  Once you’ve populated this CSV file, you use the Import Subnetwork Controllers tool to import the file into your network to enable the corresponding features as subnetwork controllers. Use the import subnetwork controllers tool to import a file to enable the corresponding features to be subnetwork controllers. After importing our subnetwork controllers, we must validate the dirty areas on each of the controllers before they can be recognized as a source. Once you’ve done this, traces that rely on subnetwork controllers like upstream, downstream, and even isolation tracing may be performed As we discussed previously, for our subnetwork traces to work we must still manually define condition barriers to ensure open switches stop our traces. In the next section we will learn how to use the Set Subnetwork Definition tool to make this the default behavior of all our subnetwork traces Subnetwork Trace Configuration Up until this point, every trace required that you specify a set of condition barriers as part of the trace configuration to ensure we get the correct results. Because we want these condition barriers to automatically be applied every time we run a trace, we can use the Set Subnetwork Definition tool to modify the definition of our subnetworks to include these condition barriers by default when performing subnetwork based traces. While we are modifying the subnetwork definition, we will discuss the importance of some of the other parameters in this tool that you may want to adjust. The first step to modifying your subnetwork definition is to select the network, domain, and tier you want to modify. Once you’ve made these choices the tool will automatically populate with the current subnetwork definition for that tier. The set subnetwork definition tool lets you customize the way subnetworks in a tier behave. The first thing we need to do is add our condition barriers to our subnetwork definition. This is done by populating the Condition Barriers parameter under the Subnetwork Trace Configuration section of the tool. Any changes made to the Subnetwork Trace Configuration section of the tool will affect the default trace configuration used by the utility network when analyzing this tier of the network.  By default, the Migrate To Utility Network tool adds a single condition barrier for disabled features. The trace configuration of the subnetwork definition controls how subnetwork tracing behaves.  In the previous example, we want to add another condition barrier to treat Open devices as barriers. If we have other network attributes configured that we want to use as barriers we could configure them here as well. It is important you define the condition barriers for your subnetwork to ensure they can properly identify boundary devices like tie switches.  Another important option you should consider in this section of the tool is whether you want to include containers, content, and structures in your trace results. If you decide to model structures or containers inside your network, this will allow the subnetwork traces to quickly identify the features supporting or supported by the subnetwork. You can control whether you want structures or content to appear in your subnetworks.  This subnetwork trace configuration also allows you to define summaries for each subnetwork. These summaries allow you to calculate summary statistics during your traces, and if you define a summary attribute the results can be calculated and stored on your subnetwork line feature for reporting purposes. A simple example of this would be to calculate the total conductor length for a circuit, as shown below. Adding summaries to your network makes reporting using subnetwork lines easy. Just be mindful of the overhead of performing additional calculations.  Each summary you calculate takes time during trace and update subnetwork, so be mindful of how much time is being spent calculating summaries versus the benefit they provide to your end users. Once you’ve adjusted your subnetwork trace configuration you can click run, however you may also want to adjust other sections of your subnetwork definition. Valid Features and Objects Another important section of the subnetwork definition is the Valid Features and Objects section. This determines which features are allowed to participate in subnetworks for this tier. When you add new asset types to your model it’s important to update your subnetwork definitions to account for them, otherwise you will get errors when you update your subnetworks that contain features with these new asset types. The subnetwork definition also determines what kinds of equipment are allowed to participate in a given tier of the network.  You should also consider updating the Aggregated Lines for SubnetLine Feature Class parameter. This determines which geometries to consider when creating the subnetwork line class. By default, the utility network builder won’t include any asset types, meaning a subnetwork line won’t be generated when you update subnetworks. You should only select asset types for this parameter that represent medium and high-voltage lines. Do not select all your asset types for this parameter, as this has a significant negative impact on the drawing time of your subnetwork line layer. The aggregates lines parameter determines which features are used to create the geometry of the subnetwork line. Note: Features not included in the subnetwork line are still included in the summary statistics for the network, so if you want to calculate your conductor length consider using a Summary function in your trace configuration. This has the added benefit of allowing you to define a filter to calculate separate lengths for medium and low voltage conductor. Update subnetwork policy The update subnetwork policy allows you to fine tune the behavior of your subnetworks to balance business requirements and performance.  The last major section of the subnetwork definition is the update subnetwork policy. This gives you control over how subnetwork information is updated within your utility network. Making changes to these settings is not a simple decision for many customers, as it involves making tradeoffs between convenience and performance. We will give a brief overview of these decision points here and refer you to more thorough discussions where available. If you include structures and containers in your network you can choose whether you want to populate their subnetwork name. The first, and easiest point to discuss is whether to update structure/domain network containers. If your subnetwork trace configuration includes structures/containers, you will see options here for whether to update them. This determines whether the subnetwork name, supported subnetwork name fields on your structures and containers will be updated when they contain or support a feature that belongs to a subnetwork. This allows you to use the select by attributes tool to identify features that support a subnetwork without running a trace. While this is convenient for reporting purposes, it also means that update subnetwork will take longer to run because there may be hundreds of thousands of additional features that need to be updated. Managing whether a subnetwork is considered dirty or not is a decision with a big impact on your quality assurance workflows and network integrations.  The next option to discuss is whether the tier should manage the IsDirty field, you can find a deep dive on state management on the Esri Community site. This field is used to indicate whether there have been edits validated in your utility network that have affected a particular subnetwork. This option is set to false by the utility network builder because it can have performance impacts. If this property is enabled, then every time you validate edits, the utility network must perform one or more traces to identify which subnetworks are impacted. Because most electrical circuits contain only a few thousand features, this cost is usually relatively small compared to the benefits to quality assurance. However, you should consider leaving this property disabled if your subnetworks contain tens of thousands or hundreds of thousands of features. Having this property enabled allows you to focus your quality assurance efforts on just the subnetworks that have been modified and allows you to easily identify which circuits have been clean and ready to be extracted to an external system like an OMS. The most performant configuration is to leave this option disabled. The configuration that is most beneficial for quality assurance and integrations it to enable state management. The edit mode for updating subnetworks is another important setting to consider when balancing quality assurance workflows and performance.   The last option to consider is which eventing mode to use for default and for named versions. This affects the performance of update subnetwork and whether the subnetwork field is populated during certain workflows. There is a deep dive on eventing modes on the Esri Community site. A greatly simplified version of the discussion follows. When a subnetwork is updated without events it will run faster. This is because of several factors, but one reason is that attribute rules and editor tracking are not triggered. The largest drawback to this behavior is that when updating subnetwork in a named version, not all features are guaranteed to have their subnetwork name updated to match the subnetwork they belong to. When a subnetwork is updated with events, the first update subnetwork operation that is run will take longer. Subsequent updates can also take longer to update if you have attribute rules configured and are updating large numbers of features. The benefit of updating subnetworks with eventing enabled is that when update subnetwork is run in a version you can guarantee that the subnetwork name feature is correctly populated for all the features belonging to that subnetwork. Note: At ArcGIS Enterprise 11.4 and ArcGIS Pro 3.4, the performance cost of triggering attribute rules can be mitigated using the new Triggering Fields behavior of attribute rules. The most performant configuration is to leave the eventing mode to update without events. The most useful configuration for quality assurance is to enable the eventing mode when in named versions and to ensure you have properly configured triggering fields on all your attribute rules. Conclusion Now that you’ve finished this article, you have learned the basics of how to configure tracing and network attributes to perform analysis using your electrical network. You also saw how you can create subnetworks that allow you to perform upstream, downstream, and isolation tracing. You also learned how you can adjust your subnetwork definition to take advantage of your network attributes. When you’re ready to learn some more advanced configurations, read the electrical networks advanced configuration article. If you want to know more about using the utility network to manage electrical networks, please explore the Learn ArcGIS Utility Network for Electric Utilities series. This learning series includes tutorials and articles that demonstrate how to address the needs of the electric industry using the utility network. Download and learn more about the Migration toolset and the Migrate to Utility Network tool on the Get started with the Migration toolset article. As always, if you have any questions or comments be sure to ask them in the Esri Community site! ... View more

With the Introduction of the new Migration toolset multiple paths now exist to implement a utility network. This technical article will compare each of these approaches, allowing you to make the best decision for your organization based on your requirements. If you're looking for a higher-level discussion of this topic, check out this article written about Enterprise GIS and Modern Network Information Management Systems. Let’s quickly review the approaches. Customers who only use ArcGIS Online and do not need any form of snapping/rubber banding, connectivity, or tracing can continue to use their GIS without any form of utility network (Option 1) Implement an industry specific model by migrating your data into one of Esri’s Utility Network Foundations (Option 3 in the above article) Implement an organization specific model by migrating data using the Utility Network Migration Wizard or migration toolset (Option 2 in the above article) Customers who are implement Option 3 will often use the tools associated with Option 2 to create a prototype utility network to help familiarize themselves with the utility network and evaluate the quality of their data Let’s review each of these approaches in more detail, starting with implementation using a Utility Network Foundation. Implement an industry specific model Esri’s Utility Network Foundations provide the best practice data models for representing a commodity with a utility network as well as preconfigured maps and instructions.  Utility Network Foundations are available from Esri at no additional cost and are fully supported.  Some Utility Network Foundations include two data models, an Expanded Data Model and an Essentials Data Model, that provide differing levels of data representation.  Expanded Data Models provide a robust schema with detailed asset descriptions and expansive network rules that enable an out of the box digital twin style representation. Essentials Data Models provide a simpler representation with just the minimum schema required to make a utility network function for a commodity.  Essential Data Models use less capabilities of the utility network and capture less descriptive information about assets when compared to Expanded Data Models. Customers who implement an Essentials model tend to add additional fields and asset types to the model, while customers who implement an Extended model tend to pair back the configurations in the model. Implement an organization specific model The second approach is to use the Utility Network Migration Wizard or Migrate To Utility Network tool to creates a utility network model that reflect your organization's current tables, subtypes, fields, and domains. This approach is faster and easier to start, but it means that you will need to extend this utility network through additional configuration over time to satisfy some of your business requirements. Capabilities The discussion is abstract when discussed at a high level, so we will look at some industry specific examples of capabilities and whether they are included in a particular model or whether they require configuration. As we discuss these examples, we will classify each capability using one of the following values to indicate the level of effort that is typically associated: Included – This capability is included in the model and requires no additional configuration. Low – This should take less than a day’s work to implement. It typically involves a few configuration changes. Medium – This should take a few days to a week to implement. It may require a combination of configuration and/or data manipulation to complete. High – This feature can take weeks or months to implement. It typically requires a combination of configuration, data modelling, and data manipulation/creation to complete. *– As long as the original schema contains all the required information (fields, values, etc.), no additional configuration is required. Otherwise, it is the indicated level of effort. In cases where an example of the configuration is documented, a link to the corresponding tutorial is provided. Electric The Electric Utility Network Foundation includes an Expanded Data Model and Essentials Data Model. The Essentials Data Model is only appropriate for representing unbalanced distribution networks, while the Expanded Data Model provides schema and configuration to support distribution, transmission, generation, and low voltage networks. The Migrate To Utility Network tool will automatically create feeders without additional configuration if the source classes that contain features with an ancillary role of source are configured to be controllers and the enabled field is used to represent open/closed switches. The migration toolset does not currently support creating nonspatial objects, so any unit information must be represented as related records. Capabilities Migration Toolset UN Foundation Essentials UN Foundation Expanded Snapping and Rubber Banding Included Included Included Connectivity Tracing Included Included Included Offline Editing Included Included Included Network Diagrams Medium, 1 Included Included Web and Mobile Tracing Low, 2 Included Included Feeder Management Low*, 3 Included Included Upstream/Downstream Tracing Low, 3 Included Included Protective Device Tracing Low Included Included Phase Propagation Medium, 4 Included Included Industry Specific Editing Rules Low, 5 Included Included Substation Asset Management Medium* Included Included OMS/ADMS Support Medium* Included Included Units as network content Medium Included Included Units for network connectivity High Medium Included 1 Network diagram tutorial 2 How to configure named trace configurations 3 Electrical Networks – Initial configuration  4 Electrical Networks – Advanced configuration 5 Refining connectivity rules Gas The Gas and Pipeline Referencing Utility Network Foundation includes only a single data model that is commonly referred to as the Utility and Pipeline Data Model (UPDM).  This data model configures   the utility network and ArcGIS Pipeline Referencing to represent gas and hazardous liquid pipelines as a single pipe system with both connected topology and linear referencing.  The Migrate To Utility Network tool will automatically create system zones without additional configuration if the source classes that contain features with an ancillary role of source are configured to be controllers and the enabled field is used to represent open/closed valves. Capabilities Migration Toolset UN Foundation Snapping and Rubber Banding Included Included Connectivity Tracing Included Included Offline Editing Included Included Network Diagrams Medium, 1 Included Web and Mobile Tracing Low, 2 Included Emergency Isolation Tracing Low, 3 Included Industry Specific Editing Rules Low, 5 Included Directional Flow Devices Low Included System Zones Low* Included Pressure Zone Management Medium, 4 Included Cathodic Protection Management High Included Facility Modeling High Included Pipeline Referencing Medium Included Unified Data Structure High Included 1 Network diagram tutorial 2 How to configure named trace configurations 3 Pressurized systems – Initial configuration 4 Pressurized systems – Advanced configuration 5 Refining connectivity rules Water The Water Utility Network Foundation includes an Expanded Model and an Essentials Data Model. The main difference between the two models is the Expanded Data Model includes a more detailed schema, including configuration for representing the contents of stations, cathodic protection, and district metering areas (DMA). The Migrate To Utility Network tool will automatically create water systems without additional configuration if the source classes that contain features with an ancillary role of source are configured to be controllers and the enabled field is used to represent open/closed valves. Capabilities Migration Toolset UN Foundation Essentials UN Foundation Expanded Snapping and Rubber Banding Included Included Included Connectivity Tracing Included Included Included Offline Editing Included Included Included Network Diagrams Medium, 1 Included Included Web and Mobile Tracing Low, 2 Included Included Emergency Isolation Tracing Low, 3 Included Included Industry Specific Editing Rules Low, 5 Included Included Directional Flow Devices Low Included Included Water Systems Low* Included Included Pressure Zone Management Medium, 4 Included Included Cathodic Protection Management High High Included DMA Subnetwork Medium Medium Included Facility Modeling High High Included 1 Network diagram tutorial 2 How to configure named trace configurations 3 Pressurized systems – Initial configuration  4 Pressurized systems – Advanced configuration 5 Refining connectivity rules Sewer The Sewer Utility Network Foundation includes both an Expanded Data Model and an Essentials Data Model for representing separate (non-combined) sewers. The main difference is the Expanded Data Model stops pipes at the boundary of each vault and uses nonspatial connectivity to manage the connectivity within the vault. This model is more appropriate for maintaining a high accuracy 3D pipe network. Organizations who use the digitized directions of lines will be able to use the digitized direction option when tracing to perform upstream and downstream analysis without needing to create sewersheds. The Migrate To Utility Network tool will create sewersheds automatically without additional configuration if the source classes that contain features with an ancillary role of sink are configured to be controllers. Capabilities Migration toolset UN Foundation Essentials UN Foundation Expanded Snapping and Rubber Banding Included Included Included Connectivity Tracing Included Included Included Offline Editing Included Included Included Network Diagrams Medium, 1 Medium Included Web and Mobile Tracing Low, 2 Included Included Upstream/downstream tracing Low*, 3, 6 Included Included Industry Specific Editing Rules Low, 5 Included Included Sewershed Systems Low, *, 3 Included Included Sub-basins Low, 4 Included Included Detailed manhole channels High, 3 High Included 1 Network diagram tutorial 2 How to configure named trace configurations 3 Gravity-based systems – Initial configuration 4 Gravity-based systems – Advanced configuration 5 Refining connectivity rules 6 Get started with ArcGIS Utility Network for wastewater Stormwater The Stormwater Utility Network Foundation includes only a single data model. Organizations who use the digitized directions of lines will be able to use the digitized direction option when tracing to perform upstream and downstream analysis without needing to create watersheds. The Migrate To Utility Network tool will create watersheds automatically without additional configuration if the source classes that contain features with an ancillary role of sink are configured to be controllers. Capabilities Migration toolset UN Foundation Snapping and Rubber Banding Included Included Connectivity Tracing Included Included Offline Editing Included Included Network Diagrams Medium, 1 Included Web and Mobile Tracing Low, 2 Included Upstream/downstream tracing Low*, 3, 6 Included Industry Specific Editing Rules Low, 5 Included Watershed Systems Low* Included Catchments Low, 4 Included Channel connections Low, 3 Included Best Management Practices Containment Low, 3 Included 1 Network diagram tutorial 2 How to configure named trace configurations 3 Gravity-based systems – Initial configuration 4 Gravity-based systems – Advanced configuration 5 Refining connectivity rules 6 Get started with ArcGIS Utility Network for stormwater District Energy The District Energy Utility Network Foundation includes only a single data model. The Migrate To Utility Network tool will automatically create energy systems without additional configuration if the source classes that contain features with an ancillary role of source are configured to be controllers and the enabled field is used to represent open/closed valves. Capabilities Migration toolset UN Foundation Snapping and Rubber Banding Included Included Connectivity Tracing Included Included Offline Editing Included Included Network Diagrams Medium, 1 Included Web and Mobile Tracing Low, 2 Included Valve Isolation Tracing Low, 3 Included Industry Specific Editing Rules Low, 5 Included Directional Flow Devices Low Included Energy System Low* Included Pressure Zone Management Medium Included Cathodic Protection Management High Included Facility Modeling High Included 1 Network diagram tutorial 2 How to configure named trace configurations 3 Pressurized systems – Initial configuration 5 Refining connectivity rules Communications The Communications Utility Network Foundation includes only a single data model. The Communications data model requires modeling strands and connectivity using nonspatial objects. Because the Migration To Utility Network tool doesn’t currently support creating non-spatial objects it is not possible to create a communications utility network capable of representing a communications network with connectivity. You must use a utility network foundation or partner model to implement a communications utility network. If you are only interested in modeling the location of your communication assets, but are not interested in tracing or connectivity, consider implementing one of the Telecommunications industry solutions like the Communications Data Management solution. Conclusion Now that you’ve seen the pros/cons associated with each of the approaches you are better equipped to decide which approach is appropriate for your organization. If you’re not certain of which approach to take, you should consider using the Migration toolset to create a prototype that you can use to begin exploring the utility network. This will not only allow you to begin experiencing some of the tools with your own data but also allows you to quickly identify any show-stopping data quality issues that need to be addressed before you implement your utility network in production. If you’re interested in accessing the migration toolset or want to see what additional resources are available discussing this approach, check out the Get started with the Migration Toolset article on the Esri Community site. ... View more

When you use the Migration toolset to create your own utility network, the tool creates a generic network model that is configured to help you get started as quickly and easily as possible. One of the limitations of using the Migration toolset to create a utility network is that it doesn’t include any of the industry-specific configurations found with the utility network foundations that allow your data to behave more like a real-world system. These configurations enforce strict data quality requirements that will create topology errors when your data doesn’t conform to the configuration of your network model (connectivity rules, edge connectivity policy, etc). The number of topology errors in a utility network can be found in the network properties dialog. You can expect to see more errors if you migrate your data to a Utility Network Foundation than if you use the migration toolset. These errors represent locations where the data needs improvement. So how do customers who use the Migration toolset configure their data to enforce stricter data quality requirements? You can configure your data with industry specific behaviors. Some of these configurations, like adding terminals, will impose more constraints on how you edit your data. Other configurations, like creating subnetworks, will unlock new tools you can use for quality assurance and quality control. One of the most meaningful changes you can make to your data model to improve data quality, and the editing experience, however, is to modify your connectivity rules. What are connectivity rules? Network rules in the utility network define what features are allowed to connect, attach, or contain other features. Connectivity rules are a subset of network rules which govern how network features can be connected through geometric coincidence or connectivity associations.  These rules influence the editing experience through the snapping environment and ensure the utility network specific editing tools (Modify Terminal Connections, Modify Associations, etc) only present you with valid options. When the Migrate To Utility Network tool runs it creates an initial set of rules that allow every type of junction/device feature to connect to every type of edge feature in the same domain. Each model produced by this tool is unique so the tool must allow everything to be connected. This approach is quite different from what happens if you migrate your data into a foundation model. Each Utility Network Foundation contains a known set of asset groups and asset types and includes thousands of connectivity rules that determine what and how these features can be connected. The Migration toolset contains several tools you can use to review and adjust the connectivity rules of any utility network. This process is particularly important for customers who use the Migrate To Utility Network tool to create their utility network as it allows them to quickly adjust their rules based on the connectivity in their GIS. Modifying connectivity rules The ArcGIS Utility Network has tools that enable you to remove rules from your model when you don’t want to allow certain features to connect. When new asset types are added to your model, tools also exist to add rules to your model that define how these new features are allowed to connect to the existing features in your model. Connectivity rues can be found in the network properties dialog Given that most utility networks include hundreds or even thousands of connectivity rules, any process for reviewing them is going to take time. Making decisions about what things are allowed to connect requires a knowledge of the GIS model and drawing standards, but it also requires an operational understanding of the types of equipment being modeled and what configurations are possible in the real world. What materials are allowed to connect at an expansion joint? Removing a connectivity rule indicates that the features can never be connected in the GIS. Before you remove a rule, you need to confirm there are no instances of that connectivity in your GIS as well as in the real world. Never underestimate the creativity of a field crew working to make repairs to a system during an emergency! With this information in mind, there are two things to consider before we make changes to rules: What types of features are connected in the data? Which types of features should be allowed to be connected? Are any of the invalid connections outliers that need to be allowed? Fortunately, the Migration toolset contains tools that can help you answer these questions. Analyzing existing connectivity Identifying what types of features are coincident to create a set of rules based on that analysis sounds like a relatively straightforward spatial analysis question. Depending on how technical you are, it could take anywhere from a few weeks to a few months to build the scripts and tools to achieve this goal, excluding time spent with subject matter experts deciding on a final set of connectivity rules. However, the Analyze Network Data tool in the Migration toolset can do all this work for you in just a few minutes. Analyze your network data to identify topology errors. Note: For this process to work correctly, you must analyze a utility network that doesn’t have any junction-edge and edge-junction-edge rules configured. The Analyze Network Data tool analyzes your data for common topological errors that need to be corrected, including features that are spatially coincident and not allowed to connect. When you use a model built by the Migrate To Utility Network tool this isn’t a problem you will encounter because of the rules that are created between all junction and edge features. However, if you were to create a copy of your utility network without any junction-edge or edge-junction-edge connectivity rules for connected features, the tool will report a connectivity error for all the features that are spatially coincident. The error summary layer shows you topology errors in your data. Note: Do not make these rule changes directly in production. You should copy your data to a local file/mobile geodatabase and test your configuration there due to the iterative and disruptive nature of this analysis. This report allows you to quickly identify what kinds of features are connected, how many of each type of connection exists, and where these are in your data. This information can then be reviewed with subject matter experts like engineers, field crews, and operators to make informed decisions about what should be allowed to be connected. The Error Summary layer shows you all the locations in your network where you have errors. If you still have a question about whether something should be allowed to be connected, the final arbiter of that decision is always reality. Because the locations layer contains features for all the connectivity issues, this layer can be shared with field crews to verify any locations in the field you have questions about. Individual features from the Error Location layer can be shared with others for quality assurance and data correction purposes. Creating Rules Once you’ve identified what types of features you want to be connected, your next task is to add the supporting rules to your network. This ensures that only features with rules can be connected, as any features attempting to be connected without a corresponding rule will be reported as topology errors. Manually adding all these rules would be a tedious task. Fortunately, the Analyze Network Data tool creates a CSV file of rules that can later be imported into a utility network. You should modify this CSV file as part of the error review process with your subject matter experts to only include rules for features you agree should be connected. A screenshot of a sample CSV file created by the Analyze Network Data tool. Once the CSV file has been modified to contain only the approved rules, you can apply it to your utility network using the Import Rules tool. After importing rules and enabling the network topology your data will be connected using the newly imported rules and topology errors will be generated for any features without a supporting rule that are not allowed to connect. Conclusion Use the Import Rules tool to import many rules into your utility network at once. In this article you learned about the importance of connectivity rules to data quality, and how you can refine your connectivity rules using spatial analysis and the tools available in the Migration toolset. Reviewing and adjusting your rules is an effective way to document and understand your model while also improving your data quality. With these new rules you will only be able to ensure that connectivity only exists between features that have been approved to connect. If you attempt to connect any other types of features, the utility network will generate an invalid connectivity topology error. Refining your connectivity rules is an optional part of configuring and deploying a utility network, but it’s a worthwhile time investment to perform with your data before you go live. Not only will this help you refine your connectivity rule and resolve any outliers, but it can often cut the number of rules in your model in half! However, don’t think you need to follow this process every time you want to change the rules. If you are making minor adjustments to your connectivity rules to account for small schema or business process changes you should use the Add Rule and Delete Rule tools. Try the Configure rules for a utility network tutorial if you are interested in learning more about maintaining the rules of a utility network. For more information about the migration toolset, including how to access them, read the Get Started with the Migration toolset article on the Esri Community Site! You can not only ask questions there, but you can download these tools and find additional resources covering topics like configuring your own model and data migration. ... View more

In the Analyzing topology errors article we showed you how you can use the new Analyze Network Data tool to identify topology errors in your utility network data. In this article we will show you how you can use the resulting database and the Apply Error Resolutions tool to resolve the topology errors the tools discovered. Sample workflow for identifying and resolving topology errors. The Apply Error Resolutions tool is best used during the data migration process, before the network topology has been enabled and before data has been loaded into an enterprise geodatabase. This tool must be run on a utility network with a disabled topology. The tool can be used to apply resolutions against data that has been loaded into an enterprise geodatabase if the data is not registered as versioned, and the tool is run as a user that has permissions to edit the corresponding feature classes using the database connection. While there can be many causes and resolutions for each error, this article will discuss the most common approaches to addressing each error along with resources you can use to help you determine the most appropriate path forward. The errors in this article are listed from most common to least common, for the errors that the Analyze Network Data tool can identify. For more information on why Analyze Network Data only supports certain errors, read the Analyzing topology errors article. Errors with no automated resolutions are included in this article with references to additional resources which can help you resolve the errors. Topology Errors Below you will find a summary of the different types of errors the tool can detect. Topology Error Description Actions Available Ambiguous connectivity  This occurs when there is more than one rule available for a potential connection. None Duplicate vertices  This occurs when a line has two or more duplicate vertices. Delete (Vertex) Empty Geometry  This error occurs when a line feature has a zero or near-zero length. Delete (Feature) Edge connectivity policy  This occurs when a line has a connection that violates its edge-connectivity policy. None Invalid terminal  This occurs when the from terminal id or to terminal id field of a line is not valid for one of the devices/junctions its connected to. None Midspan terminal device  This occurs when a device that has a terminal configuration is drawn midspan on a line. None Missing junction  This occurs when two features with a different asset type are connected without a junction or device. Create Rule missing  This occurs when two features are potentially connected but there is not a rule that permits it. None Self-intersecting line  This occurs when the geometry of a line intersects itself. Delete (Vertex) Shape length  This error occurs when a line feature has a zero or near-zero length. Delete (Feature) Stacked points  This occurs when two or more junctions or devices are within a tolerance (xy) and occupy the same z location. Delete (Feature) Update (Feature) Subnetwork tap  This error occurs when a feature with the subnetwork tap category is drawn at the end point of a single line or at the endpoint intersection of two lines. None Vertex within tolerance This error occurs when two or more vertices are within the spatial tolerance of the dataset but not topologically coincident. Anchor Snap Note: There are two delete actions: Delete All and Delete All But First. The table above lists both these actions as simply Delete, because either action is appropriate. Additionally, the table above specifies whether the delete applies to the entire feature or just the vertex in error even though this information isn't specified in the action. When reviewing errors using the attribute table, consider changing the row height of your table so you can see all the asset types on an error. You can change this by going to Project > Options > Table > Columns and rows > Row Height and set it to triple or double. Increase the row height of the attribute table if you plan to review errors using the attribute table. Otherwise consider using the attributes pane.  Error Resolutions Manually cleaning up data is something that many customers do in preparation for their data migration. However, certain errors lend themselves better to automated cleanup, or you may decide that for your first attempt at migrating to the utility network you want to quickly apply automated fixes to your data. Regardless of the reason for your decision, you can specify automated resolutions to your data using the Error Resolutions table. The Error Resolutions table has the following columns: Error code – The error identified at the location Analysis types– A concatenated list of all the features present at that location. Resolution key – An ID that uniquely identifies the error associated with the fix Group position – When multiple types of features are present at a location, this gives the order they were encountered Feature type – The network class, asset group, and asset type of the feature in this location Source class – The utility network layer the fix will be applied to Asset group – The asset group of the feature the fix will be applied to Asset type – The asset type of the feature the fix will be applied to Context – Whether the feature at this location represents an error, or a feature coincident with the error Action – What action to apply to this feature to resolve the issue, if any Delta X – How much the feature should be offset in the x direction Delta Y – How much the feature should be offset in the y direction Delta Z – How much the feature should be offset in the z direction Delta step – If there are multiple features offset at this location, how much each subsequent feature should be offset Create/Update type – The class, asset group, and asset type to use for creating a new feature or updating the existing feature. Actions The following table describes the actions available for each fix. Action Description Create This action will create a new feature. When this action is selected you must specify the type of feature using the Create/Update type field. Update all Update all but first This action will update the corresponding vertex or feature(s). If there are multiple features associated with the fix you can choose to update all the features or update all of them but the first feature.   When updating the feature(s) you can use this action to update the location of a feature using the delta x, y, z, and step fields. When there are multiple coincident features make sure you specify a delta step value to ensure each subsequent feature is offset from the previous feature.   You can also change the asset group and/or asset type of a feature using the Create/Update type field. Delete all Delete all but first This action will delete the corresponding vertex or feature(s). If there are multiple features associated with the fix you can choose to delete all the features/vertices or to delete all of them but the first feature/vertex. Anchor Snap These resolutions are used to resolve the Vertex within tolerance error. They allow one vertex to be designated as the anchor location and the remaining vertices can be snapped to that location. When reviewing the fixes for an error you will often see multiple rows with the same Resolution Key. Each of these rows either represents one of the features in error or a feature that is coincident with the feature in error. When specifying an action, you will almost always be applying the fix to one or more of the error features. If there are multiple error rows for the fix, you will need to think carefully about which feature you apply the fix to. Once you’ve determined the fixes for all the issues you want to automate, you’re ready to apply the resolutions. Any remaining issues will need to be resolved manually. The manual resolution process can be facilitated by using the location features in the diagnostics database. Examples What follows is a series of examples of resolutions and actions for each topology error. Missing junction This error occurs when two features with a different asset type are connected without a junction or device. Each error indicates whether it occurs between the midpoint or endpoint of each line. For two lines to be connected the endpoint of one line must connect to the endpoint, or midspan, on the other line. Missing junction errors are described in three different ways: End/End - The endpoints of two separate lines are coincident. If no junction is created there will be an error in the utility network. This error is typically resolved by creating a feature at the endpoint of the two lines to connect the two features. Mid/End - The endpoint of one line connects midspan to another line. If no junction is created there will be an error in the utility network. This error is typically resolved by creating a feature on the endpoint of one line that taps into the second. Mid/Mid - The two lines share midspan vertices. These lines are not connected and do not report any errors in the utility network. They are reported for informational purposes. This screenshot shows an example of an end-end and a mid-end error Midpoint/midpoint coincidence, shown as mid-mid, situations are included for informational purposes only since these features are not considered for connectivity and will not create errors. You do not need to apply resolutions for mid-mid missing junction errors to have an error free topology. These errors are filtered out from the layers using definition queries but are visible if you look at the table directly or remove the definition queries. This screenshot shows a missing midspan junction issue. These issues don't create topology errors in the utility network, but some datasets may not want to allow this style of connectivity. The most common resolution to missing junction errors is to create a junction feature at the intersection of the two lines. To perform this resolution, look at the resolutions for the error, you will see at least two different line types in the list. Select only one of the resolutions, set its action to Create, and pick the Create/Update type of the point feature you want to create at that location. Use the Create action on one of the resolutions to create a junction to allow the features to connect. Be sure to select an asset type that is allowed to connect to all lines present at that location. Additional Resources Address common errors in the utility network (article) Utility Network Error management – Topology Errors (article) Utility Network Error Management – Electric topology errors (article) Utility Network Error Management – Gas and Pipeline Topology errors (article) Utility Network Error Management – Water topology errors (article) Fix connectivity errors in a utility network (tutorial) About error features (online help) Stacked points This occurs when two or more junctions or devices within the xy tolerance and the same z location. The records in error will indicate which kinds of features are stacked, if only a single type is listed then there are multiple instances of that feature stacked at the location. The group key column will indicate the types of lines, if any, present at that location and can help you understand how to best resolve the error. Stacked point features are a common problem that must be resolved with care to ensure features are correctly connected to the network after being unstacked The most common resolution to this error is to leave one feature in place and delete or offset the remaining features. To perform this resolution, find all the point features for the error in the Error Resolutions table. Identify the feature you want to keep and set its action to Update all but first or Delete all but first. Use the delete all but first action where all the stacked points have the same asset types If there are different types of point features that are stacked, set the action to the other point resolutions to be Update All or Delete All. If multiple asset types are stacked you must use a combination of update/delete all and update/delete all but first. This will ensure that only one feature remains connected to the network at the current vertex. Using the Delete action is an easy fix but is not commonly used during production migrations. Production migrations typically use the Update all and Update all but first actions with an xyz offset to keep the original features for review later. If you are offsetting multiple types of point features, make sure their offsets are configured such that they don’t create stacked point features at the new offset. If there are more than 2 features being offset, ensure you also specify a Delta Step value to ensure that subsequent stacked features are continually offset. Use Update all and Update all but first when you want to unstack point features without losing data. The moved features will become disconnected from the network, but will no longer create topology errors. Additional Resources Address common errors in the utility network (article) Utility Network Error management – Topology Errors (article) Utility Network Error Management – Electric topology errors (article) Utility Network Error Management – Gas and Pipeline Topology errors (article) Utility Network Error Management – Water topology errors (article) Fix topology errors in a utility network (tutorial) About error features (online help) Self-intersecting line This occurs when the geometry of a line intersects itself. The error location feature will indicate the specific vertex where the line intersects itself and the group key column on the error summary will indicate if there are other features present at that location. It is important to take note of how many different types are listed in the records in error column, because this will determine how you apply resolutions to the fix. Self-intersecting lines can be difficult to identify manually, but the analyze network data tool reports the specific vertices that cause the self-intersection. The most common resolution to this error is to delete the vertices responsible for the line intersecting itself. If there is only a single type in the records in error column, find the line for the error in the resolutions table, and set its action to Delete all but first. The most common resolution to self-intersecting lines is to delete the vertex that causes the self-intersection.   If there are multiple resolutions with the same type in the records in error column then you will need to set one of the types to Delete all but first and set the remaining types to Delete all. This occurs when a self-intersecting line occurs at the start or end vertex of a feature, resulting in both a mid and end vertex being reported as being in error. The most common resolution to this issue is to set the resolution to the midspan vertex to delete all and set the resolution to the end vertex to delete all but first. This will preserve the endpoint of the line while removing the vertices inside the line causing self-intersection. Additional Resources About error features (online help) Tools for checking and repairing geometries (online help) Duplicate vertices This occurs when a line has two or more duplicate vertices within xy tolerance and at the same z value. The error location feature will indicate the specific location of the duplicate vertices and the group key column on the error summary will indicate if there are other features present at that location. Duplicate vertices are often the result of a digitization error, pay attention to any nearby features when resolving these errors.   The most common resolution to this error is to delete the duplicate vertices. To perform this resolution, find the row for the error in the fixes table and set the action on all the line features to Delete all but first. When the error resolutions are applied this will delete all the duplicate vertices for the features specified, while leaving the unique vertices for the line intact. The most common resolution to duplicate vertices is to delete the duplicate vertices    Additional Resources About error features (online help) Tools for checking and repairing geometries (online help) Empty Geometry This error occurs when a line feature has an empty geometry. The only automated resolution to this error is to delete the feature, since an empty geometry cannot be updated. Empty geometries are an uncommon error as most systems prevent you from creating features without a geometry. The most common resolution to this error is to manually draw the geometry of the feature, if you can identify its location. If you wish to automatically delete this feature through an action in the error resolution tool, find the row in the Error Resolution table with this error code and set its action to Delete all. The most common resolution to an empty geometry error is to delete the feature using the Delete all action.   Additional Resources About error features (online help) Tools for checking and repairing geometries (online help) Shape length This error occurs when a line feature has a zero or near-zero length. Invalid shape length errors occur when a line feature's start/stop vertex are identical or nearly identical.   The most common resolution to this error is to manually redraw the line to correct the geometry. If you wish to automatically delete this feature through an action in the Error Resolution table, find the row in the table with this error code and set its action to Delete all. The most common resolution to this error is to delete the line feature.   Additional Resources About error features (online help) Tools for checking and repairing geometries (online help) Midspan terminal device This occurs when a device that has a terminal configuration is drawn midspan on a line. When a device has terminals it must split the line it is connected to, otherwise a topology error will be created.   The most common resolution to this issue is to split the line at the location where the device is connected. The tools cannot currently apply an automatic resolution for this problem; however, you can use the By Feature mode of the Split tool to split multiple features at once. There is no action available to automatically split lines. If you want to split the lines you must use the Split tool in ArcGIS Pro.   One of the most precise ways to identify the features that need to be split is to use the Select By Location tool with the Relationships: Contains Clementini and Within Clementini. Use the Select By Location tool to limit the split operation to lines that need to be split.   Additional Resources Utility Network Error management – Topology Errors (article) Utility Network Error Management – Electric topology errors (article) Utility Network Error Management – Gas and Pipeline Topology errors (article) Utility Network Error Management – Water topology errors (article) Fix topology errors in a utility network (tutorial) About error features (online help) Ambiguous connectivity This occurs when there is more than one rule available for a potential connection between features. This kind of error is not common when using the Migrate To Utility Network tool unless you add rules to your network and/or change an asset type’s terminal configuration. Am Ambiguous connectivity happens when there are multiple rules that allow features to connect, like when a device has multiple terminals.    The most common cause for this error is a line connected to a device with terminal with multiple rules, in which case the resolution is to specify which terminal the line is connected to using the Modify Terminal Connections pane. There is no action to automatically resolve ambiguous connectivity errors, but you can use the Modify Terminal Connections pane to manually resolve the issue.    Note: When modifying the terminal connections of a line always use the Modify Terminal Connections pane, as it will ensure you only select terminals that are valid for the line based on the devices on either end of the line. If you modify terminal connections using the attribute editor or the attributes pane you run the risk of introducing Invalid Terminal errors. If you have many of these errors, consider using the Assign Terminal Connections tool in the Utility Network Package Toolbox to calculate terminal connections for all the features in the network. Terminals are assigned without respect to any attribution or flow, so while this tool will resolve topology errors, you will need to review and adjust the connections for any devices with a directional terminal configuration. Additional Resources Address common errors in the utility network (article) Utility Network Error management – Topology Errors (article) Utility Network Error Management – Electric topology errors (article) Utility Network Error Management – Gas and Pipeline Topology errors (article) Utility Network Error Management – Water topology errors (article) Fix connectivity errors in a utility network (tutorial) Configure rules for a utility network (tutorial) About error features (online help) Rule missing This occurs when a point and line feature are potentially connected but there is not a junction-edge rule that permits it. This kind of error is not common when using the Migrate to utility network tool unless you add a new asset type without adding a corresponding rule, remove existing rules, or change an asset type’s terminal configuration. This check does not take into consideration any edge-junction-edge rules that you define in your database. Missing rule errors occur when two features are attempting to connect in the utility network, but there is not a rule that allows them to be connected.   If the two features should be allowed to connect, then the resolution is to add a rule allowing them to connect. You can see a list of all candidate junction-edge rules that can be imported in the RuleCandidates.csv created alongside the analysis results database. Be sure to review the rules file before importing it to ensure that all the rules are correct for your data and to ensure you do not unintentionally introduce ambiguous connectivity. This is especially important if you have any edge-junction-edge rules already configured. Use the Import Rules tool to import the rule candidates CSV file created by the tool.    If the two features should not be allowed to connect, ensure the features have the correct asset types and are drawn correctly. You can achieve this by either manually changing the feature’s asset group and asset type, or by using the Update all action in the resolution table to automatically correct the asset types of all the affected features. You can use the Update all action to update the asset type of features if you determine that they are improperly classified.   If you want to learn how to modify your connectivity rules to improve data quality, read the refining your connectivity rules article (coming soon!) Additional Resources Address common errors in the utility network (article) Utility Network Error management – Topology Errors (article) Utility Network Error Management – Electric topology errors (article) Utility Network Error Management – Gas and Pipeline Topology errors (article) Utility Network Error Management – Water topology errors (article) Fix connectivity errors in a utility network (tutorial) Configure rules for a utility network (tutorial) About error features (online help) Refining your connectivity rules (tutorial) Invalid terminal This occurs when the from terminal id or to terminal id field of a line is not valid for one of the devices or junctions it is connected to. This kind of error is not common when using the Migrate To Utility Network tool unless you manually assign terminals without using the Assign Terminal Connections tool. The invalid terminal error occurs when a line is connected to a device that has terminals, but it references a terminal that does not exist.   The most common resolution to this error is to update the terminal on the line to a valid value using the Modify Terminal Connections pane. Use the Modify Terminal Connections pane to manually resolve any invalid terminal IDs. The UI will only show valid terminal connections for the features.   Additional Resources Address common errors in the utility network (article) Utility Network Error management – Topology Errors (article) Utility Network Error Management – Electric topology errors (article) Utility Network Error Management – Gas and Pipeline Topology errors (article) Utility Network Error Management – Water topology errors (article) Fix connectivity errors in a utility network (tutorial) Configure rules for a utility network (tutorial) About error features (online help) Edge connectivity policy This error occurs when a line with edge connectivity policy of End Vertex has a line, junction, or device connected to one of its midspan vertices. Models created by the Migrate To Utility Network tool have a default connectivity policy of Any Vertex. If you encounter this error, you must either redraw the line, the features connected to the line or change the connectivity policy for the edge in error. Additional Resources Fix topology errors in a utility network (tutorial) Configure rules for a utility network (tutorial) About error features (online help) Subnetwork tap This error occurs when a feature with the subnetwork tap category is drawn at the end point of a single line or at the endpoint intersection of two lines. This kind of error is not possible when using the Migrate To Utility Network tool unless you manually assign the subnetwork tap category to an asset type. Subnetwork tap features have certain cartographic requirements that must be met. Resolving this issue requires you to make a choice about whether a feature should be a subnetwork tap, and how it should be drawn within the system.    If the junction or device feature is improperly classified, you can use the error resolution table to correct its asset group and asset type. Otherwise, you must manually resolve this error by adjusting the location of the junction/device, so it is no longer at the endpoint of both lines. You can learn more about the topological requirements of subnetwork taps by reading the additional resources below. Additional Resources About error features (online help) Subnetwork taps (online help) Vertex Within Tolerance This error occurs when two or more features have common vertices that are close enough to each other to be considered coincident with a spatial query, but not close enough to be consistently topologically connected. It is recommended that these features be snapped to share a common location to ensure they are consistently connected and traceable. Vertex within tolerance errors do not create topology errors, but can result in inconsistent behavior during validate network topology that may result in features becoming disconnected. This issue will not be reported if there are other errors, like stacked point features, present at the same location. Note: If there is only a single resolution available for this error summary that means there are multiple features, or vertices, at that location. In this case you should set the resolution to anchor. This will use the first object in the resolution as the anchor and the remaining objects for that resolution will be snapped. Set the action of one of the resolutions to anchor and the remaining resolutions to snap. This will snap all the vertices to a common location to resolve the error.   Additional Resources None ... View more

With the release of the new Migration toolset for the utility network this provides a good opportunity to review how these new tools can be incorporated into existing best practices for implementing a utility network. In this article we will be discussing some of the best practices for using the tools, along with links to resources where you can learn additional information. You can also find a similar discussion in the Migrate existing data into a utility network topic in ArcGIS Help. Before we talk about the new tools, let’s do a quick recap of the existing best practices for implementation. This is an abbreviated version of the best practices outlined in the Utility Network Data Migration: Best Practices article. Historical tools and models Prior to the release of the utility network migration toolset, migrating to the utility network meant you needed to use the Utility Network Package toolbox along with a pre-defined data model (asset package), such as those provided with Esri’s Utility Network Foundations. Data could then be migrated into the asset package using the Data Loading toolset, or any other data migration tool or process you wanted to build. As more customers began using the data loading tools, the ArcGIS Solutions team released the Create Simple Data Mapping and Create Migration Workspace tools to make the process of creating a data loading workspace easier. These tools act as a utility network specific front end to the Data Loading toolset. If you’re interested in learning more about these existing tools and models, check out the ArcGIS Utility Network migration reading list. Once you understand the concepts, you can test your knowledge by trying one of the following tutorials: Load data into a utility network (water) (learn tutorial) Electric transmission data loading (ArcGIS Solution tutorial) Electric unbalanced distribution data loading (ArcGIS Solution tutorial) Sewer data loading (ArcGIS Solution tutorial) Stormwater data loading (under development) Water distribution data loading (ArcGIS Solution tutorial) Historically, quality assurance has been performed on your source data using ArcGIS Data Reviewer., Error analysis and error remediation workflows relied on manually reviewing errors created by the utility network, requiring a combination of manual edits and creating data cleanup scripts to resolve. The ArcGIS Solutions team released the Utility Data Management Support toolbox which includes several tools to make the process of reviewing (Summarize Utility Network Errors) or resolving some errors (Assign Terminals) easier, but it was still a largely manual process. With history out of the way, let’s now discuss how the tools available in the new Migration toolset can supplement or replace some of these processes. Migration toolset The new migration toolset for the utility network includes tools focused on automating the migration to the utility network by creating a utility network that is based on your existing layers and fields. You can learn more about how this tool works by reading the Introducing the Migration toolset for the utility network article and the Building a utility network article. To summarize the previous articles, the approach of the migration tools is quite different from what has come before and has several important implications. The biggest positive is that you maintain the subtypes, fields, and domains of your existing GIS features. The downside to this approach is that, because you are not implementing a known model that comes pre-configured for a specific set of industry workflows, you bear the responsibility of configuring your utility network model to behave the way you want. Some customers may prefer this approach; however, it does mean that, instead of time spent focused on the translation of your data to conform to an industry standard model, you will be spending time focusing on configuring these same behaviors in your organization’s model. Every time the Migrate To Utility Network tool runs, it creates a new mobile database. This begs the question of what to do when you’ve spent time configuring your utility network and need to refresh the data? You can use the Data Loading toolset to remigrate your data without losing any configuration or schema changes you’ve made. Let’s look at how the Migration toolset and the Data Loading toolset interact with each other. Data Loading workspace In addition to creating a mobile database containing a utility network, the migrate tool also creates a data loading workspace. A data loading workspace is a collection of files used by the Data Loading tools to migrate data from one schema to another. Example output from the Migrate to Utility Network tool. This allows you to re-run the data migration of your source data into the data model that was originally created by the tool. The Load Data Using Workspace tool in the Data Loading toolset allows you to rerun your data migratoin whenever you want. The main benefit of this approach is that it allows you to keep the configuration changes you’ve made to your model, while still being able to refresh your data. However, this approach does have some limitations. When you run the Load Data Using Workspace tool it must remove any existing data from the database. If you have enabled subnetwork controllers or created associations in your data, then these must be removed before the tool can delete the corresponding data. There are two ways around this. We will discuss the first approach in this section. The first step to creating a repeatable migration is to run the migration tool with the Load data parameter unchecked. (it is checked by default). This will create a data model (referred to in this article as a template) and a data loading workspace containing data mappings that can be used to remigrate your data. You can then keep a copy of this empty database to use for data loading purposes. Run the Migrate To Utility Network tool with the load data option unchecked to create an empty geodatabase with your schema.  Once you’ve loaded data and made configuration changes these can be incorporated into your data migration process. Associations and subnetwork controllers can be exported or imported using the Export Associations, Import Associations, Export Subnetwork Controllers, and Import Subnetwork Controllers geoprocessing tools. Any configuration changes you’ve made during your data migration can be applied to your template geodatabase as well. Exporting subnetwork controllers and associations allows you to save any utility network data you manually created for re-use in subsequent migrations.  If you make any other schema changes to your geodatabase you will also need to apply them to your template. Depending on what has changed, you may need to adjust the field values or translations of your data loading workspace. You can learn more about this in the data loading workspace concepts topic in the online help. This approach can take you quite far; however, note that if you decide to push the limits of the data model and its configuration, you will find certain types of changes are not allowed. The most common example is you are not allowed to remove or rename asset groups or asset types. So how can you deal with this limitation? This is where the second approach comes in. To discuss the second approach, we must first discuss the history of data migration projects for the utility network and specifically discuss asset packages. Asset Packages The first data migrations built for the utility network required you to create and configure your network from scratch. Because this was a time-consuming process Esri developed a set of tools in the Utility Network Package toolbox to help streamline this process. These tools allow you to create and manage a specially structured file geodatabase called an asset package. An asset package is a specially formatted file geodatabase that contains the geodatabase schema (tables, subtypes, fields, domains) and tables that define the schema and configuration of the utility network being created. Another set of tools then reads this specially formatted database, using it as a template to create and configure a geodatabase and utility network matching that schema. However, an asset package isn’t just a schema, it also contains data. Any data loaded into the geodatabase tables is appended to the corresponding tables of the newly created geodatabase. The asset package also allows you to populate the utility network system tables for subnetwork controllers and associations by populating several specialized tables in the asset package. This is a powerful approach, but how does it apply to the migration toolset? The Utility Network Package toolbox contains a tool that allows you to export an existing utility network with all its configurations to a new asset package. This means that, once you reach the end of a prototype/pilot phase using a model that was created with the Migrate To Utility Network tool, you can use the Export Asset Package tool to turn it into an asset package for re-use in subsequent migrations. Use the Export Asset Package tool to turn your utility network into an Asset Package you can use to create a repeatable data migration.   Once you’ve exported your utility network configuration to an asset package, you then need to update the data loading workspace to point to the new asset package. This approach allows you to adjust the model, reload data to the asset package using the Data Loading toolset, and use the Asset Package to Geodatabase tool to deploy the asset package to a new utility network. Use the Asset Package To Geodatabase tool to turn an Asset Package into a utility network.  Smaller and simpler projects may not need to take this approach, but for larger, multi-month projects this allows you to iteratively develop and refine your data migration over time while still using a model produced by the migration toolset. Conclusion An overview of the data migration process. To recap, the primary purpose of the Migrate To Utility Network tool and the Migration toolset as a whole is to provide customers with a straightforward path to the utility network from their current geodatabase. However, as we all know, what can start as a simple project can sometimes evolve over time into something more involved, which is why these tools can be integrated into existing best practices for utility network migration to suit your needs. In this article you learned how you can overcome the most common migration challenges using existing Esri tools. This knowledge should prepare you to handle any challenges that may arise in your journey and, even if you don’t need to employ any of these techniques right now, it’s good to know they exist should they be needed in the future. Check out the Get Started with the Migration toolset article for more information on how to access these tools and find additional resources covering topics like configuration, data cleanup, and data migration. ... View more

  Update: All data migration resources for the Migration toolset, Utility Network Foundations, and all surrounding best practices have been consolidated to the ArcGIS Utility Network migration reading list. Please use that article going forward. The main purpose of this post is now to provide users with access to a version of the Migration toolset for use with ArcGIS Pro 3.3. Update: ArcGIS Pro 3.5 now includes the Migration toolset as well as the Utility Network Migration Wizard. The content in these articles is still relevant, however the tools no longer require a separate download and can be found in the Utility Network Toolbox in ArcGIS Pro. If you have questions, please ask them in the ArcGIS Utility Network Questions community. The Migration toolset is a new set of tools designed to migrate network data stored in a geodatabase to the new utility network dataset You can read more about these tools in the Introducing the utility network migration toolset article. The tools will be officially released as part of the ArcGIS Pro 3.5 release; however, the tools are being made available in a standalone format ahead of this release to support customers who use ArcGIS Pro 3.3.    Screenshot of the Utility Network Migration toolbox for ArcGIS Pro 3.3 You can download the tools along with the help documentation for the tools using the link at the bottom of this post. Additional resources Over the next two weeks we will be publishing articles describing how to use these tools and make use of the models they product. If you subscribe to this page, you can be notified every time we make a change. Introducing the Migration toolset Utility Network Migration Wizard (video) Utility Network Migration Wizard (tutorial) Building your utility network Choosing the right model for you Analyzing topology errors Resolving topology errors Refining your connectivity rules Migrating data to the utility network Deploying a utility network with the Migration Toolset Deploying a Utility Network Foundation Deploying a utility network to ArcGIS Enterprise Creating and sharing maps for utility network data Helpful Utility Network Links Electric Learn ArcGIS Utility Network for electric utilities Basic electrical network configuration Advanced electrical network configuration Gas and Pipeline Learn ArcGIS Utility Network for gas and pipeline Basic pressurized network configuration Advanced pressurized network configuration Water Learn ArcGIS Utility Network for water utilities Basic pressurized network configuration Advanced pressurized network configuration Wastewater/Stormwater Learn ArcGIS Utility Network for sewer and stormwater Basic gravity network configuration Advanced gravity network configuration If you have questions about these tools, or anything else ArcGIS Utility Network related, please ask them in the ArcGIS Utility Network Questions community. ... View more