GISdevelopment.net ---> GITA 2001 ---> How They Did It - And What's Next

Inventing a GIS

Neal Myers
Central Lincoln PUD
P.O. Box 1126
Newport, OR 97365


Introduction
The implementation of a large GIS project differs from a standardized procurement process such as purchasing a new line truck. While there are many options and configurations available for a line truck those responsible for it's purchase and operation are very familiar with the resulting functionality and cost to value ratio. The functionality, cost and even the methods to most effectively use a GIS are often vague and can be confused further by conflicting assertions and the positive or negative experiences of other users. Mindful of these issues, Central Lincoln began to explore the possibility of creating this system to most effectively serve our customers.

Background
Central Lincoln People's Utility District is an electric distribution utility with approximately 34,000 customers on the central Oregon coast. The district is organized as three operational divisions covering an area of 630 square miles with a load density of 26.7 customers per wire mile and annual demand of 275 MW.

Motivation
At the onset of this project in 1990 most records for engineering, warehousing, accounting and other functions performed by Central Lincoln were stored on paper forms. These paper files were augmented with some enterprise and several isolated computerized databases. The business rules which originally directed the construction process were based on a highly formalized, labor intensive and de-centralized system that generated at least fifteen separate forms which were then distributed to at least eight departments. From 1970 to 1990 the number of customers served by the District increased from 14,000 to 27,000. During the same period the Engineering staff levels remained static. As the increasing volume of construction projects began to overwhelm available resources, requirements were relaxed. Forms which had been highly standardized became ad hoc and reflected the requirements of local operating areas. The lack of standardized construction specifications and practices throughout the district led to warehousing issues and variable project estimates which was compounded when the accounting close used different criteria than those used for engineering estimates, to determine costs.

In order to mitigate this situation an examination of work flow and data used or created during the construction process was conducted. Advances in software, middleware, hardware and advantageous price to performance ratios for this equipment were also studied. The conclusion drawn from this process was that a digital data automation system should be considered.

The primary goals for the proposed system would be to eliminate redundant data entry; to standardize construction specifications; and to enhance data retrieval by integrating isolated databases. These goals would translate to customer benefits of; 1. reduced operating costs through increased efficiency of personnel at each data transaction and reduced inventory through the use of construction standards; 2. more effective system cost recovery through a more accurate reflection of resource costs and by timely update of accounting and other databases; 3. enhanced customer satisfaction through accurate, timely and centralized information with which to address customer inquires; 4. the ability to leverage investments in legacy systems by integrating these systems with new components and; 5. more effective use of company resources by allowing engineering analysis to be run against a valid system model.

Execution
The basic components necessary to accomplish these goals were:
  • "a geographic database (map library) that could model the electric system
  • "an application to facilitate the design process and to update the map library and the site inventory databases
  • "computer hardware
  • "software such as relational databases and middleware to connect the components together.
The geographic database would reflect existing paper electric system maps of which four distinct types were maintained:
  • "inventory maps which depicted a large amount of detail for a relatively small area of the system and included an inventory list for each site
  • "operating maps which covered larger areas and included information on disconnects and fuses
  • "phasing maps which again covered large areas and included information on the physical configuration of overhead conductors and the connected phase and size of transformers and
  • "tagging maps which showed the relationship between underground facilities. All information except tagging would be incorporated into the map database.1
The design application would be required to:
  • "add and remove design elements from a job
  • "access corporate site inventory data
  • "create work sketches and parts lists to support the construction process
  • "maintain the necessary relationships, such as connectivity, in the electrical model
  • "post design changes to map, inventory and related databases
The major requirements for computer hardware and related software would be cost effectiveness and support for the first two components. Likewise the environment into which the map library would be captured would be determined by the design application chosen. Therefore specifications and an RFP for the design application were produced as the first step in the process.

Proposals were evaluated and a pilot project was initiated in which a small portion of the electrical system was converted and a design application created. This system, however, did not fully meet some requirements and was completely unable to interact with legacy systems. Further evaluation led to a second pilot project by Miner & Miner Consulting Engineers of Greeley CO. Miner & Miner produced a database design, supporting applications based on ESRI's Arcinfo AML (Arc Macro Language) and better connectivity to IBM AS/400 legacy data. The second pilot project sufficiently demonstrated the feasibility of the basic concepts of the system and was approved for further development.

