Geometric networks for water utilities

Whether you are implementing GIS in your water, wastewater or stormwater utility and creating a data model for the first time or you are updating your existing GIS datamodel, you will no doubt ask yourself this question –

How should I model my utility’s asset in a geometric network and why should I use a geometric network?  You should model a Geometric networks can enable utility system tracing, error checking, and better productivity while editing.

But how should I build it.  That one simple question spawns many sub questions.  Should I use complex edges, what edge to junction or edge to edge rules should I implement?  What are weights?  Should I worry about cardinality?  We get these questions or have this conversation all the time with utilities and partners. 

Below, you will find information and some guidance to help you answer these questions.  Also, we always recommend that you read through ESRI’s webhelp as a starting point on geometric on networks:

http://webhelp.esri.com/arcgisdesktop/9.3/body.cfm?tocVisable=1&ID=6764&TopicName=What%20is%20a%20geometric%20network?

First, you will need to create your network.  When creating your network, you have a few options.  The most important are choosing which layers participate in the geometric network and what layers, if any, are sources or sinks.

So what layers should you include in your geometric network?  Keep in mind that the geometric network should encapsulate how your distribution or collection systems actually operate.  So include only layers that participate in the logic network – or to think of it another way the layers that include assets that determine how your collection or distribution system function.

These typically are mains, valves, fittings, hydrants, laterals, virtual lines, manholes, catch basins, etc.  Since the geometric network should only contain layers that affect the network, a change in geometry or information can affect analysis on that network.  Data like Leaks, or SCADA sensor locations, are operational data sets.  It is showing some incident on the network or some value or reading of the network.  So these operational layers should be included in the operations dataset and not in the geometic network.

In order to create a geometric network, you’ll need to have a feature dataset which contains all of the feature classes for that network.  You’ll also need at least the ArcEditor level of ArcGIS Desktop.  When prompted to build the geometric network from existing features or  an empty network or to create an empty network, you’ll typically choose the first option.

After you determine the layers that should be part of your geometric network, you need to think about how you are going to model flow.  When setting sources or sinks, make sure to only set one of these.  This is critically important, and a mistake that we see all too often.  Do not set one feature as source and another as sinks.  You only need one and having both in a geometric network for water, wastewater or stormwater will lead to odd network behaviors.  Typically the NetworkStructure feature class or similar feature class containing a relatively small number of points is used.  While creating the network you don’t specify whether it is a source or sink just that it could be one or the other.  This adds a field called AncillaryRole to any feature classes you specify.   Later, in ArcMap you can set the value of this field for individual features to source, sink or none.  These values can be used to establish flow direction for the non-looped portion of your network.  You could instead choose to use the digitized direction of your lines to establish flow direction, in this case sources and sinks are not used.  

After the geometric network has been created, you need to set up the core properties of the network. 

Let’s first think about complex edges versus simple edges.  This is an easy one to make a decision on. In a geometric network, a simple edge must be split at every junction, so every valve, manhole, fitting, etc, on an edge, splits that edge.  Complex edges allow one segment to have many junctions on top of it and it does not require that segment to be split.  And by split, I mean separate records in the geodatabase.  Usually, complex edges only are used on your mains and laterals for water, sewer, and storm.  This allows you to model your segments by the method defined by your utility – meaning that there is no standard industry definition for what a “pipe segment” is and we often see utilities making a conscious decision for how they want to define a pipe segment and use that definition across all of their operation and business systems.  We have seen people model laterals as simple edges.  Typically, simple edges are used here because the lateral and the connection point (meter, service connection)  is a representation of the actual meter and lateral.  The representation allows you to perform tracing through the network to the meter and connect the meter id to a billing or customer system. 

Next we need to determine whether to set connectivity rules.  Keep this in mind – if you set just one connectivity rule in your geometric network and wish to use the validation tools, then you need to set up all the rules.  This can be a complex process to figure out how all your assets connect in every situation-.  Despite being complex to implement and maintain, there are certainly large benefits to using connectivity rules.

