Electric Circuit Mapping with Inventory Data � Tips, Tricks, and OVERPOST Finesse

Faced with the need to use large-scale electric facility data for smaller scale schematic circuit mapping, the City of Riverside Public Utilities Department employed many unique techniques to create these critical output products. Elegant approaches to scaling, placement and page management usher several ARCPLOT commands including OVERPOST to the "next level". Peek under the hood to learn how OVERPOST really works and how to make it respect asymmetrical marker symbols. This paper addresses the issues, reveals AML fragments, and presents algorithms.

The Goal

The initial objective of the City of Riverside GIS implementation was to replace all manually maintained maps with a common base and department specific data layers to support the historical as well as enhanced map products. One of these map products is the electric circuit map. AutoCAD and manual methods maintained these maps. They were at various page sizes, orientations and map scales. The map scales ranged from 1" = 200' to 1" = 800' and the page sizes ranged from A to D. The primary reason for the different scales, page sizes and orientation was to minimize total page counts while maintaining clarity. Several inset maps clarified congested areas.

The electric department automated their facilities with a sophisticated database design using ArcInfo coverages and Oracle to support 1"=100' inventory mapping. This scale, while very clear and easy to read did not lend itself well to circuit mapping due to the number of pages required to cover each circuit. The engineering staff attempted various scales and page sizes before standardizing on one page size ("D") and map scale (1" = 200'). Even at the standard scale, inset maps are required to detail congested areas.

All of the electric data
FIG 1: All of the electric data for this area.

The final product
FIG 2: The final product.

Data Issues

We could manage most of the data relationships within the electric data model by employing creative RDBMS "views" and "native mode" SQL selects. For the uninitiated, a native mode SQL select uses a relate which connects ARCINFO to the RDBMS using the format "^relate name" with a standard where clause to create the selected set. The advantage to native mode selects is you can have very creative where clause collecting a selected set in the RDBMS and returning it to ARCINFO. In addition, the native mode queries perform the query once and return the selected set of related records instead of performing the query for each row.  Here is a good example explaining each: The expression "reselect electric point transformer//KVA = 100" performs the query for each point and checks it against each row in the Oracle table.

The expression "reselect electric point ^transformer KVA = 100" goes to Oracle and returns the selected set of records which interns selects the set of electric points. This is unbelievably fast.

 The only down side of native mode queries is the ARCINFO data must be indexed on the relate item.  This sounds obvious but when the data is edited, the index on the relate item is lost until the data is re-saved. Through trial and error, we found in most cases creative selects and processing can reduce the number of edits blowing away the index .

To optimize the circuit display requirements, we extracted the electric data from Librarian and processed it so that only the features represented in the circuit remained. When the data (designed for 1" = 100') is simply mapped at 1" = 200', the annotation becomes too small and marker symbols overstrike making the map unreadable. Several new data editing and processing steps as well as application issues resolved these problems.

Application Issues/Resolutions!

The next series of issues unravel the annotation readability and marker placement. The problems were initially addressed in three ways. 1) Rotate markers to minimize overstrike; 2) Use "Detail Boxes" to blowup congested areas; 3) Scale up the annotation text sizes; and 4) Use overpost to move annotation dynamically.

Judicious editing eliminated marker overstrikes by properly rotating the markers and creating 1" = 200� test plots to verify rotation effectiveness. Where necessary, detail or inset maps make sure that even in the most congested areas, markers will not overstrike.

Sample area with detail boxes
FIG 3: Detail boxes clarifying congested areas.

To create detail boxes for the circuit maps, we added two features to the circuit page layout coverage. The layout coverage is used to denote how the circuit is mapped from the inventory data into the circuit pages where "pages" are created covering the entire circuit. Special annotation show where other circuits connect to the other side of switches or to help in the identification of the circuit in the field.  For the detail boxes, we draw a box for the area to detail, pick the detail box map scale and then place the detail box on the map where it will not effect the display of the rest of the circuit data.  To make things even clearer, a leader line ties the detail box to the map location. The size of the detail box is calculated to precisely scale the data as selected in the detail area. The information drawn in the detail box is exactly the same as shown in the base but is scaled such that it is clear. The following is the general series of steps used to get the map extent of  detail area and the map limits and scale to plot it.

