Stephen G. Lee
Brian Welander

Routing Meter Readers… Leveraging an investment in data conversion!

Abstract

Seattle Public Utilities delivers water to over 174,000 customer accounts. In an effort to provide better service to the ratepayer, it was believed that cost savings could be realized by creating more efficient meter reading routes. In 1995, the Metering and GIS Sections joined together to explore the feasibility of rerouting meter reading routes. In 1996, RouteSmart Technologies was selected as the routing software vendor. A pilot project in 1997 convinced management to implement citywide routing. The savings originally expected are being confirmed as software from RouteSmart Technologies and Esri has assisted in leveraging the utilities prior investments in data conversion.

Background

The Pacific Northwest is surrounded by a natural beauty that some consider among the best in the world. The City of Seattle is fortunate to be part of that environment and has a duty towards the protection and management of a portion of the regions fresh water supply. Seattle Public Utilities (SPU) is the City department responsible for delivering high-quality drinking water to its citizens, regional municipalities, and special districts.

We Provide World Class Utility Service!

In 1997, SPU was created by merging the functions previously provided by the Water Department and Engineering Department. SPU combines water, solid waste services (garbage/recycling), street drains and sewers, and engineering services. The motto, "We Provide World Class Utility Service" captures a tradition of excellence in infrastructure and utility management along with an new focus on customer service, environmental stewardship, and integrated planning and operation. Providing better service through improved operations with the use of GIS Technology is the focus of this paper

What is the role of meter reading?

Meter Reading is a vital function in the collection of revenue for many water utilities. The Metering Section is responsible for reading over 174,000 water meters throughout the metropolitan Seattle area. In addition, the section is responsible for maintenance, repair, and testing of all inventoried water meters. The majority of the installed meters are divided among residential (85%) and commercial (12%) customer accounts. The remaining meters in the field (3%) are classified as municipal, fire protection, and purveyor customer accounts. One-inch and three-quarter inch water meters account for the majority of the water meters (92%) in the field. The largest water meter is 24 inches and these large meters are used in a handful of commercial and purveyor accounts. The meters that register large water volume usage (e.g., commercial, purveyor, and industrial accounts) are read monthly, while the remaining meters (e.g., residential accounts) are read bimonthly. SPU has 1,115 meter reading routes (240 monthly and 875 bimonthly) throughout the service area.

How was routing accomplished in the past?

SPU has been reading water meters using walking and driving routes that have been in existence for years. The routes evolved as the City grew and service area annexations occurred over time. No major adjustments to the routes have taken place in recent history. The Metering Section has a crew that services 15 to 22 routes on any given day. Depending upon the customer billing cycle, some meter readers are assigned driving routes to read commercial, industrial, and purveyor meters.

In the past, a new service was added to an existing route by researching adjacent service numbers and route sequencing. The new service was then manually assigned a billing cycle, route, and sequence by entering the information into the customer billing system.

In 1995, there was an effort to manually reroute monthly routes throughout the entire City. Customer accounts were plotted on maps produced by the GIS Section and tracked using color coding for existing routes and meter sequencing. All customer accounts were plotted within four months. The manual approach to route development required knowledge of city streets, traffic patterns, and the time required to access individual meters. Knowledge of these elements determined how many meters to assign to a new route as well as the sequencing of the meters. Thirty-six (36) routes, consisting of 130 to 229 meters each, were manually rerouted in approximately one month. The new routes were entered into the customer billing system during a two-week period between final customer billing and transferring route information to the ITRON Automated Metering System. The two-week "window" period was used to accomplish quality assurance and field verification of routes. The Metering Section was able to perform data entry, route documentation, and route tracking for approximately 200 customer accounts per day. Roughly 6000 accounts were rerouted in this manner. Manual rerouting the entire City at this rate was estimated to require over two (2) years.

What are the shortcomings to the current process or routes?

