Logical Approach to the Integration of GIS/WMS/CIS
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.
