Water Utilities Blog

Geometric networks for water utilities

2009-11-17T19:48:00Z

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.

GIS Training Plan for Water, Wastewater and Stormwater Utilities

2009-11-10T16:23:00Z

One of the things we can’t stress enough is the importance of GIS training for water, wastewater and stormwater utilities. The proper skill sets are critical to the success of any GIS implementation or operation and training is one of the ways a water utility can ensure they have the proper organizational skill sets to capitalize on their investment in GIS.

As a best practice, ESRI recommends that our water, wastewater and stormwater utility customers plan for their training needs. This includes both short term training needs to support a GIS implementation or a specific GIS project and long term training needs to ensure that a water utility can support their enterprise GIS progression.

Some of the typical benefits of GIS training for water utilities are faster GIS deployment, significantly reduced potential for mistakes (both GIS software use mistakes and GIS deployment mistakes), best practice enterprise architectures, better workflows and improved data QA & QC which ultimately yield a better return on your investment in GIS. We seen many utilities that continue to develop their employee’s GIS skills reap the benefits of faster enterprise deployments that are more soundly planned for.

During the past few years, ESRI’s Training Group has created a large number of training plans for water utilities. The plans were created through a consultative process where our training group would spend time working with a utility to ensure they had the necessary organizational skills to support their GIS plans. Through this process ESRI identified some patterns in the training needs of water utilities. These patterns included common GIS training classes taken by certain water utility staff roles, the relationship between size of a water utility and training needs and the sequencing of water utility GIS training.

From the experience of our training group coupled with typical GIS deployment patterns, core water utility functional areas, and best practices for water utility GIS, ESRI has now created a Generic GIS Staff Development Plan for Water Utilities. You can download the plan from the attachment link below this post.

After you download the Generic Staff Plan, we suggest you first read the Document Purpose section. This explains how the document is intended to be used. Since this is a generic document, we suggest that you contact an ESRI Training Consultant to help you customize this training plan to your utility. We’ve also created the plan to be a living document, so we’ll be updating the plan regularly as ESRI continues to expand our training offerings and the field of water, wastewater and storm GIS continues to evolve.

November 5th Webcast exploring the Water Utility Resource Center & Enterprise License Agreements for Water Utilities

2009-10-22T13:05:00Z

You can sign up now for a webcast ESRI will be giving that explores the templates on the Water Utility Resource Center and also how water, wastewater and stormwater utilities can benefit from an ESRI Enterprise License Agreement (ELA). We’ll touch on how you can leverage the GIS best practices from the Water Utility Resource Center and then demonstration of each of the templates in action, including the newly released Water Distribution Capital Planning Template. The webcast will also explore how water utilities are benefiting from both negotiated Enterprise License Agreements and Small-Utility Enterprise License Agreements. At the end of the webcast we’ll answer any of your questions about the Water Utility Resource Center, the templates or ELAs.

You can sign up here:

Session 1 – November 5^th 2009 1 to 2 PM EST - http://events.esri.com/info/index.cfm?fuseaction=showSeminar&shownumber=12971

Session 2 – November 5^th 2009 3 to 4 PM EST –

http://events.esri.com/info/index.cfm?fuseaction=showSeminar&shownumber=12972

Thanks for the downloads!!

2009-10-16T11:41:00Z

In the 8 months since the Water Utility Resource Center went live, we've gotten a lot of great feedback from our water, wastewater and stormwater users and been very encouraged by the number of times the templates have been downloaded.

Just this week the Water Network Editing Template went over 2,000 downloads, so we figured we should take a break from building templates, blogging & answering your emails to celebrate. Of course every good celebration needs a cake, so here is ours:

We're already talking about what to do at 5,000 downloads, so far ice cream cake is edging out cupcakes...

ESRI Solutions on display at WEFTEC.09

2009-10-13T16:48:00Z

Come to WEFTEC!

ESRI’s Team Water/Wastewater is going to Orlando.

This year’s conference is October 10-14 at the Orange County Convention Center. We will be in booth #3857 along with 6 of our business Partners: Azteca, ID Modeling, Trimble, ESEA, Geo Cove, and Westin. Dave Wachal from our professional services group will also be in the booth to answer all your questions. We will be featuring some great new solutions including ESRI’s Water Utilities Resource Center, wastewater models using ArcGIS Explorer, cool tools for data production, handheld GPS devices, mobile GIS, and work management solutions for utility asset management, inspection, mapping and data collection and showcasing numerous case studies. Plus don’t forget to ask us about our new Small Utilities Enterprise License Agreement (SU-ELA) to see if you qualify.

Last year’s conference broke attendance records with over 21,000 attendees and 1000 exhibitors. So be sure to take time out of your busy conference schedule to visit our other business partners on the exhibit floor including DHI, Wachs Utility Services, GBA Master Series, RJN, MWH, VUEWorks and Wallingford Software just to name a few.

Check it out at http://www.weftec.org/home.htm

WEFTEC is a great event that must not be missed. Stop by and say “hi”.
See you in Orlando!

The Evolution of the Water Distribution Capital Improvement Planning Template

2009-10-13T12:45:00Z

As you may have seen, we released the Water Distribution Capital Improvement Planning (CIP) Template a last week. First, we wanted to say a big thank you to all of our users and business partners who helped us to refine the initial geoprocessing models and the toolset also shared their workflows for capital planning.

We've already had a few questions about why we chose the term Capital Improvement Planning (CIP) to describe this template, since not all utilities use that term. So when we use the term CIP, what we mean is the long term plans of a utility to manage their assets and/or to expand their system, what you may also call a "Capital Plan", "Long Term Plan" or "5 year plan".

