Giving the power of GIS to field technicians

Giving the power of GIS to field technicians

William C. Peterson
Manager, GIS Business Alliance and Solution Delivery
Lone Star Pipeline Company 301 S. Harwood Dallas, Texas 75201

T. Michael Seaman
Programmer Analyst,Outfield GIS TM, 11900 Crownpoint Drive
Suite 100 San Antonio, Texas 78233

Abstract
The use of a Geographic Information System to accomplish a field operations task has significant potential benefits to increase worker productivity. Lone Star Gas Company has completed a pilot project to use their GIS graphics and data to complete leak surveys and leak reporting, and to integrate the information into an existing code compliance database. The selection of the appropriate field personnel to test the application was critical to the project, as well as a team of GIS staff, vendor, IS staff and contract programmers committed to meet the projects goals. A focus on software development and not hardware was also a key factor. The use of GIS graphics and data as part of a field application brings to focus the accuracy of landbase and address information, as well as the accurate mapping of gas facilities, and poses the need for a redlining tool to make corrections in the field. Based upon the successful completion of this project, Lone Star plans to implement the application company-wide by the end of 1997.

Company Information
Lone Star Gas serves over 1.3 million customers in over 520 cities and towns in north and central Texas. Approximately 60’%of the customers are in the Dallas-Fort Worth Metroplex area. The Lone Star Gas system includes over 22,000 miles of gas mains.

Project Background
In 1993, Lone Star Gas Company’s Distribution Division underwent a full-scale re-engineering effort. One of the results was the development of a comprehensive code compliance inspection scheduling, tracking and reporting system. At Lone Star Gas (LSG), the System Monitoring department was formed, with responsibility for all of the code compliance inspections for the gas distribution system. Since the first applications were developed for leak survey, leak detection and leak repair, this system became known as the Lone Star Leak System (LSLS). In parallel with the LSLS system development, Lone Star Gas had started the conversion of the gas distribution paper maps to a CAD-based automated mapping system. This conversion was designed to also capture the attribute data necessary for eventual use in a GIS system. When approximately 20°/0of the gas mains and services were converted, the System Monitoring department decided to develop a GIS application that would utilize the intelligent landbase and gas facilities, in order to decrease the amount of time spent finding and reporting leaks in the field.

Pilot Project
The pilot project goal was to develop an application that would reduce the time spent in the field sketching and reporting leak locations. During the design stage of the project, the areas of focus were:

The application should have only the features and menu selections that the technicians would use. No additional menu options should appear that the technician was to “ignore or not worry about”.
The software should pass information stored in the landbase to the existing leak management system.
Key features should include navigating to specific locations, query of attribute data, and a controlled sketching environment.

A technician typically spends 15-20 minutes completing each leak report, with most of the time spent drawing street intersections, street names and addresses, and leak migration patterns. A leak migration pattern is a map showing the extent that the released gas has traveled underground, based upon gas concentration readings obtained from probing the ground at several locations. Using this method, the technician is able to pinpoint the location of the source of the leak. The extent of the leak migration is one indication as to the degree of hazard that the leak poses.

Work Process
The LSG code compliance technician is a multi-functional worker that performs several code compliance surveys and inspections that are required by the Department of Transportation and the Texas Railroad Commission. The technician’s work includes leak surveys, cathodic protection surveys, regulator and pressure relief valve inspections, emergency valve inspections, odorant test points inspections, and patro areas. The LSLS applications have been developed to manage the back-office functions for scheduling, tracking, and reporting for leak surveys, cathodic protection surveys, odorant test point inspections, and emergency valve inspections. The LSLS currently allows the field technician to fax-in forms that are read by specialized software, to update the central database with completed leak survey, leak detection, and leak repair information.

The focus of the pilot project was to make the field technicians more productive in the leak survey process. The current process involves:

LSLS is used to track and schedule the leak survey jobs.
A leak survey work order is printed from the system and given to the technician.
The technician surveys the area designated by the work order, and makes up a leak report form for each leak that is found on the LSG distribution piping.
The leak form is a pre-printed form with bubble fields and character recognition fields that is faxed-in, and then validated by software at the central server.
A staff assistant will then review any faxed-in forms that are rejected by the system, and process it for correction of the errors.
LSLS generates a repair order that is electronically routed to the service center of the work crew assigned to the area in which the leak was found.

We also expected to achieve some back-office time savings, as the error correction process for the faxed-in forms would be eliminated.

