Logical Approach to the Integration of GIS/WMS/CIS

Logical Approach to the Integration of GIS/WMS/CIS

Jay Stinson
Intergraph Corporation
Huntsville, Alabama 35894
Phone: 256-730-8726
Fax: 256-730-8225
Email: djstinso@ingr.com

Introduction
The first step in integrating GIS and WMS is determining the major interface points between the two applications. These interface points can be defined as:

Job management.
Construction unit (CU) integration.
Data exchange integration.
Life cycle management.

The following high-level diagram illustrates the GISAVMS workflow, including where these applications integrate.

The real issue is how to model the database to assure seamless workflow without compromising the independence of the individual products. The following diagram depicts a typical system configuration with a high-level data model showing the location in which the major pieces of data will be maintained and stored.

Job Management
Job management involves the job-related communication between WMS and GIS, including information such as job name, address, designer name, et cetera. Job data is captured in WMS initially, and a subset of data is passed to GIS. The following workflow diagram illustrates this process.

Compatible Unit (CU) Integration
Compatible unit codes are the means by which work management systems determine the cost of performing a job. The user creates and maintains the list of valid CUS and their key attributes within the WMS environment. GIS then accesses the CU tables in the WMS database and displays the CUS that are available for the user to place with a facility item. The following diagram illustrates the CU interface.

As part of this integration, GIS must be able to support multiple CU types. Most WMS systems support the following CUs:

Primary: Primary CUS represent the plant items (such as poles, transformers, or conductors) in the field. The quantity number for a primary CU must be one.
Secondary (or Ancillary): Secondary CUS are cost items that are part of the permanent GIS model. The quantity number for ancillary CUS can be modified.
Macro: Macro CUS, which will contain only one primary CU, can contain additional ancillary Cus.

A primary CU typically has "key attributes" associated with the item. An example of key attributes might be pole height and class. When a GIS user selects a CU to place, the GIS software populates the height and class attributes automatically, reducing the amount of user-entered information and improving data quality.

Data Exchange Integration
After the work request has been designed, GIS transfers a list of the appropriate CUS to WMS. To accomplish this transfer, GIS and WMS access a set of shared Oracle tables on the WMS server, as illustrated below.

Life Cycle Management
A work request will change states several times during its life cycle. WMS manages these transitions and initiates the appropriate GIS batch transactions to ensure that the GIS model matches that of WMS. The following diagram illustrates the work request life cycle.

Life Cycle Management

The life cycle operates as follows:

Initiate Work (WMS): WMS creates and captures the appropriate job information, generating a record in the External WR Details table that is then written to the GIS Job Management table. The work request status is New.
Design (Interactive GIS): The user designs the work request in GIS. All features added or marked for removal or abandonment exist in a proposed state (PPA, PPR, or PPX).
Approve Work Request (WMS). WMS approves the work request.
Write to External WR Details (WMS). After the work request is approved, WMS inserts a record into the External WR Details database table.
Read from External WR Details (GIS). GIS reads the WMS External WR Details database table and inserts a record into the Life Cycle Management database table.
Schedule Work Request (WMS). WMS schedules the work request.
Write to External WR Details (WMS). After the work request has been scheduled with a crew, WMS inserts a record into the External WR Details database table.
FSA Cancel (Batch GIS). If the work request is cancelled, WMS initiates a batch function in GIS to cancel the work request. The user must cancel the work request prior to posting it to the master model. If the work request has been posted, the user must manually remove the changes introduced by the work request and close the job through normal procedures. The user must also remove the polygon representing the job location at which work is being proposed.
Post Job (Batch GIS). After the work request has been approved and scheduled, WMS initiates a batch job in GIS to post the features to the master model.
Allow Select As-Built Changes (Interactive GIS). Certain features are selected to be transitioned into the In-Service state and posted to the master. The user enters the workset in the As-Built mode and is provided with menu options for performing state transitions and posting. This functionality should be limited to qualifying work requests or features only.
Perform As-Built Changes (Interactive GIS). As-built changes made during the project's construction phase must be reflected in the GIS model. The system provides the GIS user with all of the design phase placement and edit routines.
In-Service/Field Completion (WMS). WMS sets the state to In-Service, initiating a GIS batch job that: - Performs state transitions on proposed features, changing them to the In-Service state.
- Sets the INSTALLED_DATE for the above features.
- Posts to the master model.
Non-GIS Job Types (WMS). Certain non-GIS job types will require a GIS as-built design to accommodate CUS with associated facilities.
Close (WMS). WMS closes the work request, initiating a GIS batch job that performs closing activities.
Close Jobs in GIS (Batch GIS). The Close Jobs in GIS batch function closes the job.

Conclusion
The key to building integrated systems that support required business processes and at the same time minimize maintenance costs is to create an architecture that offers the appropriate application separation. The approach described herein operates best when GIS and WMS are placed on separate servers so that the applications run independently. Maintaining this architecture allows upgrades to be performed without compromising other systems as new releases of software are made available.

GIS and WMS communicate through Island tables that trigger Stored Procedures in Oracle to process the data in the appropriate manner. This approach allows for system enhancements, or data structure changes, without requiring interface software changes for other systems-a key criterion for minimizing cost of ownership.