Personally, I think the CIP Template is great example of how ESRI listens to our water utility customers and responds to their needs. We've had numerous customers over the past few years tell us that they want to be able to leverage their asset data in GIS as well as their operational data (workorders, CIS, water quality) better to support their long term plans. Of course, we thought that giving our customers a geographic view of all that asset and operational data was the best place for them to start. We also heard from many of our water and wastewater customers that their long term planning has evolved from an occasional event to a continual process; because of funding issues, grant availability, coincidence with other projects that a utility could share costs with and the desire to be quick and proactive to eliminate the risk of future critical asset failures.

Also, we are excited, because the CIP template is great example of GeoDesign. We'll be doing a blog shortly that explores the principals of GeoDesign and relates them back to the CIP template.

2 Parts of the CIP Workflow

As we dug into the CIP process, we observed 2 distinct, but related workflows happening. The first part of the workflow was to assemble data from many sources and analyze that data to look for where projects are needed. This part of the process is tailor made for the benefits of GIS - to use GIS as the place where different types of data are assembled together into a common view and also to use the analytical capabilities of GIS to gain better insight into the aggregated data. Because this analysis needs to be iterative (looking at multiple data layers with different weighted criteria), an auditable process (you have to be able to defend your findings to a PUC and your ratepayers) and an automated workflow (to save time, money and resources) this is a perfect match for Geoprocessing Models in ArcGIS.

GIS Analysis for CIP Decision Making

At first we took the approach that ESRI should try and build a few geoprocessing models that all water and wastewater utilities could use to score and rate their assets by estimated remaining asset life, condition or criticality. We figured that we could do some research, interview some of our users and figure out these geoprocessing models (our inner geography geek begged us to take this approach first). What we quickly realized was that there isn't a silver bullet set of geoprocessing models we could build because every utility system has their own approach to long term asset management and their own priorities (KPIs, level of service they want to provide, hot button issues, fiscal condition, etc) that drive their long term planning.

This was also a great reminder that even though we have the ability to use technology to automate a process, the human element is still critical, meaning that the more we talked with the engineers who are creating these CIP plans, the more we realized they need a better way to manipulate and process data so they could apply their engineering expertise to make decisions about capital projects. We also noticed when talking to engineers doing capital planning, that while they were somewhat aware of the analytical capabilities of GIS, they weren't aware of the geoprocessing framework core to ArcGIS and how to use ModelBuilder to automate analysis and create a reusable toolset.

So we decided that we need to focus our CIP template on showing the water utility community how they could benefit from automating spatial analysis with the ArcGIS geoprocessing framework by providing some generic models. So, please keep in mind that the intent of the models we've provided in the CIP template is to show you how geoprocessing and ModelBuilder work within ArcGIS so you can create geoprocessing models that reflect how your utility wants to manage assets and plan for the long term. Incidentally, if you want to learn more about GIS analysis, Geoprocessing or Model Builder within ArcGIS, ESRI has lots of great resource including on-line training, books and class room instruction.

Estimating Project Costs

The second part of the CIP workflow we observed was estimating CIP project costs. Basically this workflow was estimating the cost of a project based on either replacing existing infrastructure or adding new infrastructure (main extensions, interconnections, extending service to new sub-divisions, etc). It's important to note that all of the functionality in this part of the CIP process is core to ArcGIS and the geodatabase, all we've done is customized the application to automate and simplify this part of the workflow. This is what we decided to call the Costing Estimating Tools.

The first step in estimating project costs is to create projects by grouping assets together into projects. In this part of the process you are visualizing the data you brought into GIS and also the results of your analysis and then determining what assets you want to include in a project, your rehab or replacement strategy for those assets and then saving that information. So you are literally visualizing data in GIS (most likely working with many data layers of data, including the same feature datasets symbolized different ways) and doing some spatial and attribute queries to come up with candidate assets to include in CIP projects.

From there, assets that are in need of replacement or rehabilitation and spatially close to together are grouped in projects. We've heard from many water utilities that without a spatial context it was a real challenge for them to group assets together into appropriate projects without and also it was a challenge for them to track and manage information about candidate assets for CIP projects throughout the CIP planning process. Water utilities were struggling with supporting their CIP process with paper maps and tracking assets that were part of a project, including costs to replace those assets, in spreadsheets.

So traditionally, this CIP process took a lot of staff time and also lead to uncertainty about whether utilities were actually spending their money on the most appropriate capital projects. We also heard that utilities were struggling with how to update data when they tried to refine a large candidate list of CIP projects down to just a few to carry forward into design and that it was next to impossible to look at multiple scenarios for the same project area (assets grouping and rehab or replacement approach) because so much of this process was manual or spreadsheet driven.

We took the approach that if a utility has their assets (water distribution, wastewater collection or stormwater) in GIS, they should use their GIS asset data to group into CIP projects and then to store information about the CIP projects (like the extent and also all of the assets that are part of the project) as new data layers in GIS. This enables a utility to create an authoritative source of data about their proposed capital projects in GIS. So this drove us to create the Cost Estimating Tools.

As we began to demonstrate early versions of the Cost Estimating Tools to our utility users, we got a lot of great feedback that helped us to refine the tools. We were told that to be really useful, the tools should include the ability to either rehab or replace existing assets and to extend mains, so we programmed that functionality into the tools. We also were told by our users that they needed to be able to compare the costs of different replacement strategies (open cut, trenchless, etc) for the same set of assets so we designed the tools to make it easy to compare the costs of use using different rehab methodologies. Also we knew that the costing element of the tools needed to be flexible, because individual utilities favor different pipe materials which can be set as defaults and that unit costs are often specific to a utility and those can be easily configured in a simple table.

So what we wanted to do with this blog was to explain how we arrived at version 1 of the Water Distribution CIP Template. We are very interested in your feedback so we can incorporate more useful changes in version 2. Also we'd like to hear about any geoprocessing models that you would like to use for CIP planning. So, please leave us feedback here - http://forums.esri.com/forums.asp?c=55&s=426#426