Software Development
The vendor’s product, OUTFIELD.Leak Survey is a Visual Basic shell running on top of a licensed graphics engine written in C++. In the true spirit of rapid application development (RAD), the vendor had no definition of a leak survey field system to use as a pattern. It was, therefore, challenging to move from the utility’s general requirements to concrete specifications. To maintain a flexible development cycle, the client’s project specifications were loosely defined at the beginning and evolved during numerous brainstorming sessions. Programming began in Windows 3.1 l@ with the target being Windows 95@when support for that platform became available in the core graphics engine. Six weeks prior to the field pilot, the ’95 core was issued.

Again in a RAD environment, the Visual Basic shell was ported to the new platform. This pioneering effort was successful only because the client and vendor maintained a close partnership during the development period. The client provided the software developers with feedback and more specific definitions of functionality as they received input from people experienced in field work. OUTFIELD responded quickly incorporating the changes as well as solving problems in the software as they were discovered. Some issues were intentionally left open pending the results of the pilot.

The initial software development tasks included the following:

Develop a translation of the CAD drawing graphics and attribute data to a format that could be used by the field GIS. The maps from the CAD system included attribute data such as pipe material, pipe size, address, and street name.
Develop tools to navigate around the electronic map, including navigating by address, street name, street intersection, electronic mapsheet number, and the historical paper map sheet number. The paper map sheet is needed for transition purposes until all of the applications are developed, if we are to replace the paper mapbooks kept in the technicians’ trucks.
Develop a leak sketching tool in the GIS that utilized the Iandbase and facility data. The map area immediately surrounding the leak would be cut out and integrated with a leak detection report, along with address, street name, pipe material and size, and the x-y coordinate of the leak. The x-y coordinate of the leak would eventually be passed back to the mapping system to record the location of leaks caused by corrosion.
Develop a client version of the LSLS that would run the leak survey application on the field computer, including all data valid ity checks that are used in the centralized database.
Develop a method to transfer the leak sketch and data from the GIS to the leak detection reporting form in the client version of LSLS.

Unlike most field applications that mostly involve collecting attribute data to fill out a form, the Leak Survey application involves the integration of GIS data and graphics as part of the final product. This puts considerable focus on the GIS landbase, addresses, facility locations and attribute data to be accurate in order to report the leaks that are detected during a leak survey. Pilot Proiect Plan

The pilot project tasks included:

Develop a prototype application for leak detection reporting that allows leak sketching and entering the appropriate leak information.
Testing of application in office by the System Monitoring staff and the GIS planning analyst.
Make required software modifications.
Train field technician in an office setting using sample leak reports on both pen-based and laptop computers.
Make additional software modifications.
Test in field in two separate locations. “ Recommend additional system modifications.
Evaluate pilot project.

The leak sketching application was developed by the field GIS software vendor and was reviewed by System Monitoring management and GIS management. Several changes to the software were recommended. With the majority of the modifications complete, a decision was made to proceed to the next step of the project. Although there were still several bugs that needed to be fixed, it was in our estimation a workable prototype. We were then able to begin training one of the field technicians to test the system for usability and functionality. At that point, several additional modifications were suggested. Again the decision was made to complete a reasonable number of the modifications so that the pilot project could proceed on schedule.

The initial field test was conducted in the same week, in two separate operating areas, by two different technicians. One technician was vaguely familiar with computers. The other technician had never used a computer before. One location used primarily a pen-based computer, and the other a laptop with both a mouse and trac-ball. Initial test results were good, but still several changes were suggested by the field technicians. Some additional software changes were then made, followed by a second field test in one of the locations, using primarily a laptop computer. Additional recommendations for software changes were noted, and discussed with the field GIS software vendor.

Project Findings and Results

GIS Data Accuracy
For the most part, the landbase maps used to create the electronic maps were obtained from the cities served by LSG. Depending on the accuracy and currentness of their landbases, actual lot locations and boundaries may not be reflected in the field. In addition, the addressing that is the official record of the town or city may or may not reflect what is actually used for house numbers or curb address markers. This is especially true of small towns. LSG serves over 400 towns of 5,000 population or less. The digitized gas facilities may not be shown on the electronic map in the right location. For example, a service line may be shown on the left side of the lot on the map, when in the field it is actually on the right side of the lot. This is a problem when a concerned technician is familiar with sketching a schematic of the leak that represents the reality of what is in the field versus what the map shows. The technicians’ 288.performance is evaluated in part on how accurately they pin-point a leak on a given gas main or service line, and how well they communicate that information to the repair crews. The desire to have an accurate picture of what is in the field implies the need to have a redline markup, or field verification feature to go hand-in-hand with the leak survey application. The millions of dollars spent on conversion could be seen as ineffective if the technicians feel they are forced to use incorrect map information.