Connectivity rules allow you to model the logic connection of your network.  To support all connection types, you need to make sure your datamodel will support this.  Connectivity rules can leverage a geodatabase design element called subtypes. Subtype allow more complex modeling of your data so that within a feature class, features are assigned to a subtype which may have different default values, different domains, and different connectivity rules than the other subtypes within that feature class.  The example template geodatabase is simplified and doesn’t include any subtypes.  This means that for connectivity purposes a fitting is just a fitting not a tee, bend, or cap.  Likewise for connectivity purposes a lateral line is just lateral line not a hydrant lateral or service lateral.  With a more detailed design which includes subtypes you can make more extensive use of connectivity rules.  That is you could have a rule that says a hydrant must connect to a hydrant lateral line and that a hydrant lateral line must connect to one hydrant.  You could also specify that a hydrant feature be added by default at the free end of a hydrant lateral and that a tap fitting be placed automatically where the lateral line connects to the main.  You could set up a similar set of rules for service lines and meters. 

Within connectivity rules, there is an option to set cardinality.  So you can go beyond just how your assets can connect and you can define how many assets can connect to each other.  Let’s think about fittings again, with subtypes for fittings, you could specify that a tee fitting must connect to 3 pipes, an end cap to 1 pipe, etc.  So you can see that to model proper cardinality, you need to model your data in a way to properly define the number each asset can connect to.

With a simple data model, like the data model that is included with the Water Utility Resource Center templates, you can still set a connectivity rule if desired.  For instance, you can specify that wLateralLine should connect to a wMain and by default a fitting must be added. 

Some of the Edit Tools in the Network Editing Template are designed to assist with automation and basic connectivity testing without the use of geodatabase connectivity rules.  For example, the connectivity checker tool merely looks at feature types and makes sure they logically connect to each other.  So if you want to use connectivity to enhance your editing experience, you can do so, without modeling connectivity to represent every asset’s connectivity restrictions in the geodatabase.  For instance, you can model a hydrant to a lateral to a main and not worry about modeling everything, you will just have some connectivity errors when you validate, which you can choose to ignore.

Next, you will see an option for setting weights.  Geometric network weights can be used in two ways.  Weights can be a filter, tracing only features with matched values.  This is somewhat advanced and is used primarily in telecom and electric networks.  Weights can also be used to aggregate flow.  This is second usage is helpful for wastewater and storm water networks where flow direction is known – that is the non-looped portion of the network.  Using trace weights, we can accumulate flow upstream from a specified location.  You might add a trace weight on the length of your gravity mains and laterals in order to later obtain the total length of pipes upstream from a given location.  You might also add a field to your wastewater lateral points representing estimated gallons entering the system.  By creating a trace weight on this field, you can summarize gallons at any point in your network using the Find Upstream Accumulation trace task on the Utility Network Analyst toolbar. If desired, the system could then store these values of accumulated flow along your network in the manholes and gravity mains. For an example of this, see the Calculate Accumulation script:

http://arcscripts/details.asp?dbid=14481

In short, weights are typically not used for most utilities.  You can see that they do provide some advance functions but are not required to model and work with a geometric network.

Lastly, we like to recommend that if you are tackling some of these issues, that you take ESRI training so you can understand all of the implications of what we’ve discussed in this blog.  The proper training or consulting help with creating your datamodel or implementing the geometric network will undoubtedly save you a lot of time and money when your data model is in production.

This entry was posted in Water Utilities and tagged , , , , , , , , , , , , , , , , , , , . Bookmark the permalink.

Leave a Reply

One Comment

  1. yahya78 says:

    Thanks for sharing such beneficial blog. I need more clarification about Why should’t we configure both Sink and Source? Why this is critical? For Electricity, Service Point or Consumer Meter are always Sinks and they never feeding a network with power (traditional Networks, Not SmartGrids) and generation plants are always Sources. And for Water, wells and Reservoirs are always Sources where the service points or consumer meters are always sinks since they never feed network with water, they only consume potable water. So where is the critical point for configuring Sinks and Sources together in same Geomteric Network. Thanks for reading my comment.