With a stable database design from the design application conversion specifications were drafted and a conversion vendor, Cartotech Inc. of San Antonio TX.2, selected. The first step in the conversion process was the creation of a base map comprised of PLS section corners captured from the USGS 7½ minute quad map series. The next step in the creation of the base map was to rubber sheet assessor's parcel maps into this framework. Because mapping conventions varied over the District's four county service area and because "local knowledge" helped in the interpretation of the source maps, district personnel performed a clarification process or "scrubbing" prior to providing the source material to the conversion vendor.

The District's electric inventory, operations and phasing maps were also scrubbed before delivery to the conversion vendor. Data from the various system maps was to be captured into a single map layer and delivered in native format i.e. ArcInfo coverages. A quality assurance process was then performed on small areas as they were delivered. Corrections were made where warranted and the vast majority of converted data has been used without further adjustment.

Central Lincoln did however suffer occasional "stubbed toes" in the conversion Q/A process. This was primarily the result of viewing the delivered products as maps rather than as map data. A map which is created from the map data in a GIS is essentially a report generated from information in a database. The "reports" generated for the Q/A process were designed more to reflect of the characteristics of the paper maps with which users were familiar than to take advantage of the characteristics of a digital system. As an example digital data could have easily been overlaid with more accurate control or displayed as a seamless data set to examine feature attributes. Both these types of examination could have helped to either validate or point out inconsistencies in the data. Tabular data could also have been programmatically tested, which is both quicker and more accurate than visual inspection, to confirm the logic of feature attributes e.g. are three phase features being "fed" by two phase features.