Map Navigation
Viewing a drawing on the screen does not give the same overall view as that of a paper map. As a result, when zoomed-in to legibly read the text on the screen, labels for street names may not appear at that scale. This implies the need to dynamically label the streets when zoomed in on the screen. This could be accomplished by using intelligent street centerlines. However, a large part of the city landbases do not have street centerlines, and would have to be added to the maps. The addition of street centerlines would also help in developing navigation tools.

Are You a Pen or a Mouse?
The procedures to draw a sketch involving a pen-based computer usually require the user to touch the screen to place a point, and then pick a tool, for example, to place a leak symbol on the map. This process is the reverse of the field technician’s inclination to want to pick the tool first, and then select the location on the screen. This can cause a dilemma in that: do you retrain the natural tendencies of the work force, or change the software.

This usability issue is the difference in saying “right at this spot (as you touch the map area), I wish to post a leak to the map (as you select an icon),” or to say “I wish to post a leak to the map (as you select an icon), right at this spot (as you touch the map area). This difference was discussed during the analysis and design stage. The natural tendency of the GM planning staff was to use the select-iconAap-screen method. But not having much familiarity with pen-based computing, we thought we might be biased toward this method. Instead, it was decided to develop the application using tap-screenhelect-icon method for most of the functions. However, in both of our independent field tests, the technicians wanted to use the select-iconhap-screen procedure.

This usability issue could add some complexity to the application development. The software will have to be written to disable and enable the natural pen functions as a starting and ending step, for using many of the features.

In the actual leak repair report in the LSLS leak survey client, the windows make use of radio buttons and scroll bar menus with pick lists. These windows are relatively easy to use, whether via pen or mouse.

Hardware
Most field applications focus on the hardware. However, with the many choices of hardware and the price-performance of computers on the decline, we were able to focus on the application functionality. We tested the application on a color 486 laptop computer using a mouse and a trac-ball, and also on a ruggedized pen-based 486 computer (monochrome).

While ruggedization is always an issue in a field application, the field GIS Leak Survey computer will be used primarily inside a vehicle. The nature of the leak survey process, with extensive walking and probing for leaks, does not lend itself to carrying an additional piece of equipment such as a computer. The field technicians currently use several electronically sensitive devices in their day-to-day work. As a result they already have an appreciation that the computer must be treated with the same respect as the other tools that they rely onto do their job.

Transition Plan
Since the pilot project covered only two work areas, and that by the end of year only 10 technicians out of 67 would have computers implemented in the field, it was decided to use the same method of returning information from the field that is currently used by the remaining technicians that were faxing-in their completed forms.

Once the technician using the field GIS Leak Survey system was through with his work for the day, he would drive to a location with telephone access, and dial-in via modem to send an electronic fax file to the central file server. By using this method, the main LSLS leak survey application did not have to be modified to accept the information. The main advantage was that the data was already validated by the client version of LSLS on the field computer.

Proiect Goals
The goal of the project software was to save the field technicians time by automating their reporting activities for leak surveys. The two technicians involved in the pilot were very receptive to being placed in a rapid application development environment and worked around occasional problems with the system. Both quickly recognized the benefits of using the sofhvare in the field and acknowledged that the system would save them time as well as produce more accurate reporting.

Conclusions
The pilot project met the main objective of developing an application that would reduce the time spent on sketching and reporting leaks. Several factors contributed to the success of the pilot project:

The commitment of the pilot project team members--LSG staff, GIS soflvvarevendor, and field technicians--to meet the project schedule in spite of “things not always going as planned.”
Strong management support of the overall AMIFM GIS project at Lone Star Gas.
Keeping the scope of pilot project small, and completing the project in a short period of time.
Focusing on the application development, and not the hardware.
Progressively moving forward with subsequent stages of the testing with only the base functionality of the application, even though all of the bugs were not worked out.
Keeping the features of the application to a necessary level, without the bells and whistles.
Picking the “right people” to test the application in the field, who were willing to work through the testing-of an imperfect application.

Future Plans
Based on the results of the pilot, Lone Star Gas plans to implement 10 computers with the field GIS Leak Survey application by the end of 1996. Computers and software for the remaining 57 field technicians are planned to be implemented by the end of 1997. Also in 1997, pilot projects are envisioned for field GIS applications to support additional code compliance inspections such as: regulator and relief valves, odorant test points, emergency valve inspections, patrol zones, and cathodic protection surveys.