Optimizing Refuse Collection Routes in Fairfax County, VA

Fairfax County, VA is a fast growing county in the Washington D.C. metropolitan area. The county office of Solid Waste Collection and Recycling has the responsibility to collect refuse and yard waste from roughly 38000 homes. (The shaded areas in figure 1a

Fairfax County has implemented an enterprise wide GIS with a core staff of GIS professionals and a number of user agencies. The central GIS staff develops applications using Arc/Info, ArcView, Map Objects, and MOIMS and also has power user skills with those products. The county user community primarily uses ArcView or custom applications. (Figure 1 shows the relationship between the county GIS staff and its user agencies.) At the start of this project RouteSmart was entirely an Arc/Info application and therefore all of the database construction and software use has been done by members of the GIS staff with institutional and managerial input given by members of the Collection and Recycling staff. Since that time the bulk of the functionality of the RouteSmart Arc/Info system has been ported to the ArcView environment.

Prior to this project, the Solid Waste Collection and Recycling Department had 16 daily routes for collecting refuse and yard waste. Each route was performed using one 10-ton truck (waste capacity) and a crew of three. These routes were run first for refuse and then a second time for yard waste. The employees worked, (and still work) on a task system, once the routes have been completed a second time, then they can leave for the day. Except for the peak yard waste season, (Apr. � May, Nov.), employees would not need to put in a full day before leaving. During the winter months the routes were run once for refuse and then employees left for the day.

The routes were generally based on number of stops, however the yard waste will vary quite a bit from area to area. This tended to make the routes unbalanced, generating complaints from the crews that the workload is unfair. The ideal scenario is for routes to be based on time, RouteSmart provides that GIS functionality.

A further problem with the old system was the lack of flexibility. If houses were added or removed from a route it would not change. This was not a problem most of the time but there is always the potential for a new development. Using RouteSmart the county staff can easily generate new routes based on updated conditions. Without RouteSmart, generating the new routes would be a very time consuming process and there would be no mechanism to alter existing routes other than a manual manipulation of all 38,000 homes into routes. Although there is relatively little development in the collection area for the county, there is always the possibility of a global change in collection policies. For example, if the county started burning yard waste instead of composting, it would require the creation of an entire new set of routes. With RouteSmart this is easily accomplished.

Another problem is that there are several town house developments the county collects refuse from but does not collect yard waste from. Prior to RouteSmart, these routes were given more houses to balance the workload. When there is little or no yard waste (Jan. - Mar.) however, these routes were no longer balanced with respect to other routes.

Finally, there was no system to calculate the most optimal travel path for any collection area. Drivers were assigned a route area and then determined on their own the best way to traverse that area. Complicating this was the fact that it was very difficult to create maps of any route. Route maps were generally hand drawn on top of tax maps and therefore difficult to produce.

It is significant that members of the Solid Waste Collection and Recycling staff who recognized that the GIS could provide a unique solution to their business problems initiated this project. The project was not the result of the GIS staff marching their flag into a user agency touting the virtues of GIS.

RouteSmart is a route optimization software package created by Bowne Distinct Ltd. At the time of purchase in 1997 the sanitation component was entirely an Arc/Info based system. (The company has since ported most of this functionality to ArcView in the form of extensions). The sanitation component was built specifically for the refuse collection industry. There are database elements specifically designed for refuse collection such as whether a truck can service both sides of the street, the time at the dump or transfer site between loads, the amount of time it takes to service a particular stop, and several others. The Arc/Info system had a great degree of plotting functionality and some very high quality mapping products and reports. The ArcView version will create the reports however the mapping functionality is still not as comprehensive as the Arc/Info system. The big advantage of the ArcView version of the software is the speed at which you can prepare your data for routing and the ease of use. We switched to the ArcView version in July of this year. I will provide a more detailed comparison later in this paper.

The ArcView version of RouteSmart requires that the user have a street centerline layer and a customer layer, both stored as shapefiles. The Arc/Info version also requires a routing database that is stored as a separate INFO file. In the ArcView version, most of the information that was associated with the routing database has been combined in either the customer shapefile or the street centerline shapefile, this includes information such as stop-time at location and vehicle speed.

There is some fieldwork that must be completed before you can generate new routes using RouteSmart. Aside from verifying street data, you will need to collect information such as the time it takes a refuse crew to load garbage once the vehicle has stopped. This is referred to as stop-time and is stored on a per-house basis. When creating the routing database you will also need to store the average pounds per house. This average can vary from area to area. We used tickets from the dump to calculate these averages.

The accuracy of your customer and street centerline layers will influence the results generated by RouteSmart. The following two paragraphs describe the level of effort required to get those data layers to what we felt was an acceptable level.

Street Centerline Layer

Our street centerline layer had a high degree of positional accuracy, however the address range attributes were originally conflated from GDT data and therefore only provide about a 90% match rate on residential addresses. At the start of this project there were no speed limits attached to the street segments and there were no turn values associated with any of the intersections. A member of the GIS and Mapping staff entered the speed limit values and another member of the same staff entered some turn values. The methodology we used to enter turn values was design by Greg Plumb from Johnson City Tennessee. (You can download his paper "Preparing Networks for Routing Applications" from the Esri Web site in the 1996 conference proceedings.) Route supervisors with institutional knowledge about the service area gave input as to what the turn values should be. After RouteSmart generated an initial set of routes, a test-drive revealed some "paper streets" and a few missing streets. Members of then GIS staff updated the street centerline layer to full completeness. What is important about this whole process is the desire to implement RouteSmart effectively almost forces you upgrade your street centerline data. If you haven�t already done this, the cost savings generated by RouteSmart justify the improvement of this data that can be used in many other applications.

In order to create a customer layer the GIS staff geocoded the Solid Waste Collection database. Members of the Mapping Department Staff as well as an intern in the GIS department did the geocoding. Most of these points (about 35000) geocoded easily. Because of the inaccuracies in our street centerline, the remaining 3000 required quite a bit of editing to the street centerline network before they would geocode. The editing consisted of updating and entering correct address range values. A member of the Mapping Dept. staff completed this task. About 400 points had to be placed manually by a member of the Mapping Dept. staff using an avenue script.

This was a time consuming task but was necessary to generate meaningful routes. RouteSmart assigns customers to the nearest street segment for routing purposes. Since many of the points ended up closer to an adjacent street, they had to be manually moved to their correct parcel. This is especially significant for corner or end lots.

The initial area for implementation was the Monday collection area. This area contained approximately 7140 homes and is located in the southeastern section of the county. This area is an older, more established section of the county with very little new development. The area also has a wide variety of home styles ranging from large single family homes to townhouses and duplexes. The yard waste also varies significantly in this area due to the variety of home styles.

In the RouteSmart software, a proposed set of new routes is termed a "solution". Based on our field data, RouteSmart computed a solution that indicated we could service the Monday area with only 10 refuse routes. Figure 2 shows the solution with different colors representing each route. Figure 3 shows a blow up view of one of the routes. In the Arc/Info version of the software, the user has the option to print a set of "route maps" for each of the route areas. The ArcView version prints route maps but they are not as appealing as

those from the Arc/Info version. The route maps from the Arc/Info version are meant to be used as a booklet, where one map ends the other map begins. Both versions of RouteSmart have the ability to show special symbols for backdoor customers and other special service customers. Both versions also provide very sophisticated travel reports. Figure 4 is an example of a travel report from the Arc/Info system.

The fact that the ArcView version doesn�t produce a sophisticated set of route maps like the Arc/Info version may not be a significant issue. While the route maps and travel reports are excellent quality, the necessity of these items is debatable. Local knowledge such as congestion at certain times and avoiding school zones at key hours of the morning is very difficult to program into a computer. I have also come to appreciate refuse drivers can take certain liberties with their vehicles that no one in their right mind would dare instruct them to do. Our research of other implementation sites showed that in at least one place (San Diego, CA), crews were given the freedom to drive the routes the best way they saw fit but were not paid overtime if they deviated from the computer generated shortest path. The real value of RouteSmart as it applies to high density routing is not necessarily generating the shortest path for a given route, but rather in generating balanced routes based on time and providing the ability to generate new routes quickly based on changing conditions.

During our implementation crews were assigned routes in areas they were already familiar with. This had both positive and negative results. Because crews were familiar with an area, most tended to drive the routes in ways they felt comfortable with and did not follow the route maps. Some drivers also had trouble following the maps and directions. Despite these issues, by the second week all but one crew was returning to the depot in time. The positive effect of assigning crews to familiar areas was that this probably resulted in fewer houses being missed. The overall miss rate was less than or no worse than normal.

The pilot began in January of 1999 and has continued throughout the year. January was targeted as an ideal starting month because this would leave several crews in reserve in case there were significant problems or in case one or two of the routes were completely out of balance. As it turned out, there were no glaring problems and for the most part the routes were well balanced. There were several occasions where a truck broke down and one of the reserve crews was sent out to finish the route. Starting the pilot in January also gave us three months to iron out any bugs before implementing the yard waste portion of the project.

The most important data acquired as a result of the pilot implementation is: IT WORKED!! By the second week of the refuse implementation all but one truck was coming in on time. One of the byproducts of the RouteSmart implementation is the ability to isolate crews that are not performing as well as others. After collecting several months worth of data, the one crew that had substantially longer running times was switched to another route. In, time we will know if the slow times were due to an unfair route or a poorly performing crew. The following table shows the reduction in the total number of refuse and yard waste routes for each period of the year. Yard waste statistics show that we could go from 16 to 14 for much of the year however that has not been implemented yet.

There were other positive byproducts of the RouteSmart implementation beside better statistics on crew performance. Prior to the implementation, refuse crews would routinely put yard waste in with refuse in order to leave early, often in very creative ways. Using RouteSmart allowed the county to change the operational procedures so that crews only collected one type of waste.

At the onset of the implementation, there was some concern that the collection crews would provide some resistance to the project. After all, the good old days were officially coming to an end. Despite some rumored talk of "breaking the system", the implementation went fairly smooth and field observations revealed that most crews were working at a diligent pace. However, being known as "the GIS person who created the new routes", my popularity statistics among the collection community reached an all time low.

One challenge we are overcoming is that refuse routes do not correspond to yard waste routes. The ramifications of this are that field supervisors must supervise a set of refuse crews for one area and a set of yard waste crews from a slightly different area.

Where this becomes important is when customers call in with complaints. There are two clerical staff members who field these calls and then notify the operations supervisor of the field supervisor responsible for the complaint location. Since the new routes from RouteSmart did not correspond to route numbers from the old system, the clerical staff had a difficult time determining the proper field supervisor to contact when complaints were logged. As it turns out, my popularity statistics among the clerical staff wasn�t too high either. For the full-scale implementation, installing an application that allows staff members to quickly view information about a complaint location will easily solve this problem. This application is being developed with Esri�s Map Objects.

Based on the success of the pilot implementation, the county will proceed with a full implementation of new routes in January of 2000. As mentioned earlier, it makes sense for us to make changes during the winter months so we can tackle one collection responsibility at a time. This will also give us time to transfer more ownership of the project to the Public Works staff and make them less dependent on the GIS staff. Switching from the Arc/Info based system to the ArcView based solution will simplify this transition. There was also some anxiety among crewmembers as to when the system would be changed for the next collection day. Rather than string the implementation out over an 8-month period, we felt it would be better change the remainder of the routes at the same time.

I would be remiss if I did not compare the two versions of the RouteSmart software. I have much more experience with the Arc/Info version however I have used the ArcView version enough to give it a fair evaluation.

The biggest difference is the amount of preparation and skill level needed before building routes. The Arc/Info version stores information in a separate INFO file called a routing database. There are AML�s in the software to help you create this, however to make it complete requires a working knowledge of INFO or TABLES. There is not a separate routing database in the ArcView version, all pertinent information is added to a customer shapefile or a street centerline shapefile. Even though the Arc/Info system has a graphical user interface, I often would transfer out of the software and enter commands at the ARC prompt. As such, to maximize the value of the Arc/Info system requires a sound knowledge of Arc/Info.

To this point in our project, all of the analysis performed using RouteSmart has taken place in the GIS Department and not the Solid Waste Collection & Recycling Department. While the latter of those two has some casual ArcView users, they do not have any staff members with Arc/Info skills. One of the future goals for the project is to train some of their staff members to use RouteSmart. Switching to the ArcView version of the software has simplified this process immensely.

The ArcView version of RouteSmart gives the user the capability to perform high-density neighborhood routing (such as Refuse Collection) and the ability to perform low-density routing over a much larger area (entire county, city, etc.). We are currently working on a project to route refuse vehicles that collect from county facilities and school locations. We used RouteSmart to develop a routing plan in a short period of time.

The Arc/Info version does offer some options not currently available in the ArcView version. While both versions provide excellent written reports, the Arc/Info version provides far superior map output. The user is given the option to produce a set of "travel path maps" for each individual route. These maps are a sequential set, where one ends the next begins. The AML�s that create these maps are not encrypted, therefore you can customize them using special fonts and symbol sets. I put a great deal of effort into customizing the maps and finding the optimum scale to use. Unfortunately, not every crew followed the maps. Some crews followed portions of them but others looked at the overall area and developed their own travel path. Field observations from one crew showed that the driver had a difficult time reading the maps. One of the goals for the final implementation will be to analyze the difference between the distance RouteSmart has computed for a route and the distance crews are actually driving.

The Arc/Info version will also incorporate turntable values if you have them as part of your street centerline network. My understanding is the company has plans to incorporate this functionality into the ArcView version. There is a limitation of 30,000 turntable records in the Arc/Info version. I was the first and as far as I know the only user to exceed this limit. Both systems offer the user the opportunity to enter turn and one-way restrictions within the software however I do not recommend this. In an enterprise GIS the street network is often one of the two most widely used layers. This type of information should be stored in a more central format so all third party applications as well as ArcView and Arc/Info can use it.

Based on the success of the pilot project, we will continue to optimize our collection procedures by implementing new routes in January of 2000. In the meantime, the GIS staff will train members of the Solid Waste Collection and Recycling staff to use the ArcView version of the software. We will also be in a better position to respond to changing conditions. Aside from possibilities mentioned earlier such as burning yard waste instead of composting, there are several other system changes which would require a whole to set of collection routes. These changes could include: switching the work week to 4 ten hour days, switching to two man crews, and changing vehicle types to fully automated loaders. Should any of these conditions occur, using RouteSmart would put us in a position to new routing plans quickly.

Since we have a data layer of our customers, we will also look into applying GIS to our "special collections" responsibility. The county collects white goods and large debris based on customer requests. The requests total on average about 62000 a year. We have not completed a comprehensive analysis however a cursory investigation indicates GIS we be an excellent tool to optimize the collections.

Brendan J. Ford

Application Development Coordinator

Fairfax County, VA GIS

12000 Government Center Py. Suite 117

Fairfax, VA 22035-0010

brendan.ford@co.fairfax.va.us

703-324-3792 (voice)

703-324-3937 (fax)