The design application (Miner & Miner's JPDE), which would become the primary user interface with map data, was being developed concurrently with the data conversion process. JPDE was originally developed as a water distribution application and implemented the basic concepts and functionality upon which to build an electric application. Much of the development of the application was therefore an integration process to incorporate Central Lincoln's database design, mapping conventions and work model. Figure 1. outlines the basic functionally provided by the design application.


Fig 1.

Infrastructure
One of the intrinsic qualities of a digital database is that data can be stored centrally and accessed by any user that can connect to it. This section will examine the three components network, hardware and databases necessary to connect to remote data.

Original GIS clients used a UNIX (IBM AIX) desktop workstation with a 10Mbit LAN connection to UNIX servers where GIS data was stored. The initial WAN connection between offices of 9.6K baud was increased to 72K baud (v.32) at the beginning of the project but was still inadequate to support GIS data transfers between Central Lincoln's three operational offices. GIS data was therefore created and maintained at each office while a high speed broadband communications network was designed and implemented. This system, based on a Harris-Farinon digital microwave, AT&T fiber terminal equipment and SONET technology, first raised speeds to DS1 or 1.55Mbits and is currently using ATM to provide OC3 or 155Mbit transfer rates.

The current network capacity enables the use of a centralized application and data servers with all the inherent advantages for management and security. This change has also allowed the UNIX desktop to be replaced with a standard NT solution using X emulation software. NT workstations are economical and provide access to a wide variety of office and personal productivity applications. It is difficult to quantify the magnitude by which computing power has increased, as not only has the computing model changed from local computing to client/server but the units of computing power have changed as well. As an approximation the first change from desktop to first generation server increased computing power approximately ten times and the second (current) generation server increased that by six times.

The primary data resources used by Central Lincoln in the engineering process are contained in four databases on three major platforms and are outlined in the following table.

Table 1.
Information Platform Database Connection Comments
XFR table UNIX INFO Native INFO is the native ArcInfo database. This datawill be moved to Oracle for wider availability.
SWITCH table UNIX Oracle ArcInfo DBI Database Integrator
PARCEL records UNIX Oracle ArcInfo DB  
RESERVED UNIX Oracle ArcInfo DB Pole Number Master
Site Inventory tables AS/400 DB2 DBI/Oracle Gateway Site Inventory information
JOS AS/400 DB2 DBI/Oracle Gateway Job Order System
CIS AS/400 DB2 DBI/Oracle Gateway Customer Information System
Costing tables AS/400 DB2 DBI/Oracle Gateway Part of J.D.Edwards costing data
SPEC "Build Table" NT Access Replicate to AS/400 Details stock items which comprise upper level SPEC's
SWITCH table NT Access ODBC to Oracle Access front end for non-GIS users
OUTAGE NT Access ODBC to Oracle Links Outage database to GIS

During the design process data is created, updated and referenced. For example a simple work project may reference data about pending work (JOS), energy usage (CIS), switches, parcel records and site inventory, create data for new facilities (SITE INVENTORY) and a new service location (CIS) and update data about transformers (XFR). During the design process connections to remote databases are made with middleware applications (ArcInfo's Data Base Integrator for Oracle and Oracle's Transparent Gateway for AS/400). Queries are passed using SQL and the results returned as views or with cursors. These data connections and SQL also allow record update and creation. The data sets are also referenced and updated outside the design process. PC and AS/400 applications provide the user interface to the data and connections to the data are established via ODBC and ASNA3 gateway.

People
Data does not have intrinsic value; it only has value for the benefits it provides to the users. The people who derive the most value from the data upon which this project focuses are those involved in the design process, the engineers and those who benefit from the design process, the customers. One of the business reasons that drove this project was to increase the efficiency of the people involved in the work process. In a successful project this increase in efficiency allows users to accomplish more using fewer resources saving the customers both time and money.

In this project the enhancement in efficiency stems from the way that data automation affects the work flow model. The vision for data capture (input) for the automated model required data to be captured only once and to be captured as close as possible to its source. In this model data integrity is maximized by taking advantage of more complete knowledge of the data to be entered and minimizing transcription points. Minimizing transcription points also increases efficiency by reducing data "touches" during the work process.

The resultant work model was thus compressed causing shifts in areas of responsibility. These shifts in responsibility required users to learn to do their job in new ways and possibly, to be responsible to do more. In order for the project to succeed it was important to impart the vision and goals of the project to those who would be most affected by these changes in the work model. The users had to feel empowered by changes and assume ownership of the project. To ensure this took place the users took part in the conceptual and planning phases of the project and were made to realize the importance of their input. Obviously the end users could not shape the entire project but could contribute in areas where they interfaced with the data; for example the way graphic features would be symbolized and the work flow in the design application.

Another requirement for a feeling of empowerment by the users was that they feel comfortable with new applications and work models so an aggressive training and support system was maintained. Also "champions" of the system were groomed at each site where the application was to be used to provide "hands on" guidance to the users.

Fruition
The goals of the Central Lincoln project were (and are) to integrate data and streamline workflow. To support these goals applications have been designed which use data that can be universally accessed via the infrastructure described earlier. Table two charts the major enterprise applications currently in use.

Table. 2
Application Platform Database Connection Comments
JPDE/PLOT UNIX(AML) INFO Native Design/Work Sketch environment
    Oracle DBI/Oracle Gateway Query, Update and Create Oracle and AS/400 data
Ad Hoc Map UNIX(AML) All   Mapping outside the design environment
Special Apps UNIX(AML) All   Reports based on geographic and enterprise data
CRS/JOS AS/400(RPG) DB2 Native Customer Information/Track work status
SITE INVENTORY AS/400(RPG) DB2 Native Display/Update site inventory
JD Edwards AS/400(RPG) DB2 Native Accounting package, provides costing/stock data
CIS/Billing NT(ASNA) DB2 ASNA Gateway Customer Information System/Billing
CPR NT(Access) Access Replicate Uses data from design process to update CPR
Map Viewers NT(VB/MO) Access Replicate Enterprise access to geographic data
Spec Tools NT(ACAD) Access Replicate Design Compatible Units, maintain "build table"

As we have seen during the life span of a job data will be entered, referenced and created. Previously this data was viewed or accumulated on paper forms, now the applications that are used during the work process use virtual forms.

The first step in the work process is the initial contact with the customer, information is entered into the CRS/JOS (Customer Request System/Job Order System). The information collected includes information about the job, customer, work to be done, status, routing and billing. The primary CRS/JOS user interface is an AS/400 character based (green screen) application. The information gathered by the CRS/JOS application is referenced by the design application to begin a project for which engineering is required. Job status and routing are updated as the job moves through the system and if a new service is created that information is updated in the CRS/JOS tables by the design application.

An AOI (Area of Interest) is created to begin the design process using the design application JPDE (Job Planning and Design Environment). A valid entry in the CRS/JOS is required when creating a job in the design environment. The electrical features within the AOI are copied to a private workspace and locked against modification by other jobs. A view of active AOI's is available to help designers coordinate work. Information about plant in service, customer billing for load studies, assessor's records and other information can be referenced from within the design application.

CU's (Compatible Units) are added to or removed from a work sketch from a list of valid candidates. Compatible Units are designed using CAD software and an MS Access database. Information about individual CU's includes an entry in a "build table" which lists the stock items that comprise the CU. Costs associated with individual CU's are determined from the stock items that make up the CU and which are maintained by accounting department software. Labor costs for CU's are currently being compiled. The use of CU's standardizes construction practices, job estimates and accounting costs and allows generation of job estimates, work lists (CU's by site for a job) and pick lists (stock items required for the CU's).

The design application uses information about CU's and current design environment settings to determine the symbology and attributes for features added to the work sketch. CU's in a job can be associated with different job orders and thus can be listed, plotted or posted separately. Topology, such as connectivity, necessary in the electrical model is also maintained by the design application.

When creating a new service location in the design process a record is created in the billing system and information such as a detailed location for the service are updated by the design application. This functionality allows a high degree of integration between the design and billing system and allows information about the service location to be entered at the most appropriate point in the work cycle.

At job posting time the base GIS and site inventory records are updated and a copy of the work done is created for use in the accounting close.

Several applications have been created to augment the design environment or to provide other functionality. An ad hoc mapping application is a natural extension to a GIS and performs a variety tasks for the organization. The district is taxed on the basis of conductor within taxing districts, the GIS is used to produce the required annual reports by selecting and totaling conductor based on type and number of phases within the geographic area of individual taxing district. Requests to provide plant value or revenues within a given geographic area are easily satisfied by linking GIS features with corporate CPR or billing records. Recently a stand alone PC based viewing application has been deployed and used to provide wider access to GIS data within the organization. A viewer was also integrated with the CIS to allow a user to select a service with tools provided in the CIS application and to use the viewing application to navigate to the geographic area of the service.

Future
The direction that Central Lincoln's GIS project will take in the future will, as always, be determined by the best interests of our customers. As we have seen the goals of this project were realized by centralizing and standardizing data. This has enhanced efficiency, reduced costs and increased customer satisfaction.

Central Lincoln will look in the future to further integrate and extend the components of the work process by linking functionality between applications and adding desirable functionality with other applications. Creating, and maintaining several computing engines to perform the same function is usually inefficient. Applications built on COM (Common Object Model) can share functionality and facilitate extensions or changes to functionality.

Functionality can be gained by implementing (and integrating) new applications, e.g. OMS (Outage Management), WMS (Work Management), MMS (Material Management), SCADA and engineering analysis applications.

New capabilities in the form of the geodatabase can open GIS data to enterprise applications and allow advanced modeling of utility related GIS features. These advances may allow users to "invent" further uses for GIS data and functionality that are as yet unconceived and blur the line between GIS data and applications and other enterprise data applications.

Mobile and web based computing could be used to provide GIS and other enterprise data to field personnel.

Whatever course the project takes in the future, decisions will be made from the vantage achieved by creating a solid foundation and taking a practical and creative approach to the challenges presented from the beginning of the project.

--------------------------------------------------
1. Tagging information, in the form of an image, is available to GIS users but that data, unlike data about the rest of the electrical system, is not maintained as part of the design process.
2. Cartotech is now a division of Analytical Surveys, Inc.
3 ASNA is a COM based application development environment for use with AS/400 data
© GISdevelopment.net. All rights reserved.