Real Benefits - Advancing GIS Technology
Susan D. Wynne Assistant Engineer – Civil GIS Database Manager City of San Diego - Water Utilities Department 600 B Street, 10th Floor San Diego, CA USA Sdw@sdcity.sannet. gov Dennis F. Beck Solutions Engineering Director Smallworld Systems, Inc. 5600 Greenwood Plaza Blvd., Suite 300 Englewood, CO 80111 USA Dfbeck@,smallworld-us. coms
Introduction - GIS at San Diego Water Utilities
San Diego Water Utilities serves the city of San Diego, which is the seventh largest city in the United States with a population of about 1.3 million people, covering an area of about 400 square miles. The climate of San Diego is quite arid. The average annual rainfall is 6.7 inches per year. Without a well-managed water distribution network, the San Diego area would be able to support a population of no greater than 50,000 people. San Diego is well known for its mild climate, beaches and popular tourist attractions. The environment is sensitive, and there are numerous endangered animal species such as the gnatcatcher and others. Information management related to the massive water and sewer infrastructure of San Diego is no simple task. To solve the problems related to managing all the water and sewer data, San Diego Water Utilities became actively involved in GIS early on. With contracts awarded to two vendors to map the water and sewer infrastructure. Actual paper map conversion began in 1991. San Diego Water Utilities first went into production late in 1992 with the SPLASH application, based on the Arc/Info product from ESRI (Redlands, CA). The fundamental objectives of the original system were to be able to have a well-managed database so that the important infrastructure information could be available on a timely basis for all those that need to use it at San Diego Water Utilities. As a part of the GIS initiative, h was critical to have all of the mapping data into the system with regular updates to the sewer and water backlog. Unfortunately, the mapping backlog continued to develop due to conversion issues and problems with the production SPLASH applications. With the large investment that San Diego Water Utilities had made in GIS data, it was becoming more and more important to move from a mapping-based system to an enterprise approach that would allow the GIS database to integrate with other key applications in the utility. In 1994, a logical model was developed for GIS that could be used to support a preventative maintenance and work order system. The system development began using the ARC/Info system and the Oracle relational database management system from Oracle Corporation, Redlands, CA. In 1995, the enterprise database was built, and the integration process began. Why Technology Advancement? The original SPLASH system had already been excessively slow, and the system experienced significant periods of down time. The net result was that the backlog that everyone was working so hard to eliminate, continued to grow. We tried extra shifts and overtime to no avail. With the advent of the new enterprise database and all of the requirements it placed on managing the integrity of the data for critical business applications, it became apparent that the production could be slowed down by a crippling 500°/0. We were in IT crisis. A tremendous investment had already been made in GIS data, hardware, applications, and people skills. We now were looking at having to scrap the whole program. At the same time, the utility had ongoing challenges managing their network infrastructure. This was due in part to the rapid population growth that the San Diego community has had to endure for many years. Some problems occurred that received significant attention from the community and the US Environmental Protection Agency (EPA). Due to these problems, the EPA required that San Diego Water Utilities have the integrated work order and asset management system (SWIM) and the enterprise GIS database (SPLASH H) in production late in 1996. Here we were, in January of 1996, faced with EPA deadlines, stifling decreases in user productivity and pressure from onlookers to scrap all the hard work that had been done over the last five years. It was time to look seriously at technology advancement. San Diego Water Utilities and our information technology provider, San Diego Data Processing Corporation, went down two concurrent paths to address the tough issues we needed to face. First, we actively engaged our existing GIS vendor to work with us to try to resolve the technological problems we were having. We also started to look at new solutions that had entered the marketplace since we first began our program back in the early 1990s. Getting the vendors involved proved to be a very effective way to quickly determine whether or not we could solve the technological problems we were facing. We set up a benchmark with Smallworld Systems, Inc., of Englewood, Colorado to prototype our system and demonstrate how to solve key technical problems related to data migration, data modeling, database management, and plotting performance. The prototype went amazing well. In just two weeks, we were able to address all the problems that had been plaguing us for several years. And we also were able to chart out a path forward to migrate existing data and applications to a new technology environment that relied on our strategic platforms of Windows NT and Oracle. As part of our commitment to our existing GIS vendor, we extended a similar offer to meet the same benchmark requirements over a sixty-day period. At the end of this period, we realized that many of our objectives could not be achieved with the technologies we had been using, and it was necessary to rapidly begin to migrate to our new system. The deadlines were closing in! The Migration Process Once the agony of making the decision to migrate our system was done, we had no time to wait around. There were a number of key things that needed to be done. Main activities included datamodel development, pilot data translation, development of custom editing and productivity tools, system integration and plotting subsystem customization. Data migration and distribution was another critical step, and on the human side, it was necessary to have a comprehensive training program to support mapping users, developers, system administration and management. The importance of good training cannot be overstated in gaining proper user acceptance. While we spent significant time evaluating the decision to migrate the migration process really occurred quite quickly. Initial data model development was complete within two months, and we were ready to begin pilot data translation. The importance of the pilot was critical to our success, as we were able to develop options for improving the quality of the data during the translation process. Within three months, we had migrated the database to the new system. The use of object-oriented technology greatly improved the application development phase of the migration. Many of the applications on the existing system were no longer required since we were able to exploit the reusable components within the new system. Within 22 weeks, our users were in production, using the system to attack the backlog that had been developing for such a long time. Real Benefits The decision to migrate can often be quite agonizing for an organization to make. One of the key things to do early on in the decision process is to have clear objectives of what needs to be accomplished. In the case of San Diego Water Utilities, there were two major objectives that we had for some time that were not being accomplished during the then-current GIS initiative. First, there was a critical need to reduce the backlog of their mapping system. Secondly, they needed to integrate their system with other applications that were under development. This was necessary to address process improvements that would empower their field workers with mobile computing. Improving User Productivity The system was implemented with the objective of having a 50% improvement in user productivity. To better understand how productivity was improved, it is helpful to look at the problems that the users were experiencing with their existing system. Avoiding Check-in/Check-out One of the most pervasive problems was associated with having to perform check-in/check-out procedures to edit the data. In the legacy system, it was necessary to extract data on a tile basis prior to performing any edit operations. This check-out step had two problems that had seriously impacted user productivity. First, it was quite time consuming. Typical checkout times were anywhere from ten to thirty minutes. During this time, the machines were busy, and it was not possible to do other work activities at the workstation. The other problem, closely related to having the long check-out period, is the variability of the check-out time. It is not possible to plan other work when it is unknown exactly how long the check-out would take. Factors that impacted check-out time included size of the tiles to be check-out, density of the data, and processor load. The new system is based on a version-managed spatial database architecture. This allows all users access to the entire database without having to go through any check-out process. Rather than having to segment users on an area basis, which in this case was a tile, each user works in their own alternative of the database. There were two areas where this has been proven to be quite beneficial: the very simple jobs, and jobs that extend over large areas of the San Diego landbase. Simple jobs are the most common type of editing activity that is performed in the mapping department. Roughly 60 to 70 percent of the jobs involve relatively simple updates to the database, such as adding a fire hydrant or adding a new customer service. These jobs typically only covered one tile of the database in the legacy systems. It is fairly obvious to see that a simple edit job can become very time consuming if it takes 20 minutes to check-out the tile from the database, just a few minutes to do the actual editing, and then, anywhere from a few minutes to ten minutes, to do the check-in back to the database. The time to do simple edits has been improved tenfold with the new system. It has also allowed us to re-engineer the process in which we do our map editing work. In the legacy system, we had a tendency to save up jobs that are in a given area, which requires quite a bit of time just to manage. It also encourages procrastination of work, which is not a good practice for our office. The other area where we were able to capitalize on not having to check-out data was on the jobs that extended over large areas. This was most noticeable when entering the new San Diego reclaimed water system. Reclaimed water drawings were at a very large scale and could have as much as five miles of piping on a single map sheet. This would have required that we perform numerous check-out operations to enter this system. As a result of not having to do this, we were able to enter the reclaimed water system into the database in record time. Exploiting Obiect-based Modeling While eliminating check-in and check-out from the mapping process had a tremendous impact on improving productivity, there were a number of other areas that helped make the system deliver results faster. One key area was being able to have an object-based datamodel instead of having to deal with a layer-based system. The benefits of object-based modeling are more associated with the ability to better model real-world facilities. This is certainly an advantage for our system, but the positive impact on productivity is particularly helpful by-product. In a layer-based system, the objects and their related features are differentiated on a layer by layer basis. For example, mains may be on one layer, hydrants on another layer, and different pieces of annotation on their respective layers. This is not a problem until one has to edit the data. Adding a fire hydrant requires that the editor swap between several layers for the hydrant, the service and different forms of annotation, which are typically segregated on a layer basis. These swaps, in addition to being tedious and subject to error for the end-user, are also very time consuming when it is necessary to move between layers. In the object-modeling world, the user needs simply to draft the location of the new hydrant, and the system understands that the new drafting lines belong to the hydrant object. This important feature removes much of the decision-making that was done by the user and relies more on the intelligence of the object. Annotation is related to the object and is automatically generated for all specified scales and at the appropriate offsets to the object. Even for very minor editing work, this has dramatically improved the user productivity. Taking Advantage of Automatic Generation of Network Connectivity Another aspect of object modeling is the ability to pre-define topological relationships between objects. In the legacy system at San Diego Water Utilities, we had to rely on a special set of procedures to build connectivity between devices on our water network. It amounted to a complete set of steps that required the definition of certain types of connectivity constructs on different layers entered in the proper order. Like with creation of annotation, these steps were subject to skill and judgment of the user to ensure that connectivity was properly constructed. It was very time consuming, and even the best operators had the potential of introducing connectivity errors into the system. In the new system, connectivity is automatically built as objects are entered into the system. During the design phase rules were set up about how the different objects interact between themselves. For the user entering data, it is now only necessary to add the appropriate objects in the right location and the topology is automatically created. During the data entry process, the connectivity relationships are highlighted to the user so that they receive confirmation that the correct connectivity has been established. The productivity improvements were great, and the impact on quality was quite significant. Real Benefits Through Improved Quality Since the SPLASH II database is an important foundation for other applications, it has been critical that we have extremely high data quality. Through many of the features described above, we have been able to keep a much higher standard of quality in the system. This has been particularly notable in the areas of annotation quality and network connectivity. Since the system now does so much of the quality control work on its own, we are now able to reduce the amount of time we had spent in the past doing manual quality control checks. This, again, has been a significant benefit for the user community. The advantages of improved quality are often difficult to quantify. We have found there are obvious timesaving by eliminating the manual quality control processes, but the intangible savings are very real. These range from having an improved application development platform to the simple, comforting confidence we have when we take our data to the field. Avoiding one disaster can pay for the technology advancement in one chunk, but we can anticipate that we will reap the advantages of the improved quality one day at a time for many years. Benefits From Hardware Turnover We received real benefits simply by changing our hardware platform as part of the system migration. Hardware is considered to be a commodity for the most part, but it is an important commodity for the production GIS user. In our legacy system, we were users of UNIX workstations based on the IBM RS/6000 platform. With the migration, we moved to the Windows NT operating system environment for our client workstations. We retained our existing UNIX server. It still performed well, and we desire to continue to manage our data in the UNIX environment. The existing workstations had served us well, but by migrating our hardware, we received benefits in many areas. First, we were able to reduce costs. Our existing hardware typically cost about $15,000 per workstation. High-end NT workstations with added memory and 21-inch monitors now cost less than $4,000. Next, we also realized that the performance of the new workstations was excellent. This was due to the rapid acceleration of computing power that the PC marketplace has been experiencing for some time. Since the migrated applications were written in an environment that was independent of the hardware architecture, we were able to retain some of our UNIX hardware for running the GIS applications. Another advantage we received was the ability we gained to integrate our GIS applications with the office software products that also resided on our client workstations. An example of this is a work status report that we regularly create. We were looking at developing a special reporting application that would allow us to create different views of the data to show the progress of the work we were doing. Once we started looking at all the different options we wanted, we realized that it could be quite a time consuming application to develop. It also would require that we get trained on the use of the application. Once the application was developed, we would need to maintain it. Integrating the GIS data with Microsofl Excel solved this problem quite quickly. We now had a tool that gave us all the options we needed, and our users were already experienced in using spreadsheets for creating reports. As integration capabilities continue to improve in the Microsoft environment, we look forward to taking advantage of more of the synergies between GIS and Windows. The use of Active-X and COM/OLE will offer us ways of making the capabilities of GIS available to more users of desktop software without having to have the more expensive fill function GIS workstations. Process Improvement Through Enterprise-Wide Integration The GIS database is an important piece of a total enterprise-wide information system at San Diego Water Utilities. The database is tightly integrated with our Oracle-based asset management system, SWIM. SWIM manages all assets of the San Diego sewer and water systems, including plant information. The GIS contains a subset of the SWIM asset information, namely, those facilities that need to be reflected on the system maps. Through SWIM, the GIS receives updates from our field-based system and user terminals. A database replication scheme is in place to identify potential conflicts between the two systems and to present work to the users. The benefits received from this integration have allowed San Diego Water Utilities to significantly improve our work processes across the utility. Rather than making as-built updates on paper maps and then submitting them to the mapping department for update, the system sends the changes made on the field unit systems to the GIS on a nightly basis. Changes that are made in the GIS are sent to the SWIM asset database as part of the data synchronization. This has allowed the mapping team to eliminate a number of steps in the update process. Incoming work that does need to be updated is closely managed as a part of the replication system called the notification manager. All of the power of this system is worthy of a lengthy discussion that is outside the scope of this paper. To summarize, however, the system has allowed us to:
The Economics of Technology Advancement Since we have now used three different systems throughout the life of our GIS program at San Diego Water Utilities, it is possible to look retrospectively at the costs associated with the two systems. This, combined with the resulting benefits we have achieved, delivers a very favorable argument for the migration of legacy technology platforms. The following table is a summary of cost differences between the new system and the legacy platform. System Migration Cost Summary
One of the things that we found quite notable is that, while hardware and development costs have dropped, the software prices have remained relatively fixed. This is now a much more significant component of the solution relative to the price of the hardware. At the same time, we found that the software was key in allowing us to achieve the benefits we have received. Software costs are really insignificant when looked at in the scope of the whole system, and if they are not spent appropriately the software can actually be considered to have a negative value. This was the case with all the expenses we were experiencing with the high development costs and low productivity of our legacy system. For the Future Now that we have successfully solved the integration and productivity problems that have plagued us for so long, we are now able to look forward to doing bigger and better things. San Diego Water Utilities has a detailed five-year GIS plan that we are implementing. Our key objective is still to eliminate the backlog that has plagued us for many years. The backlog is making significant progress. We prepare hi-monthly management reports, and we are now able to show that there is a dramatic improvement. A current project underway has allowed us to correlate all the different drawing projects and quickly do the small jobs that were previously so time consuming to complete. In just six weeks, we were able to reduce the backlog from 788 drawings to 587 drawings for an improvement of over 25%. We are currently very much on schedule for completing the backlog by the end of 1998. Because we now have a high-integrity database to work with, we are now planning to use our system as a base to develop important applications that can utilize our network information. We are evaluating the use of software packages for fluid flow analysis on the water network, and our sewer modeling personnel are actively evaluating how to leverage some design applications. Because we have such a great source of important data, we also plan on distributing our information via what we call “intelligent Internet applications” during the latter part of 1998. Integration of our system with other parts of the city will continue to progress at a rapid pace. We have a project to interface our system with emergency management, and we also will be coordinating our hydrant information with data that is used by the fire department. We will also be supporting information for the San Diego weather stations. The list seems endless, but we are moving forward with a new optimism as a result of all the great progress we have made over the last year. Conclusion Through advancing GIS technology, we have been able to solve a number of difficult problems that had been plaguing San Diego Water Utilities. Our productivity has been greatly increased, and we are making tremendous strides towards reducing our backlog. We now have a functional enterprise database from which we can deliver future applications. The ever-so-elusive benefits we expected to see long ago are now there, for us to enjoy. When looking at technology advancement, it can often be agonizing to realize that there is change and uncertainty ahead, but we have proven that we were able to leverage our existing investments in skills, systems, and data, and move ahead much farther than we ever thought we could. Perhaps the best testimonials come from the individuals that work in the front of the system on a day-to-day basis. It is nice to come to work and hear user technicians comment that their system is “awesome,” or “it’s great!” From management down to the users in the field, things are moving forward at San Diego Water Utilities. | |||||||||||||||||||||||
|
|