The current process of reading individual meters is a necessary function that will not be eliminated as long as manual meters are used in the field. Automated meter reading has been considered; however, manual meter reading remains the current technology. The routes themselves can be improved to eliminate inequities in workload balance as well as to increase the overall productivity on the specific paths taken in any given route. Currently, there are some routes that have less than 8 hours of work while others are near or over a full day’s work. These inequities are becoming worse in the geographical areas throughout the City that have experienced a boom in new construction. SPU believes that it has now reached a point where the entire meter reading routing system needs to be rebalanced. Advancements in the GIS Technology enables software tools to be built that make citywide rerouting practical.

What are the driving forces to change?

The surge in new construction is attributed to landuse rezoning, which allows for smaller lot sizes for single family units. SPU has observed a direct correlation in the increase in water service applications to the new zoning policy. Large parcels that can be subdivided under the new zoning tend to aggregate in certain parts of the City rather than be uniformly distributed. The clustering of new growth places a strain on the meter reading routes servicing growth areas as far as being able to "pick-up" additional meters; therefore, accentuating workload imbalance among the routes.

Another factor driving change is the belief that routes in general can be more efficient in the sequencing of water meters. A close examination of the field conditions that impact what paths can be navigated on foot or by motor vehicle has not been addressed in a systematic way. Understanding these field conditions and working with routing software is believed to result in some cost-savings alternatives.

Finally, public concern over the lack of time spent in the field by meter readers on certain routes has emphasized the need to rebalance the entire meter reading workload. Public and media input has helped to prioritize the meter reading rerouting effort at SPU.

Problem Statement

Seattle Public Utilities has a workload imbalance among meter reading routes that negatively impacts the overall productivity in meter reading.

How did SPU know a rerouting project was feasible?

In 1995, the Metering and GIS Sections joined together to explore the feasibility of rerouting meter reading routes. The Metering Section provided the specific business requirements perspective while the GIS Section provided a technology and data perspective in an effort to provide a workable business solution. Participation at the National Meter Reading Conference and Esri User Conference enabled both sections to learn the latest technologies used to address the problem of improving workload allocation among meter reading routes. More importantly, the conferences enabled face-to-face conversations with industry peers, vendors, and consultants.

Further, discussions with RouteSmart Technologies at the conferences as well as during an onsite demonstration in Seattle gave SPU a better understanding of the data and process requirements necessary to perform a successful meter reading rerouting project. A GIS applications feasibility study by Roy F. Weston, Inc. indicated that a project was possible given that SPU had recently converted customer accounts to an ArcInfo Librarian data layer. Finally, reference checks of organizations that had completed or were in-progress with meter reading rerouting projects provided additional input into the decision to proceed with a limited pilot project.

A pilot project enabled SPU to test the converted data, modeling parameters, modeling techniques, link to the customer billing system, customized software, production scheduling, manual procedures, field verification of routes, and system administration requirements. The pilot was a partnership between the SPU Metering, SPU GIS, RouteSmart Technologies, and Roy F. Weston, Inc. The pilot area covered about one-tenth (16,098 accounts) of the meter readings service area. A variety of field conditions were represented in the pilot area that SPU was particularly interested in learning how route modeling would be able to handle. The key findings from the pilot were:

1. complete data coverage of customer accounts is vital to meaningful modeling results
2. information on some meter locations stored in the customer billing system required human intuition to interpret when the service location and service address were different
3. field conditions could be handled reasonably well by proper assignment of various modeling attributes and parameters
4. meter reading rerouting is a full-time effort requiring dedicated staff

Although the pilot identified some problems with data and processing procedures, each problem identified could be adequately addressed. In the summer of 1997, SPU decided to proceed with citywide production meter reading rerouting.

Project Overview

Production meter reading rerouting began in the Fall 1997. The service area was divided into two datasets along a natural waterway, known as the Ship Canal, that carries marine traffic between Puget Sound and Lake Washington. This division helped to minimize the overall size of a single dataset as well as incorporate flexibility into data preparation schedules.