In the next few weeks we'll be recording a video of the Water Distributions CIP Template in action and we are also going to do a webcast in December that takes a deep dive into the CIP Template.

CIP Template Released

2009-10-07T14:37:00Z

If you have been following us on twitter, you already know that we released the ArcGIS Water Distribution Capital Planning template (we are calling this the CIP Template for short) yesterday. The CIP template includes a set of models to help you understand how to you can use GIS to score and rank your infrastructure and a set of tools to provide cost estimates for rehabilitating, replacing or building new infrastructure.

We will film a video at the end of October that shows you in detail how these tools work, and we’ll be doing a live webcast in December to explore the CIP template in depth. So in the mean time, below is a little help with the CIP Template.

Models:

We included 6 models that show different ways you can analyze your data. To run these models, you will need to create a temporary file geodatabase and set the environmental variables for each model. The two variables you need to set are Current Workspace (the folder that has the CapitalPlanning.gdb in it) and the Scratch Workspace (the folder that has the temporary File GDB you just created).

Tools:

The Project Cost Estimating tools use three tables in the CapitalPlanning.gdb for configuration. These tables are shipped to work with the data in the Sample.gdb. If you want to start changing cost or the configuration, you will need to change these tables.

CIPDEFINITON – This tables defines which featureclass’s to cost, the fields to look at(such as Diameter and Material) and a few other parameters.

CIPCOST – This table defines the cost for a particular asset. When costing an asset, you can define a Strategy, like Replacement or Rehabilitate, then an action for that Strategy, like Open cut for a Replacement . For each Strategy and Action, then you define the cost based on the fields you set up in the definition table. So if you are looking at wMains as a layer, you are interested in the Field’s, Diameter and Material, you would select your Strategy, the Action for that Strategy, the Material(say PVC), then Diameter(say 12) and define a cost for what each foot would cost. So by using a Strategy, Action and two filter fields, you can provide very detailed cost estimates.

CIPREPLACEMENT – This table allows you to provide lookups for replacement. If you are going to replace a 6” DI, you may have a rule saying that each 6” DI is going to be replaced with a 8” PVC. This table allows you to define this replacement. So that costing is preformed an 8” PVC, not a 6” DI.

Since this is our initial release of the CIP Template, we want your feedback. So please post any questions or feedback to our forums under the Water Utilities Template section: http://forums.esri.com/forums.asp?c=55

GUID's as ID's

2009-09-28T16:39:00Z

We have had a lot of talk about Unique ID’s in the last few weeks and GUID’s have came up a few times. We wanted to add some more information to this topic. GUID’s or Globally Unique Identifier are essentially unique values. These are used by the geodatabase for replication and editing in ArcGIS Mobile in a special field called Global ID. This Global ID field is managed by ArcGIS. When a feature is created, it is auto populated with a GUID, either in ArcGIS Desktop, ArcGIS Server or in ArcGIS Mobile. This should not be used for a Unique ID. These values can change if you have to reload the data at some point or if you drop the Global ID field and re-add it. I would say that you should not use any field managed by something as a unique ID. But there is a GUID Option.

There is also a GUID field type. This allows you to use the GUID data type as a unique ID. It is up to you to manage it, but there are some tools to help. We are looking at adding an option in the Dynamic Value table so the Attribute Assistant that is part of the editing template can add a GUID for you. I have included a VBScript function that can be used in the Field Calculator. Please see the attach GUID.Cal file.

You can read more about GUID’s on this Wiki article. - http://en.wikipedia.org/wiki/Globally_Unique_Identifier

Where Are Your Customers?

2009-09-22T18:00:00Z

At first glance, that might seem like a silly question to a water, wastewater or storm water utility. After all, how hard is it to find your customers…. they are in your service area, connected to your infrastructure and you have an address to send them bills. But do you really accurately know where you are providing service to?

We are seeing a trend where water utilities are recognizing the importance of accurately knowing where they are providing service to (your real customer locations) and also understanding that there are many facets to accurately establishing your customer locations.

So what do we mean by customer location and how do you store that in your GIS?

For the purpose of our discussion here, by customer locations we mean the location where you as a utility are providing service to. This is the location where you are distributing flow to in a water system or where you are accepting flow in a sanitary sewer system

There are some common approaches that we see utilities using to store customer information in their GIS. Just like any GIS data model, you should pick an approach to store your customer locations that fits your utility’s specific needs.

For water utilities we commonly see customer location stored as a meter feature class (if you have meters) or with a feature class called customer, premise location or service location. With a geometric network, these feature classes are snapped to lateral which are snapped to mains. An important distinction for many utilities is that billing location of a customer, where the bill is sent to, is often different than the location you are serving that customer (premise or customer location).

For wastewater utilities we commonly see customer locations stored with a cleanout feature class, a customer or premise feature class or if a combined water/wastewater utility then water and wastewater both may use the meter feature class from the water distribution network.

Of course if you don’t have your water or wastewater networks in GIS yet, or don’t even have a GIS, customer locations are a great starting point for building a GIS system. It is relatively cheap to record them and you’ll immediately get high value from having those location accurately measured.

Some common attributes we see for customer location feature classes are: unique ID, customer type, active, customer name, premise address, customer phone number. Unique ID is should be an ID that will allow you to join your customer locations with your billing system so you can visualize consumption patterns.

Benefit of accurately locating your customers:

Some of the ways we’ve seen water and wastewater utilities benefit from accurately knowing their customer locations are:

Reducing non-revenue water – We’ve seen accurate customers as a critical data component to reducing non-revenue water. A simple example of reducing non-revenue water with accurate customer locations is to create a map that shows all of your customer locations and then to look for where places (such as a buildings) that should be a customer location but are not. Another way to use customer locations to reduce non-revenue water is to join your billing data to customer locations and visualize customer consumption by creating a thematic map of graduated symbol sizes or colors. In this case you are looking for active customers that have abnormally low consumption and may have a defective meter. Anecdotally we’ve heard from a number of ESRI customers that the simple actions above have made significant reductions in non-revenue water. We’ve also seen some very sophisticated analysis using consumption data linked to customer locations and metering data to try to identify zones within a water distribution system that may a high amount of water loss due to leaks.
Allocating demands – More accurate customer locations will yield better demand allocation for hydraulic models, especially when linked to consumption data.
Estimating flow – For wastewater utilities, more accurate customer locations can be used to better estimate flow through being able to more precisely calculate the EDUs flowing into pipes from upstream.
Better Customer Service – For example you can gain better insight into how customer complaints and customer service requests track back to the actual infrastructure that they are served by. A good example of this is water utilities that are using their customer locations in GIS to track the location of water quality complaints over a multiyear period back to common pipes or water sources that could be the cause of an issue.
Improved routing – More accurate customer locations will yield better routes for field crews, saving fuel and time.
Validating premise addresses in other utility systems – We often hear from utilities that while they have very good billing address data for customers in their CIS or billing system, that premise locations (stored as an address) in these systems is often wrong. So better premise address locations generated with GIS can be used to fix bad premise locations in your CIS (you should have one system of record for premise locations, but we’ll save that discussion for another day).
Better emergency notifications – We’ve heard a number of horror stories from utilities that have an emergency notification system that has not notified customers during an emergency because their customer locations are bad. 2 common ways to notify customers during emergencies are doing a broadcast notification (notifying all customers in a service area or a municipal boundary) or doing a target notification based on the pipes that serve a customer (just notify customers that are affected by a broken main because you know they are served by that main). In both of these examples accurate customer locations are key to being able to perform emergency notifications.

So how do you get your customers located accurately?

The most common way that utilities initially get their customer locations into a GIS is through geocoding their billing roster. When geocoding any address data, the 2 critical components that determine the quality of your geocodes is the input address data and the dataset that you are geocoding against.

We’ve heard from a lot of water utilities that the premise locations in their CIS or billing system are of dubious quality and often time there is not a lot of consistency in how the address fields for premises were used. So while billing address data is usually of high quality (otherwise you’d never get paid) premise location is not accurately stored because it was perceived to be of less importance. In this case, step one would be to try and fix some of the issues in the address data you are trying to geocode before you geocode the address data. This may include trying to standardize the input address data (street abbreviations, data structure, etc).

You also want to use the best dataset available to geocode against. Increasingly we are seeing water utilities licensing commercial dataset for geocoding. Particularly they are choosing to license datasets that frequently updated and have the ability to geocode down to a rooftop level.

We somtimes see water and wastewater utilities use parcel centroids as the first step to establishing customer locations. So if you can get a good dataset of parcels in your service area you can use GIS to calculate the centroid of each parcel as the first step to establishing customer locations.

Also we are increasingly speaking with water utilities that are GPSing their meter locations and curb stops during meter replacement projects or wastewater utilities that are GPSing clean outs during field data collection projects.

No matter what automated process you use to get your customers on the map initially, no doubt you’ll have to do some data clean up. For example, you will probably have to do some manual data creation and editing to establish customer locations at commercial and industrial locations or for multi-unit housing. Also you must develop a workflow to keep your customer location dataset in GIS up to date.

Interfacing the mobile map with other systems

2009-09-18T13:42:00Z

Many of you have had a chance to test out the Mobile template and provided great feedback. One question that keeps coming up is “How do I interface (or integrate) the mobile map with my other utility systems?” Typically, when we get asked this question, people are referring to their workorder system (also called a CMMS or EAM). Occasionally we are asked about interfacing with a LIMS system, mobile leak detection system, customer information system (CIS), billing system, heck we’ve been asked about interfacing with a utility’s time card system. Hopefully you notice the trend here, that water and wastewater utilities can and do want to “spatially enable” their other business systems because most of these systems contain information that has a location to it, but the other business system can’t store spatial information at all or can’t store it well.

Well, there is one simple easy answer because there are some many types of systems, vendors, API’s, gateways, etc... So I wanted to talk about a few general ways to communicate with other systems and some ideas how to work with other systems. First you need to decide what functions the field crew is going to need. For instance, if you are flushing hydrants, do they need to access to when the hydrant was flushed lasted or every time it was flushed? The reason I would ask this question is the answer is going to help us define how to work with other systems.

Lets start by looking at were to record the inspection or flushing report in the above case. If we are storing our field reports/inspections in the geodatabase, then this is fairly easy process. We can create a feature class with all fields for the hydrant flushing. This is exactly what we did with the template. The user can click the hydrant, copy some relevant information to the hydrant inspection record, such as Asset ID and populated the geometry of the report from either the hydrant or the GPS location of the field crew doing the inspection. The crew can fill out the rest of the information, click save, and use ArcGIS Server to post that information directly back to the Geodatabase. If the user wants access to all historical inspection data, then that information can either be in the same feature class as the new inspections or in a separate one. I would suggest that all historical information been in a separate featureclass. The reason is that the historical inspection or field report data can be very large. You want to manage the update of the devices with this information separately then the newly created field inspections. If all the inspections, both new and old, are in one feature class, then the map may have 100’s of inspections at the same location, may be very confusing for the field crews. The historical inspections never really need to be displayed, they really just need a tool to click the asset and pull up all related information. With the new inspection, once they create it, they then can visually see on the map that they created and save the inspection and are done working with that asset. So in summary, if you are using the GDB as you system of record for assets and their related information, inspections, flushing, etc.., then create a data schema for new data and historical data. This will provide ultimate flexibilty and usability. Just one more note on the above. If you are going to load all your historical inspection information into the geodatabase from another system, then use a process to join your historical, non GIS inspection data, to the geometry of your asset and load this to your historical field inspection data.