Scaling up the annotation, which looked great at the original size, caused the text to overstrike. For the transformer and conductor annotation, individual text strings denote separate attribute values. Further data editing concatenated the individual strings reducing text overstrike. Even with this editing, stacked text still over struck in some instances necessitating the use of the OVERPOST command to move annotation slightly to increase readability. The initial attempts at using OVERPOST where quite funny. The first real attempt used the TEXT FIXED NODELETE option to keep the conductor annotation in place and the TEXT MOVABLE NODELETE to allow the device and structure annotation to float. Markers where plotted first with the MARKER FIXED NODELETE option set, blocking the bit map for the other text to float around them.  Although they were not usable, these early attempts showed promise.

Scaled annotation
FIG 4: Processed data with the annotation scaled up for readability. Need to move the strings or use the OVERPOST environment.

OVERPOST gone crazy
FIG 5: OVERPOST gone crazy. The annotation is scaled but it is not concatenated into single strings.

Partially concatenated annotation
FIG 6: Concatenated the device and conductor annotation into single strings.

Using the OVERPOST command required some innovative thinking. Separate stacked text strings, that "went together" were moved individually and were separated. We had to exercise some annotation data relationships to process the data and assemble the individual parts into one "text string" so it would move as a unit. The process was to use the annotation linkage to the device, the device knowledge of its structure and the structure linkage to its annotation to tie everything together. We were getting somewhere, but it was easy to get lost trying to determine which bit of text annotated what.

Fully concatenated annotation
FIG 7: Concatenate the annotation for the devices and structures into their own block. It is ambiguous as what goes where.

At this point we really understood the fact the OVERPOST command moves points or text based on its origin. For many annotations, the original placement designed to support the display all of the electric data, caused some of the text placement to be too far away for clear identification. By using our data relationships, we moved the annotation on top of the associated electric devices or structures. The OVERPOST command would then move the string away from the new origin point, preventing overstrike with other points and text. By using the LEADERSYMBOL, LEADERTOLERANCE and LEADERS commands, we were able to clarify what went where even when it was far away.

Annotation moved to device or structure
FIG 8: Move the annotation to the device or structure for clarity.

Almost there, long leaders make it difficult to read
FIG 9: OVERPOST after moving the annotation to the device or structure. Other than long leader lines, it is clear what goes where.

We were still not happy with the results of our efforts because in most cases we had leader arrows trailing all over the place. Since we could not control the order in which the annotation was placed, we had some cases where leaders crossed over each other. After talking with Esri and through trial and error, we determined our specialized marker symbols resulted in overpost bit maps that were blocking an area much larger than the actual marker. We called this the bounding box vs. the ink on the page problem.  Because many of our markers are very large and are not centered around the midpoint of the marker block, we were caught by this trap in a big way. Fortunately we crafted a solution by plotting white boxes that closely bound each of our symbols, turned overpost off, plotted the real markers, and then turned overpost back on to plot the annotation.

Boxes tricking overpost bitmap
FIG 10: The magenta markers represent the 'hidden' markers which are used to trick the overpost bit map.

The final issue to fix was the instances where annotation was placed over line work. The overpost environment did not take into account line work in the bit map. Overcoming this was easy, we used the DENSIFYARC command with the VERTEX option to create new vertices every foot. Then we used ARCPOINT the resulting coverage to create points for all of the nodes and vertices. We simply plotted all of the points with a small white marker to set the bit map for all of the lines.

The perfect digital circuit map
FIG 11: The completed circuit data. Annotation stacked neatly and close to the markers.

Summary

Our creative approach by processing the data in a specific way, understanding the overpost limitations, and tenacity allowed the City of Riverside to re-use GIS data developed for inventory mapping at a different scale for circuit mapping. Many people at the City seeing our early attempts doubted we could ever pull it off. It was nice to prove it could be done.


Bradley Mayo
Senior Programmer Analyst, City of Riverside
Pat Hohl
Senior Electric Engineer, City of Riverside