Figure 1 illustrates the production workflow used on the project. The ongoing business processes (outlined in black with black text) typical of any metered water utility (i.e., Meter Reading, Billing, and Audit) appear on the left side of the diagram. The ITRON Automated Metering System and Combined Utilities Billing System (CUBS) are important to field data collection and the processing of customer accounts. GIS and RouteSmart^TM Modeling System (outlined in blue with blue text) are key systems enabling citywide meter reading rerouting. The primary rerouting activities (outlined in red with red text) are Routing, Data Upload/Download, Final Quality Assurance, and Data Exception Handling. A rerouting project can be characterized as a "data driven" project. The success of a rerouting project depends heavily on the accuracy and completeness of the information contained in the modeling datasets. Figure 1 identifies two data conversion tasks (outlined in blue with black text): (1) Water Services Data Conversion and (2) Routing Dataset Preparation. The next two sections focus on these important efforts.

Figure 1. Seattle Public Utilities Meter Reading Rerouting - Production Workflow

Water Services Data Conversion

SPU completed building its basic water infrastructure layer (i.e., water mains, hydrants, and appurtenances) in 1993. The GIS Section realized that many business functions throughout the utility required customer information in GIS before several beneficial applications could be developed. The water services data conversion in 1994-95 enabled SPU to pursue meter reading rerouting.

The GIS Section, CUBS Section, and Roy F. Weston, Inc. developed data conversion specifications. A significant finding during analysis was the identification of a text-based service location description (SVLOCDESC) per customer account that could be used by an automated process to generate water service arcs in an ArcInfo coverage. There are four (4) primary hurdles to the data conversion approach.

1. categorization of candidate service location descriptions
2. decoding of candidates within logical category
3. automated placement of decoded candidates
4. visual inspections and correction of automatically placed services

Figure 2 illustrates the logical processing steps employed to convert a text-based service location description into an arc feature.

Figure 2. SPU Water Services Data Conversion – Logical Processing Steps

Categorization of the SVLOCDESC text field was possible since the location descriptions contained abbreviations and "look-a-like" spelling that made reference to features such as right-of-way margins and parcel boundaries. Once categorized, the candidate SVLOCDESC was decoded into description components by parsing the text description into a measurements value (e.g. 23 feet), street or parcel line (e.g., north margin), and in the case of rights-of-way, street name (e.g. NW 68^th ST). Similar parsed components were extracted for other categories. The next step incorporates geoprocessing using spatial processing commands found in ArcInfo. Automated placement incorporated the processing power of the GENERATE and NEAR commands to create point and line features relative to known GIS features (e.g., right-of-way margins). COPY, COPY PARALLEL, MOVE, and EXTEND were some of the editing commands used to complete the automated creation of water service features. The final hurdle was the visual inspection of the automatically generated service arcs. This is a manual step requiring the review and editing of service arcs on an edit plot.

Service location descriptions that did not provide measured values were located to the center of the correct parcel by addressmatching the service address to a parcel polygon coverage and related address file. The creation of service arcs for these accounts were labeled as "Schematic" since the measured placement of the service arcs could not be determined. Finally, some accounts were not placed using any of the automated techniques described above, and were later placed manually under a "Drafted" approach.

What is it about the water service data layer that allows it to be leveraged to meet the needs of meter reading rerouting?

The water services data conversion requirements were based on general mapping and query needs of field crews and customer service representatives. An understanding of the ArcInfo data model and geoprocessing strategies resulted in the creation of a water services data layer with internal data consistency. Data consistency in arc orientation enabled the meter reading rerouting project to leverage this valuable data source.

Figure 3 illustrates the general orientation of water service arcs (white) extending from water mains (blue) into parcels (green). The "from" node of the service arc is always coincident with a point on the water main and the "to" node is always located in the parcel to which water is supplied. The "to" node coordinate was the basis for the systematic creation of point features that became customer locations for route modeling.

Figure 3. Orientation of Water Service Arcs - "To" Node Towards Parcel