Now if you are storing some asset information in another system, like extended asset data in your workorder system, then you have a few ways to interface that data with the mobile map. One way is to use the Geodatabase as your connection to other systems. What I mean is build a backend process to pull out new inspections from the Geodatabase and push them to whatever system you have, and vice versa, use the same process to push information from the other system into the geodatabase. This way you can use ArcGIS Server and ArcGIS Mobile to interface with the information in the field. It is much easier to write back end database scripts to move information around then it is to build a process to push out other systems data into a field, in a format that they can access offline, make edits or entries to that information and push it back into the office.

If want to connect to the other system information store directly, without having to move it into the geodatabase, you have two options. You can work with a local copy or cached representation of that other system. This means that a set or all the data from that system will be loaded on the device. The other option is to use a web services approaches or a Enterprise Service Bus(ESB) to directly talk to those other systems.

If you want to work with the other systems directly on the mobile device, then you are going to need to figure out how to get that information on the device you are using and write a module for the mobile app to talk to that data store. ArcGIS Mobile is built with the .Net framework, so it is very easy get your Mobile GIS Information to talk to other data stores. The biggest challenge with this method is figuring out how to get the information on the device, keep it updated and push changes back into the office. Some vendors have ways to do this, some do not. I would suggest talk to your vendor and discuss what options they have. You can also look at using provisioning software that can manage pushing out information to the field and pulling back in. If you have a homegrown system, then you will need to develop a homegrown field version of the data and a synchronization method.

If the above is technical daunting and you want to use web services to have ArcGIS Mobile talk to your other systems, then I would ask yourself one question. Can your field personal do their job if they do not have a connection to that service? If so, this is a great way to interface mobile and office systems. If your answer is no, then proceed down this route with caution. Even with cell coverage getting better and better, there are always dead spots or connection issues. What is one of the first things that happen when there is an incident, the cell networks get overloaded. Also think about bandwidth. This could be a chatty system. According to Gartner, the days of unlimited data on cell networks are coming to an end, btw, unlimited data is 5GB on most carriers. If you are ok with all the above or your field crews do not need access to this information to do their jobs, then web services are great, effective and easy ways to talk to other systems. They are easy to implement and they can support many applications. All you need to do is build a module for ArcGIS Mobile that when I click an asset, it hits the appropriate web service and displays the results. This could be a simple hyperlink in the attributes of a feature.

In closing there are a number of ways to interface an ArcGIS Mobile Applications with other utility systems and we wanted to highlight few of them. The above strategies are not the only strategies; there are many ways to implement communication between different systems. If there methods you would like to discuss further, please contact us and we can help you figure out the best approach for your utility. You also may find that combining some of the approaches best suites you. For example, with new inspections, you may use ArcGIS Mobile to create a new record, store it in the cache, and post it to the geodatabase using ArcGIS Server, then nightly, use a backend script to move it to the proper system. When that field user wants to look at the historical info tied that asset they are inspection, they can hit a web service. If your field crews do not have coverage broadband, well at least they can complete their work.

Thanks

Our Fall Plans

2009-08-25T15:45:00Z

Summer is winding down, so we thought we'd take this opportunity to report on a few things we spent our summer working on and some things you'll see in the fall.

First, you can now follow us on Twitter at ESRITeamWater - we'll be providing updates via twitter about our activities, information for our water, wastewater and stormwater customers and also when we've posted updates to the resource center.

And we have quite a few updates on the way....

Costing Tools

Those of you who were lucky enough to attend the UC in July, you saw us present our "costing tools" for ArcGIS Desktop. We are now doing some final code revisions and documentation and will be posting this new template to the resource center in the next few weeks.

For those that haven't seen the costing tools yet, they are a set of desktop tools designed to help you cost out capital improvement projects or really cost out any type of project with GIS. The concept is that you can either choose assets that are in your GIS and select them for replacement and the tools will look up against a cost table to determine the replacement costs. The cost table is fully customizable and you can do some things like have default replacement types for materials - for example if you always replace transite pipes with ductile iron, than that will be pipe type used for your replacement project and that will drive your replacement costs. Also you can choose to add or extend mains or pipes to get costs for water main extension or sewer expansion projects.

We'll also be providing some geoprocessing models to help you make system rehab and expansion decisions. We've had a lot of discussions with water and wastewater utilities about how to make some generic models to assist in condition assessment and decided that it would be more impactful if we created some models that showed you how you can use GIS and geoprocessing to make rehab decisions. Than you can customize the models for your utility's information, workflows & asset rehab priorities.

To be fair, the costing tools are more of generic toolset and you'll also see the costing tools as a template for pavement management on the soon to be launched ESRI Public Works Resource Center. So if you are looking for an end-to-end solution for condition & risk assessment that leverages your investment in GIS data, we suggest you check out some ESRI business partner solutions such as CapPlan from MWH Soft or MRP from Advantica.

Editing Template Update

As you may have heard, we are also working on an update to the editing template that will expand the editing toolbar for both water and wastewater.

Wastewater Focus

Over the next few months you'll see us begin to add more wastewater information and templates to the Water Resource Center. So, while decided to start with water (hey, you have to start somewhere) we are going to add more content for wastewater and stormwater.

Water & Wastewater Utility Training Plan

We are wrapping up a GIS training plan specifically for our water and wastewater customers. The intent of the training plan is to give water utilities a tool to help them make training decisions by recommending GIS training courses by both typical staff roles within a utility (mapping technician, engineer, DBA, etc) as well as buy department (IT, planning, operatins) . So for example, we can help recommend training course for engineers that want to use GIS for lightweight analysis and ad hoc mapping or for folks in the IT department who need a better understanding of how GIS fits into their enterprise.

