Bluegrass GIS, Inc. has assisted Nashville Electric Service (NES), one
of the ten largest public electric utilities in the United States,
with its migration from workstation ArcInfo 7.2.1 and ArcStorm to
ArcGIS and an enterprise geodatabase housed in Oracle. This paper
provides an account of the ArcGIS migration process at NES with lessons
learned. Topics addressed include geodatabase design; UML modeling;
custom maintenance application development using Visual Basic; feature
linked annotation creation and editing; and integration of the NES geodatabase
with ABB's CADOPS outage management system (OMS).
Nashville Electric Service(NES) undertook its original GIS implementation in 1995 with the purchase of ArcInfo and Digital UNIX workstation and Oracle for the relational database. Existing primary distribution drawings in AutoCAD format were converted into ArcInfo coverages and initially stored as map libraries and ultimately in an ArcStorm database.
NES also selected ABB's CADOPS Outage Management System (OMS) for managing electrical outages. One of the key goals of the GIS was to provide accurate data for the OMS system. A Database Maintenance Application (DMA) was developed by Bluegrass GIS with customization through the Arc Macro Language (AML) so that the data could be maintained in a user-friendly, cost efficient manner.
In 1998 - 1999, Bluegrass GIS conducted a study to assess NES's GIS implementation
to date and developed a Strategic Plan for implementing an enterprise
GIS. From that study, the GIS hardware and network were upgraded
initially and a new enterprise ArcGIS system was planned and developed
with ArcSDE and an Oracle RDBMS as its core. ArcIMS was implemented
on NES's Intranet to give access to the GIS data to a much broader user
base within the company. A new Geodatabase Maintenance Application
(GMA) was developed and implemented by Bluegrass GIS. The custom maintenance
application has ArcMap 8 as its core with customization using ArcObjects,
Visual Basic, and Visual C++. This new enterprise system went into
production in March 2002.
Interviews were conducted with all relevant departments to determine data and application requirements and the modifications to the existing database design needed to accommodate their needs and requirements. Using the existing GIS database design as a starting point, the geodatabase design was modeled in diagrams using the Unified Modeling Language (UML) in Visio 2000 Enterprise. Esri's wizards were used to create the database schema from the UML diagrams. Loading of the database Feature Classes and database preparation was time intensive and required several steps to complete. These steps included: conversion of the ArcStorm data into Coverages that were formatted according to the new database schema, import of these coverages into the Geodatabase Schema using ArcCatalog, creation of the Feature-linked Annotation Feature Classes through custom code, Feature-linked Annotation Feature Class loading through custom code, creation of the Geometric Network, reapplying the schema for connectivity rules, creation of indexes and creation of composite relationship classes.
To take advantage of the new environment, the following were implemented in the Geodatabase:
1) Subtypes were used instructuring the data and resulted in fewer geodatabase feature classes through consolidation of existing GIS data layers. For instance, three separate voltage distribution line layers were combined into a single distribution line feature class with subtypes. Feature classes were primarily divided into subtypes by voltage and if it was overhead or underground. Protection devices (blades and fuses) and switches were further subtyped by device types.
2) Extensive use of domains was used for valid values which helped greatly for validation and coding of the GMA application.
3) Default values by subtype were used whenever possible to ensure attribute integrity was maintained in the database when new features are added.
4) All attributes needed for generating the feature-linked annotation were incorporated into the design. This included a Boolean Flag field in feature classes where only some of the features have annotation. Phasing annotation for distribution line features is an example.
The database design was an iterative process in which the UML modeling allowed us to make changes fairly quickly. Because of the large database, it would take a considerable amount of time to generate a new database. Another advantage of developing the UML model of the database schema is that we could generate either an Oracle SDE geodatabase or an Access personal geodatabase as we desired. Even though the final implementation was in ArcSDE, the personal geodatabase with a test set of data allowed staff to develop and test the GMA application without having to be connected to an ArcSDE database.
One key element missing from Esri's UML modeling capabilities for the
Geodatabase is that there is not a way to model the annotation, which
was extensive in this project. This meant that each time the database
was created, the annotation feature classes would have to be separately
created. Since there were originally over fifty annotation feature
classes, a custom tool was built to speed the creation of those feature
classes. A feature of this tool was that all the properties needed
for creating the annotation class was held in an Access table for easy editing
of the properties. The tool read the table during the creation process.
The large number of annotation feature classes was later pared down
by half by combining some of them and by adding an attribute field into the
annotation feature class to differentiate them.
Originally, the geodatabase design called for all electric features to participate in a geometric network. After testing the model, we discovered that when multiple point features are located at the same x,y coordinate, only one of the features participates in the network as the junction and all other coincident point features can not participate in the Geometric Network. Coincident point features were a common occurrence throughout the existing NES database, and offsetting thousands of point features to eliminate coincident point features was an unacceptable solution to this problem.
Additionally, it was important for supporting the CADOPS data model and for the editing process that we find a solution to this problem. CADOPS uses a data model consisting of lines and nodes much like the ArcInfo linear coverages. However, line features in a geodatabase lack from and to node attributes (i.e. arc-node topology). Our solution was to create a Node point feature class at all the endpoints of the Distribution and SubBus features (comparable to nodes within an ArcInfo line coverage). Relationship classes were created to link the Node features to the other devices and poles using a common Node ID attribute (Figure 1). CADOPS requires that a device such as a switch be linked to a line feature and a node feature at one of the endpoints of the line through unique database-wide ID values. This model enabled us to maintain that relationship. Also, while editing, when a node is deleted or moved, the related devices are also deleted or moved as was desired through the network.
An application was created to provide the NES GIS database technicians with an editing interface that was intuitive, efficient, easy to use, and enforced certain connectivity requirements for CADOPS. One such rule was if a user adds a switch, then it must be linked to a node point feature present within the geodatabase or the add process will be terminated and the edits rolled back to their original state. By enforcing this rule at the editing stage, problems are eliminated when loading data into the CADOPS system.
One unique feature of the application is tools that encapsulate other tools into a single tool. This allows the user to begin adding a transformer bank, once it is placed the tool “morphs” into a different tool that prompts them to link it to a node, a different tool to link it to a pole, a rotate tool to rotate the transformer bank, and then it finally opens an attribute form to fill in any values needed. This greatly speeds up the process of adding or moving features.
Features are symbolized with different colors for different voltages
and service status. Until a feature and its associated annotation
have been field verified, they are assigned a unique color. We
used the group symbol attributes in the annotation feature classes to
store the different types of text symbols used in the annotation. This
allows it to be changed at a later date and allowed us to standardize
coding of symbology changes. When the user changes the service status
of a feature, code triggers the change in the text symbol id of the related
annotation.
Most information needed for CADOPS is stored directly in the GIS database.
Some CADOPS values are derived from information housed within
the NES geodatabase via Oracle procedures during the data load from
the GIS tables to the CADOPS tables. This is done nightly so that
the latest data is available for use in the CADOPS system. Previously,
significant post-processing was required following the transfer of data
from the GIS to CADOPS due to incompatibilities between the GIS and
CADOPS data models. Where possible, the process of transferring
data from the NES geodatabase to CADOPS was streamlined incorporating
information required by CADOPS into the NES geodatabase design or was
automated within Oracle procedures which convert the NES geodatabase features
into their appropriate CADOPS Oracle tables.
The versioning setup has a Default version and a Master Edit version that is derived from the Default version. Each edit user has a version for editing that is derived from the Master Edit version. This design allows for protection of the default version in case something goes wrong in updating the database and allows for control over the end user edit environment for the reconcile and post process.
Esri's ArcIMS technology was implemented at Nashville Electric Service
on the corporate intranet. The ArcIMS site provides NES staff access
to distribution facility data, substation one-line detail data, and
basemap data. The intranet site accesses an ArcGIS geodatabase
that models NES's real world electric features. Customization using
ArcXML (AXL) was implemented to present the end-user with the correct
symbology for features by utilizing a custom font, appropriate zoom
in and zoom out display thresholds, and display by Feature Class Subtype.
With the new ArcGIS system in place, NES is now poised to use it across
their enterprise. The old system was not easily accessible to other
areas within the company. There are plans to implement mobile
GIS applications for use in the field, integrate GIS with a new Work
Order Management System currently under development, and integrate GIS
into the Engineering design process. Several departmental applications
include Pole Attachment tracking, Fiber Optic management, Tree Trimming
Maintenance and Street Light Maintenance.
Implementing the ArcGIS system with the custom application allows NES's staff to concentrate on the maintenance of the data rather than spending time and resources on keeping the CADOPS data intact. It has also allowed for faster updating of the CADOPS system so that it always has the most current information, critical for any Outage Management System. In addition, the use of ArcIMS directly linked to the ArcSDE database eliminates redundant data sets dispersed throughout the organization and allows the end user to have access to the most current data.