Another important element to leveraging the water service layer was maintaining the customer service number. The customer service number enables the GIS to access additional information from CUBS when the need arises. For example, information regarding existing water meters and metering routes was not originally downloaded to GIS during the creations and initial maintenance of the water service layer. Meter reading rerouting requirements identified the need for this information and subsequent access to the information was possible.

Routing Dataset Preparation

Data accuracy and completeness are critical in order to create the most efficient routes possible. Customer accounts that are inaccurately assigned to a given street can result in routes that exclude one of two water meters that are only a few feet from each other in the field. Field conditions throughout the City that routing software must model are handled by assigning appropriate values to feature attributes and modeling parameters. Accurate street network topology is very important in generating realistic modeling scenarios. A combination of automated geoprocessing steps and manual data editing enabled SPU to prepare modeling datasets suitable for the project. The project has resolved many data issues and the remaining problems pertain to customer accounts not contained within the routing dataset. The project has defined an activity that identifies and corrects these situations before placing the modeled routes into production.

RouteSmart^TM Neighborhood modeling is accomplished in ARCPLOT, and uses datasets that are in ArcInfo coverage format. Point-to-Point modeling is accomplished in ArcView, and uses datasets in shapefile format.

The primary modeling datasets required by RouteSmart^TM modeling software are based on the Water Services Layer (SERVICE) and the City’s Street Network Database (SND). SERVICE provides the foundation for creation of the customer locations (CUSTCOV) coverage. As described earlier, CUSTCOV is a point coverage created by extracting the "to node" of the water service arc features in SERVICE. The point features in CUSTCOV are known as "customer stops" and have modeling attribute fields that store values used during modeling.

The City’s Street Network Database (SND) provides the basis for the street centerline coverage required for modeling. The City’s SND is used primarily for addressmatching and this project defined new topological requirements for the SND. It was determined that modeling required a modified version of SND in order to make accurate routes. Editing staff reviewed each overpass and underpass situation in the street network to ensure that street arcs did not intersect when in reality there was no physical connection between the streets that would allow for vehicle or pedestrian travel. In addition, there were pseudo nodes (remnant from prior geoprocessing) that needed to be removed in order to accurately distribute theoretical address ranges along street blocks. On rare occasion, street arcs that looped around and closed on the same node (i.e., to/from node have the same coordinate values) had to be split in order to satisfy software modeling requirements. A node coverage (NODECOV) required for RouteSmart^TM modeling is calculated from the street centerline coverage.

An INFO data file known as the Routing Database (MET.DAT) was created specifically for RouteSmart^TM Modeling. MET.DAT contains modeling attributes that define walking and driving characteristics for each street segment in the modified SND.

A point coverage (FACILITY), also known as Office in Point-to-Point modeling, was built to identify the starting and ending locations of modeled routes. SPU decided that, due to variable conditions impacting the time required to get a meter reader to the head of a given route, the impact of travel time from a given facility to the head of a given route would not be modeled. This was accomplished by customizing the RouteSmart^TM software to assign zero time travel from a given office location to each node on the street network. Therefore, each facility location SPU created is arbitrary, but necessary for RouteSmart^TM modeling.

Other coverages that are helpful during display and plot creation are City boundary lines (TOWNBND), street names (STCLANNO), and street rights-of-way (BUFCOV).

How field conditions were handled?

Seattle is bounded by Puget Sound to the West and Lake Washington to the East. The City is physically divided into North and South halves by a shipping canal. The terrain rises steeply several hundred feet on slopes from sea level to the bluffs overlooking Puget Sound. Water meters in these areas are located along the shoulders of winding roads with no sidewalks.

In addition to the physical boundaries between land and water, greater Seattle is developed on hilly topography that presents some interesting problems and situations for meter readers. Ravines along hillsides create dead-end streets that have water meters that are sometimes traversed by trails or walkways (often not mapped in the GIS). Steps are located at the end of some streets to allow foot traffic to climb from Lake Level to a street above. In some cases, a customer stop is correctly placed according to a service address; however, the meter location is in reality uphill or downhill from the front of the property address.