The training plan is designed to be customized for specific utilities. So you can work with an ESRI training consultant to identify what your organizational and GIS goals are and then based on the size of your utility we can recommend training options. And the training plan will be free of charge!

Public Works Resource Center

We'll be launching a Public Works resource center soon that will compliment the Water Resource Center. So you can go to the public works resource center for information about managing pavement, street furniture, signs, facilities, snow plow routing, solid waste pickup, etc and use the Water Resource Center for information about GIS for water, wastewater and stormwater.

Your feedback

As always, your feedback guides much of our future plans. So if you'd like to make suggestion please email us at ArcGISTeamWater@esri.com, post a comment to this blog or use the water/wastewater discussion forums.

Generating Unique Asset IDs for asset discovered in the field

2009-08-19T16:47:00Z

Based on our recent blog on Generating Unique Asset IDs, we had a few people ask about how to handle generating IDs in the field and how to handle new assets turned over from developers. So we thought it would be good write a follow-on blog about that topic.

First off, for most utilities having a methodology for generating unique asset IDs doesn't necessarily mean that an asset's permanent unique ID is actually created in the field. So while the title of the blog is generating unique asset IDs in the field, that's a bit of misnomer, because not allowing field staff to create permanent asset IDs may be the most efficient process and also be the best solution to safeguard your data quality.

I think the question to answer for a utility then is "what is my process for creating asset IDs for assets we 'discover' in the field?" Since we are focused on GIS here, by discover we mean that you capture the asset's location spatially and this drives the need to give it a unique ID, but what we are discussing is really applicable to any asset that is found in the field that you need to track in a computerized system. Also, we are using the term 'discovered' here because these aren't new assets, just assets that you didn't know existed or may have known about, but didn't know where or what exactly they were before.

There are many ways that you may discover new assets - as a water utility you may find the locations of valves that were paved over and recently restored to grade, or as a wastewater utility you may find buried manholes when you CCTV. So ideally when these assets are discovered they are ultimately captured in the GIS with appropriate spatial and descriptive information. Spatially they may be captured in the field as a feature in a feature class, ideally with the appropriate level of precision (such as with sub-foot GPS) or perhaps as a rough location with descriptive information that tells the utility the asset needs to be captured at a later date more accurately. Incidentally, we often see this type of workflow with water utilities that want sub-foot asset locations, but only have a few crews that have the GPS equipment to achieve that level of accuracy. So the GPS crews will go back and capture the asset locations when time permits because the utility has an attribute that allows them to know the spatial quality of each asset location.

You may also have developers build infrastructure for your distribution or collection systems and turn that over to you - these are new assets and different from discovered assets. For assets that are being built and turned over to you by a developer, it's best to track all of those assets in your GIS from the time you learn they may be built. We see more utilities starting to use a proposed feature dataset in their geodatabase to track potential system expansion. When the asset are built, the data is modified to reflect developer submitted as-builts or GPS data collected, assigned a unique ID and then moved over to your water or sewer distribution feature datset from the proposed feature dataset. We'll plan to cover using proposed, abandoned and active feature datasets and other tips on managing asset in GIS as the go through their lifecycle in a future blog.

IDs for Discovered Assets

So for discovered assets, there are 3 options for assigning asset IDs in the field - temporary asset IDs, permanent asset IDs assigned by the field crews & permanent asset IDs assigned by your asset "system of record".

Temporary asset ID assigned in the field

The simplest way to go for field users. Basically let the field user or have your mobile GIS application give a temporary ID to an asset that signifies it was captured in the field and doesn't have a permanent asset ID that conforms to the asset ID methodology of your utility. Ideally there is some sort of identifier in the asset ID that shows the asset ID is temporary - for example for a manhole ID you could use MHT and for valves you could use VT.

Then your workflow would be for the appropriate person or system in your office to assign the permanent asset IDs. Using our example, a simple query for the letter "T" would reveal any assets that don't have permanent IDs assigned yet. If you are using a mobile GIS application with data synchronization capabilities, such as ArcGIS Mobile based solution, when the asset is assigned the permanent ID back in the office, the field users will see the new asset IDs in their applications the next time their data is refreshed.

Permanent Asset IDs Assigned by the Field Crews

Field crews could assign permanent IDs to assets at the time of discovery. We've seen data collection forms that call for an asset ID to be entered, often these are paper based forms that have a box for an asset ID. We've also seen electronic data collection forms for GPS using ArcPad that allow or require field crews to enter asset IDs.

So in this case a field crew has the ability to assign or record an asset ID in the field. Allowing a field crew to record an asset ID is good workflow when there is already and ID on the physical asset, like a unique number on your manhole lid or a barcode on the asset and all the field crew is doing is recording the ID already given to an asset when they capture a more accurate location or do an inspection.

But allowing a field crew to assign asset IDs without any guidance from a mobile application or without any coordination from your office is a workflow that could introduce data integrity problems. For example, a field crew could assign asset IDs that are duplicates of IDs already in your system.

Permanent Asset IDs Assigned by Your Asset System of Record

If your GIS is your asset system of record, than using a mobile GIS application with real time connectivity back to your office can ensure that the appropriate asset ID convention is used and the next sequential asset number is assigned. Or if you are using an Enterprise Asset Management or EAM System, which is typically now a GIS integrated with a workorder system, the GIS application can communicate with the workorder system on the backend in the office to assign the permanent asset ID on the spot in the field.

If you are a smaller utility and you don't have mobile device connectivity, you can also call into your office and have someone assign an asset ID from your system of record, but this isn't a very efficient workflow.

Tips For Capital Project Coordination

2009-08-10T17:06:00Z

It's seems like right now, the idea of capital project coordination between utilities and other government entities has reached critical mass. Whether faced with budgetary problems due to the economy, the need to do a significant amount of capital projects now (or both) recently we've had a lot of ESRI customers asking us how they can use GIS to coordinate their capital projects better and what information about future projects they should share with other utilities and municipalities in their operating areas.

