A web-based spatial viewer for operations resource management
Our spatial data option uses a set of PL/SQL scripts to add columns to one of the OMS
database tables, as well as creating a new table. For our DIAGRAM_OBJECTS table,
which contains all of the objects in the utility’s data model, we added a SHAPE column
containing an aggregation of the point coordinates of the object, a SHAPE_TYPE column
to indicate how to draw the object, and a NUM_POINTS column to indicate the number
of anchor points. Typically this is done after an initial model build to calculate values for
all existing rows in the table. The scripts also add a trigger such that when new rows are
added or existing rows are changed or deleted during an incremental model build, the
appropriate values for these new columns are calculated for each new row.
The scripts create various database views by joining data in other database tables of our
schema with the spatially enabled data in the DIAGRAM_OBJECTS table. For example,
to see outage information in the spatial viewer, a SPATIAL_OUTAGES view is created
by joining the OUTAGES and DIAGRAM_OBJECTS tables. The same is done for all
dynamic data such as notes, tags, crews, and so forth. Similarly, for data such as roads
that can be fetched without requiring any joins, database views are defined to pull in
objects with the proper object types from the DIAGRAM_OBJECTS table. This way, all
the viewable data in the system is partitioned into named layers. All the viewing happens
by bringing in specific layers for requested partitions.
The scripts also create a SPATIAL_LAYERS table that includes information such as
which layers of information are displayed by default, which contain selectable objects,
the zoom range within which they are displayed, the color to be used, the draw order, and
other parameters. With the SPATIAL_LAYERS table, the large amount of data in the
DIAGRAM_OBJECTS table can be partitioned into logical layers, the visibility of which
can then be individually determined.
Background data such as water bodies and subdivisions, also referred to as landbase, is
handled differently due to its very large data volume. Rather than being stored in the
DIAGRAM_OBJECTS table, it resides in background map files that are based on the
DXF format. To see the background within the spatial viewer, these DXF files are pulled
from the OMS onto the Web Gateway server and parsed with a Java DXF parser. This
parsed data is cached by partition on the Web Gateway server, just like the data from the
DIAGRAM_OBJECTS table. This data can then be fetched by the client viewer and
displayed along with the data from the DIAGRAM_OBJECTS, if the user wants to see
the background as well. Since this background data comes from a DXF file instead of a
database table or view, it is not further divisible into layers. If the user displays the
background data layer, all the background will be visible.
Achieving Scalability Through Caching and Efficient Updates
The use of an EJB container such as Voyager gave us the ability to cache information
such that a large number of users could be supported. If dozens of users were each
directly querying the database for map partitions, the performance impact on the database
could be prohibitive. However, map partitions are cached in a viewer EJB, so that only
the first request for a given partition requires a database access. Subsequent requests for
the map partition, either by the same user as they navigate away and back to the area, or
by another user, will only need to go as far as Voyager’s EJB container.
Another way in which scalability is achieved is through the use of a Publisher used with
the CORBA gateway that allows the viewer to subscribe to messages that provide
updates to the cached information. A set of associations is maintained between message
types and layers such that when a message is received that a certain type of update has
occurred, only the associated layers for the affected partition(s) are uncached.
Viewer Functionality
Figure 2 - Web-based Viewer
The viewer is interactive and supports several functions in addition to data display. A set
of “pan bars” around the border of the viewer display area allow panning up, down, left,
right, or along any diagonal. The text boxes on the lower right indicate the current object
selection in the viewer (left text box) and a selection in an associated tool (right text box).
Web-based tools integrated with the viewer include a work agenda of outages and nonoutage
events, crew management tools, and customer and call information.
The toolbar, which is shown along the right side of the viewer but may be repositioned to
any border of the window or left floating in its own window, offers several functions.
The top two buttons toggle the viewer selection mode between the Control Tool and the
Trace Tool. When in Control Tool mode and a device is selected, a popup window opens
that supports the opening and closing of devices, adding notes or “Do Not Operate” tags
to devices, moving outage predictions upstream / downstream, and bringing up device
attributes. Examples of a Tag icon (white T inside a filled box) and a Note icon can be
seen on a device in the lower center of the viewer. Outage type indicators (RO, PSO) can
be seen on several devices, and rings indicate devices in an abnormal state (e.g., open
when normally closed). A crew truck icon can also be seen near a device to the right of
center. Each type of icon resides in a separate layer and thus supports efficient updates as
described in the previous section.
When in Trace Tool mode and a device is selected, the viewer opens a popup window
allowing the user to select the type of trace to be performed: To Source, To Switch, To
Transformer, or to All Connected devices.
The “file cabinet” button brings up a search popup dialog, where for example a device
name (or partial name) can be entered. If a partial name is entered, all matching device
names will be displayed for selection.
The “H/D” button allows turning on or off the display of graphical layers such as
electrical components, landbase data, text, etc. The next two buttons are Back and
Forward arrow buttons that function similar to such buttons on a web browser.
Whenever the displayed view area is changed as a result of panning, zooming, or
focusing on another device location, the previous view is cached up to a configurable
number (typically 12). The Back button can then be used to “un-zoom”, “un-pan”, or
otherwise undo a view change, just like navigating through web pages.
Next down on the toolbar is a “refresh” button that does an on-demand update of the
displayed viewer information. Use of this button is needed to see updates associated with
electrical network changes.