SPU considered overlaying topographic data layers to identify customers on steep slope areas. However, it was determined that the resulting findings would be of limited value since the steep slope areas tend to have streets that are constructed to follow contours, thus eliminating the thought that extra time was required to travel up and down streets in steep slope areas. Therefore, assigning customer stops on steep slope areas with higher service times was not done. The overall impact of topography on service times was accounted for by a less precise approach. Each customer location falls within a utility map area and the map number is stored in an attribute of CUSTCOV. General trends in topographic relief was accounted for by map number and adjustments in service time values were made by map number link. Individual customer stop locations with unique situations were identified, and stop time values modified accordingly via interactive editing.

The perennial problems with moles and a lack of sidewalks in some areas are handled by adjusting the time required to service the customer stops. Field conditions impacting the speed at which a meter reader could walk, or the speed at which a vehicle could travel are handled by parameters in the routing database.

Routing

Why was RouteSmart^TM Selected?

RouteSmart Technologies was selected to provide the modeling software after researching the Meter Reading and GIS communities for organizations with a proven track record of providing routing solutions. SPU and Roy F. Weston, Inc. had considered developing an application solution with ArcInfo NETWORK software, however, the complexity of such an undertaking prompted the search for a routing software vendor. Both Esri and Roy F. Weston, Inc. recommended that RouteSmart Technologies offered a cost-effective software solution to our meter reading rerouting needs. Finally, reference checks of existing routing customers convinced SPU that RouteSmart^TM was a reasonable choice.

Route modeling comes in two flavors!

RouteSmart Technologies licenses two distinctly different modeling software products. The Neighborhood modeling package addresses the situation where a large contiguous distribution of water meters need to be read. The intended use of Neighborhood software is for daily meter reading operations and cycle realignment. The Point-to-Point modeling package addresses the situation where water meters tend to be scattered and/or dispersed across a larger geographical area. Typical uses of Point-to-Point software include missed reads, maintenance calls, and turning on/shutting off services. SPU uses Neighborhood and Point-to-Point modeling to reroute walking and driving routes, respectively.

What is the actual routing process?

A brief description of the routing process is presented at this point as the focus of this paper is not on the actual modeling process. Neighborhood modeling is accomplished within the ARCPLOT environment. Functionality is provided to the user via menus that allow the user to specify working datasets, define record sets to model, set display options, estimate workloads, generate routes, sequence customers on routes, edit routes, and generate output. The first task in Neighborhood routing is to create aggregate routes that contain customer stops in a billing cycle. The modeling software determines the distribution of customer stops to aggregate routes based on parameters set by the user. These parameters specify constraints on the overall workload allocation estimate based on the number of available meter readers or available time. Additional parameters can be specified for the time taken by meter readers for breaks and office preparation. Aggregate routes are generated after an acceptable workload estimate is calculated.

After aggregate routes are generated, individual routes are created from each of the aggregate routes. The individual routes are routes that a given meter reader completes in a day. The customer stops on the individual routes can be sequenced to create a travel path. Both aggregate and individual routes can be edited by reassigning customer stops to other routes under a process called "swapping". Editing is required in accordance with specific knowledge the user has, over what the modeling software is able to calculate. Finally, when desired routes have been created, they are assigned a SPU preferred billing cycle number that is consistent with the billing revenue sequencing, instead of the geographical sequencing assigned by RouteSmart^TM . Complete routes are transferred (i.e., uploaded ) to the customer billing system by cycle number.

What has SPU learned about modeling?