Since water and wastewater utilities are in the same right of way with other public utilities such as electric, gas and telco and also are typically under the pavement owned by other municipal entities, departments of transportation or highway agencies a little coordination yields big cost savings. We see this capital project coordination happing between departments, such as between a city's wastewater and streets departments and also between utilities and external entities such as between a water utility and gas utility.

For example if you can coordinate your work with other utilities when a street is opened you can split the restorations costs. Jurisdictions your utility operates in may also have street paving moratoriums, for example they may prohibit streets to be opened until 2 years after they have been paved, so in this scenario you need to know what streets are being paved in the next few years so you can complete any project work in those areas ahead of the schedule paving.

Capital Project Coordination with GIS

So how can you use GIS to coordinate capital projects?

Capital Project Aggregation

Even before GIS, many water and wastewater utilities tried to gather the capital project locations of other utilities and municipalities in their service area. This was often a time consuming process, with multiple requests for information and paper document submittals that the water utility needed to aggregate into a big picture view of capital projects in their service area. With GIS, many water utilities started to input capital project locations from other utilities as GIS layers. This still required a great deal of digitizing effort to create project polygons and even if you had the location of future projects in your service area you may not have had good descriptive information. Maybe if you were lucky, the other utilities in your service area also use GIS and are were able to provide shapefiles or geodatabases of project locations.

Consortium Approach

We've seen some utilities work as "consortium" to coordinate their capital projects with web based map viewers. For example some utilities aggregate capital projects from municipalities and other utilities in their operational area and then provide free access to a web based mapping application for all of the entities that provided project information. Other utilities have created web mapping application where local utilities and municipalities can edit their project footprints and enter basic project information. Setting up a website with security where utilities can enter project locations on a basemap is very easy with the web editing capabilities of ArcGIS Server. The drawback to this consortium approach is that it takes someone to have the infrastructure to host and manage a web based application and the other utilities have to submit data or enter it.

Map Services

An easier way to share capital improvement project locations for utilities with ArcGIS Server is to publish a map service of project locations. This is easier because if a utility keeps all of their project locations in a centralized enterprise geodatabase than a published map service of project locations will always be up to date. The project location map service could be used both internally at the utility and externally and could be consumed in a variety of applications like other ArcGIS Server applications, ArcGIS Desktop, ArcGIS Explorer, in AutoCAD with ArcGIS for AutoCAD or in Google Earth as KML. If you want more information on publishing map services with ArcGIS Server you can find it here: http://webhelp.esri.com/arcgisserver/9.3/dotNet/index.htm#map_service.htm

ArcGIS Online

With the new free content sharing capabilities, ArcGIS online is an excellent option to share project locations. For those that haven't seen the new content sharing functionality in ArcGIS, with ArcGIS 9.3.1 you can upload your data as layer packages to ArcGIS online and share it with everyone or with a group you designate. So you could create a group of local utilities and municipalities that you want to share project locations with

and you can securely share your project locations with ArcGIS online.

If published a map service of future project locations you could also share that through ArcGIS online with a group, much like a layer package.

We're very excited about the new content sharing capabilities of ArcGIS online because it's a great solution for water, wastewater and storm water utilities to securely share their GIS data and maps. It can be used as we outlined above or used to share data with GIS consultants, engineering firms, developers, etc. Best of all, ArcGIS Online content sharing is free!! We plan on doing a more detailed blog in the future that goes into depth on using ArcGIS Online to share your content for project coordination.

In the meantime we encourage you to explore ArcGIS online content sharing for yourself: http://www.arcgisonline.com/

Utility Coordination Data Model

We commonly get asked by water utilities if there is a data model for capital projects. There isn't an ESRI community data model for capital project coordination, but from discussions with water utilities that are using GIS for internal capital project tracking or for project coordination with other utilities and municipalities, we've seen some trends. Most utilities track their projects as a polygon of the project extent and are capturing fairly simple attributes - project name and/or project ID, project start date, project end date, project contact name, project contact information such as phone number or email. We've seen utilities begin to track project funding information as an attribute as well, both total project costs, project cost by year for multiyear projects and also funding source information if stimulus money is being used for the project.

For water and sewer main extension or replacement projects most utilities buffer the mains to be replaced by a predetermined distance, like 25 or 50 feet to generate the project footprint.

Some utilities are also using project IDs to link to a project management or tracking system to store extended project information.

Methods to Create Unique Asset IDs

2009-08-03T12:51:00Z

We commonly get asked by water, wastewater and stormwater utilities for some tips on how to establish a system for unique asset IDs, so we thought it would helpful to share some insight on this topic. It seems like almost all utilities now recognize the need to have a standard methodology for establishing unique IDs for all of their assets and often use GIS implementation or data model upgrades as an opportunity to introduce a new system for assigning unique asset IDs.

First, and most importantly, it is an absolute must to use unique asset IDs!! In our modern era of computers, databases and GIS, unique assets IDs play a critical role in reducing duplicate or confusing information about your assets and also is the first step to being able to reduce silos of data and integrating your systems.

That being said, it seems like some water, wastewater and stormwater utilities make the process of coming up with a unique asset IDs a more complex endeavor than launching the space shuttle. It doesn't have to be that difficult, because inherently GIS has the ability to use any unique number or letter combination to store, manage and retrieve information about your assets. Things become complicated when we try and bring back the human element into our asset ID naming system. That is, you try and create asset IDs that have information in them that allows humans to understand what the asset is or where it is located. An example of this would be using an asset naming methodology that produced names like H-MT601 - where H is for hydrant, MT is for the service area in this case Millbrook Township, and 601 is the number of the hydrant.

But if you are using a GIS, you are already accessing asset information by location and can eliminate location information from your asset IDs. We hear 2 common rationales for having a location code in asset IDs. The first is that field crews need a location code to help them know what service area assets are located in or know what map book sheet they will find an asset. A good mobile GIS application eliminates this need.

The second rational we hear is location codes in asset IDs are necessary for reporting. For example we commonly hear water utilities say they need municipal codes in their hydrant IDs to run reports for fire billing. This problem is also solved by GIS because you run fire billing reports, or any asset reporting for that matter, but municipal boundaries or other polygon layers in the GIS.

Asset ID Methodologies

So here are some methodologies that we've seen utilities use for their asset IDs:

Incrementing Asset IDs - incrementing asset IDs by one number whenever a new asset is put in service. This is by far the simplest way to assign asset IDs, provided that one person or system is assigning all of the asset IDs. The Dynamic Value Table in the Water Editing Toolbar that is part of the Water Editing Template is simple way to have ArcGIS increment your asset IDs.

Asset ID preceded by asset type - For example putting an identifier in front of asset ID to identify the type of asset. For example MH preceding manhole IDs or FH preceding fire hydrant IDs, M preceding meters numbers, etc. This is fairly common and is useful to help identify which asset ID corresponds to which asset when labeled on a map.

Asset IDs with geographic identifier - discussed above, in a well done GIS implementation, there is typically no business value in this practice.

Asset IDs with a system identifier - This is mainly seen in wastewater systems where it is important to identify and differentiate interceptor lines, typically for reporting purposes. For example, a utility with 3 different interceptors lines - Bushy Creek, Forest Run & Oak Valley might put BC, FR & OV in front of any of the assets that in those drainage basins. Arguable you could also use a polygon to establish what assets are in each interceptor or sewershed for reporting purposes.

Increatementing Manhole IDs from the lowpoint up - Some wastewater utilities choose to increment their manholes IDs from the lowest manhole to the highest manhole along interceptor or trunk sewer lines. This tends to work well in areas where trunk mains or interceptors aren't going to be extended in the future and the utility is aware of all of the manhole locations before establishing asset IDs. If new manholes are found (such as buried manholes) or manholes added along the interceptor than typically that manhole is given the next downstream manhole ID with a letter designation. So a buried manhole found above MH27 is given the asset ID MH27A. Once all of the manhole IDs have been assigned from the bottom to the top of the interceptor than many wastewater utilities just increment the manholes on each of the collector lines that feed into the interceptor moving from the bottom to the top of the collector systems.

Here is a good website from the EPA on manhole numbering: http://www.epa.gov/NE/sso/manhole-id.html

Sanitary Sewer Pipe IDs - Often done with a combination of downstream manhole, a dash, and then upstream manhole. So sanitary sewer pipe ID 26-27 takes flow from manhole 27 and carries it to manhole 26.

Geopins - Not often seen in utilities for asset IDs, a geopin is calculated using the X & Y coordinates of a spatial feature. Geopins are commonly seen in land records. Geopins are not a good choice for spatial features that are assigned new loction, such as when a utility improves the spatial accuracy of their asset base by doing something like sub-foot GPS field data collection.

This is an example how geopin would work for a valve at coordinates: X = 23658974.365 Y = 6584752584.968
Geopin Formula = X2 Y2 X3 Y3 - X4 Y4 - X5 Y5 X6 Y6
GeoPIN = 3568-54-8795

Asset ID Tips

Don't use internal database IDs or geodatabase IDs for your asset IDs - This is a cardinal rule! Never use any internal IDs from a geodatabase or any other database for your unique IDs unless you are 100% certain that it will not be automatically recalculated by the application in the future. An example of this is the OBJECTID attribute in a geodatabase. Because the OBJECTID attribute is internally used by the geodatabase, on occasion in may be recalculated by ArcMap.

Keep your legacy asset IDs - It's perfectly acceptable to store your "legacy" asset IDs when you switch to a new asset ID system. It may be very helpful to know legacy asset IDs if someone needs to refer back to as-builts or old field map books. We saw a great example of this with a municipality that created a table with a one to many relationship between new asset IDs and legacy asset IDs that were used on any old plans or maps that showed the assets.

Make sure only 1 application or person assign new asset IDs - This is critically important. Only 1 application, such as ArcMap, your CMMS or 1 employee is who assigns unique IDs, otherwise you are running the risk of assigning duplicate IDs.

Storm Water IDs - because of the ad-hoc nature of how most water storm networks were built, especially in suburbia and the difficulty in understanding how the water flows without good elevation data, it's difficult to create an asset ID system for stormwater that describes which assets flow into each other. It's much easier to just use incrementing IDs.

If you'd like to share other asset ID systems you've seen, please feel free to post a comment on this blog.

User Conference follow up and your thoughts on the Templates

2009-07-22T13:45:00Z

If you had the chance to attend the user conference, I am sure you are excited about some of the new functions you saw in 9.4. I know I am. I cannot wait for the new editing environment. To be able to set up editing templates that default attributes, symbols, etc. is going to make managing our assets so much easier. There are many nice additions at 9.4, I wish it was ready tomorrow!!

What did you think of the 9.4? Are you excited about it as I am?

I also wanted to thank all the users who were able to attend the sessions dealing with water, wastewater and public works and those who stopped by the industry island. We had a great turnout and fantastic feedback. Some of you had a chance to talk to the water team and share some great information. If you did not get a chance to talk to the team or you wanted to follow up on the conversion, please send a note to ArcGISTeamWater@esri.com. We also started a new thread on the forums so you can post your enhancement request, success stories, bugs or issues you may encounter with the templates. You can also use these forums to talk about any other issues you may need help or advice.

The direct link to the post for the templates is:

http://forums.esri.com/Thread.asp?c=55&f=426&t=286881

Here is the link to the forums:

http://forums.esri.com/Forums.asp?c=55

Thank you and looking forward to hearing from you.

ArcGIS Team Water