Accurate and complete preparation of the street centerline coverage and Routing Database are very important to creating acceptable routes. The street centerline coverage must be topologically correct for vehicle and pedestrian travel. An effort should be made to code modeling attributes with turn restrictions that represent actual limitations to travel (e.g., concrete median barriers that prevent left turns on major arterials). The manner in which a meter reader is allowed to walk along a street (i.e., meander from side to side or restrict travel to one side at a time) has a noticeable impact on the creation of routes. The service time assigned to customer stops is another important factor to balancing workloads. Assistance by meter readers during the pilot project helped in field verification of modeled routes and contributed towards establishing a benchmark of customer stop times. Further, field conditions beyond the pilot area were taken into consideration when determining an average customer stop time for each map number area. Customer stops with limited access or special field conditions were adjusted accordingly.

How are the cycles and routes better?

The number of meters assigned to each cycle and route are more evenly distributed under RouteSmart^TM than the manually maintained routes. Travel paths are more efficient on individual routes due to the tendency of the modeling software to navigate the street network in looped circuits. This modeling behavior is based on the Euler Circuit logic used by RouteSmart^TM. The number of meters assigned to each route has increased within the limits of an 8 hour working day, thereby, increasing the overall productivity of meter reading routes.

Figures 4 and 5 illustrates the difference in the assignment of customer stops to billing cycles before and after rerouting. The inset in Figure 4 shows an area of approximately 10 blocks assigned to a given cycle (blue). The inset in Figure 5 shows the same area, assigned to a second cycle after rerouting (red). The shift in customer assignment is an improvement because the modeled cycles are more compact geographically and increase the safety of the meter readers. The element of safety is not obvious in Figures 4 and 5; however, closer inspection of the street running North/South dividing the cycles (blue vs. red customer stops) reveals it to be a busy arterial which the modeling software recognized due to accurate data preparation of the modified SND. Therefore, meter readers are not required to cross busy streets as often as they have been in the past.

Figure 4. Customer Stops Assigned to Old Cycle Area

Figure 5. Customer Stops Assigned to New Cycle Area

Cost Savings

After rerouting a portion of the total production service area, SPU has been able to generate new billing cycles containing routes that are 16% to 46% more efficient than previous billing cycles as measured by the number of customer accounts assigned to individual routes. Considering the geographic distribution of the remaining customer accounts, as well as knowledge of the street network and field conditions, the Metering Section is forecasting an overall increase in route efficiency of around 20%. The reduced staffing levels required to accomplish meter reading will allow reallocation of some staff to other metering functions.

Summary

The need to rebalance inequities in the workload allocation of meter reading routes could not be delayed indefinitely. The combination of GIS and routing software provided the necessary tools and data in order to proceed with a reasonable citywide rerouting effort. Production rerouting is currently progressing through the northern portion of the water service area. The entire City is scheduled to be rerouted by the end of 1998.    Project Update 1998-1999

References

RouteSmart^TM Neighborhood Meter Reading Routing User’s Manual, Version 3.40, Bowne Distinct, LTD., April 27, 1997

RouteSmart^TM Point-to-Point Routing User’s Manual, Version 3.20, Bowne Distinct, Ltd., May 21, 1997.

Acknowledgments

The success of the meter reading rerouting project owes many thanks from contribution by management and staff at Seattle Public Utilities, Roy F. Weston, Inc., and RouteSmart Technologies. Special thanks go to the technical team of Paul Patterson (RouteSmart Technologies), Keith Palmer (Roy F. Weston, Inc.) and Rich Folsom (Seattle Public Utilities) for keeping the "nuts and bolts" together throughout data conversion, data preparation, and the rerouting pilot.

Authors

Stephen G. Lee
Senior Systems Analyst

Seattle Public Utilities
Dexter Horton Building, 9^th Floor
710 Second Avenue
Seattle, WA 98104
Telephone: (206) 684-7558
Fax: (206) 684-0808
E-mail: stephen.lee@ci.seattle.wa.us

Brian Welander
Senior Meter Reader/Systems Analyst

Seattle Public Utilities
Dexter Horton Building, 6^th Floor
710 Second Avenue
Seattle, WA 98104
Telephone: (206) 684-8074
Fax: (206) 386-1310
E-mail: brian.welander@ci.seattle.wa.us