CITY OF SEATTLE VAULT PLAN INDEX

ABSTRACT

A GIS solution to the management and research of the 32,000 plans in the City of Seattle’s Vault has been created. First, a complete database of plan information was developed, supported by a robust query system that allows searches by plan numbers, date, plan name, and other identifiers. This automated maintenance and query system is now fully operational. In the second phase, a geographic network was created to support storage of plan locations. Each plan in the database is being assigned to the correct block face. Address matching is used, in combination with the existing query system, to narrow down the plan search. The entire system is used via a set of simple menus that were created for staff and the public.

This paper and application spotlight presentation will highlight the design and functions of this system, as well as some of the organizational challenges encountered in bringing new tools to a well established function at the City.

BACKGROUND
The City of Seattle's Vault contains over 32,000 plans, a complete record of as-builts 
dating back to the  19th century.  A tour of the vault conjures up visions of Victorian 
scribes working on linen.  The handwriting on the older plans looks more like fine 
calligraphy than everyday handwriting.  The plans contain current and historical 
information on water, sewer, sidewalks, paving, lighting and other plan data.  The 
plans are used extensively by City staff and the public.  Until now, the search for plans 
was conducted using a set of paper maps containing the plan numbers. The paper 
system was extremely cumbersome, since the extent of plans overlaps in many areas.  
The system had become increasingly worse over time with the added volume of plans. 

Technicians at the Vault counter conduct research for City staff and members of the 
public.  The customers are looking for plan information that pertains to the geographic 
area in which they are working.   For example, a developer looks for the plans within 
several square blocks of a new development.  City engineers need the plans along a 
street where they are putting in a new sewer line.  A citizen wants to see the paving 
and sidewalk plans along his block.  Support technicians were having trouble finding 
the correct plans for a customer and also in knowing whether or not they had pulled all 
the relevant plans. A system was needed that would support the daily work of the 
technicians at the Vault counter.  A GIS solution was chosen because of the strong 
geographic nature of the queries.  It was determined quickly that the first piece of 
information needed to conduct plan research was "What is your address?"  

The problems with the research and management of plans in the Vault had been 
recognized over time.  Several failed attempts had been made to solve the problems 
with automation.  A partial GIS design had even been tried, in which all the plans were 
inventoried in an INFO database.  This history provided a political challenge for the 
development process in this project.  It also contributed to the success of the design 
because the design process was approached so carefully and completely.

DESIGN
Our first step in the design of the Vault Plan Index (VPI) was to clarify the goals of the 
project.  These simple goals became the foundation for designing the new system.

Effectively store and maintain information and location for all plans in the Vault.
Provide tools for City staff to maintain plan information as easily as possible.
Allow for easy, accurate, and flexible research of plans for any area in the City, 
using multiple criteria.
Reduce staff time taken in plan research.
Make VPI information available to Vault customers, including other City staff 
and the Public.

The design of the system was extremely important, since the users of the system were 
not GIS specialists and the past attempts to solve the problems had failed.  
Involvement of the technical staff in the design component was a top priority.

Our approach was an attempt to balance the complexity and volume of the Vault 
information with the need for reasonable storage, maintenance and query.  We spent time 
with the Vault staff and management in order understand what worked in the existing paper 
systems and what did not. We made use of existing City GIS resources, such as the Street 
Network Database (SND) and address matching routines, wherever possible. 

Initially, we looked at two possibilities for data storage:  Storing the plans in the GIS 
with their true extent or storing the plans by block and intersection.  We selected the 
approach that stores plans at the block level on a single, specialized coverage that is 
initially based on SND.  There were several important advantages to this approach.

Ability to use address matching to locate the plans.  Since the address ranges 
are not actual, an address can only be located to the block level. 
Guaranteed coverage - plans will not be missed for any location.
Complete research power.  The system will tie directly to the existing INFO 
file of all plans.  Research can be conducted by plan types, dates, names, as 
well as location.
Ease of use and readability.  The approach will be similar to the Sewer and 
Drainage maps graphically, making use of a reference numbering system.  
This makes the map much less cluttered.  Paper maps could also be created, if 
needed.  These maps would be much more readable than the existing VPI 
maps.
Expandability - Future technology advances could allow the system to be more 
detailed.  For example, scanned images might be added someday to allow a 
customer to browse through plans.
Speed of conversion  and ease of maintenance - this approach was much 
simpler and could be taken on by staff with little training.

Once the database design was established, the functions and  menu designs were created.  
Each component was designed to work with the day to day needs of the technical staff.  The 
staff tested each menu and made suggestions for corrections.  A high proportion of hours on 
the project was set aside for modifications, to ensure that the user needs were met.

FUNCTIONALITY
The Vault Plan Index interface provides for three main activities: data entry and 
maintenance, query, and public access.  All are completely menu driven and designed 
for the less experienced ArcInfo user.

Database Overview
The VPI database is based on the integration of several, large tabular files detailing 
construction plans and a street network georeferencing the plans.  The tables, stored in 
INFO, contain over 30,000 records of the plans stewarded by the Vault.  Information 
such as construction type, work order numbers, field book numbers, and permitting 
and building dates have been transferred from a very old and cumbersome book to the 
INFO tables.  The street network contains coding uniquely identifying each arc and 
node in the city.  These codes, or plan reference numbers, are the combination of 
section-township-range plus an integer unique within the section.  A process is 
underway to assign each of the plans the plan reference numbers associated with the 
plan extent.  Once completed, users will be able to generate a list of plans relevant to 
their needs by entering an address in addition to searching for values in the tabular 
database.

Data Entry and Maintenance
Running the VPI interface initiates the main Vault Plan Index menu.  This menu 
displays anything and everything a user might want to know about any plans in the 
Vault.  This menu also serves as the main data entry engine.  Using a series of choice 
widgets and input fields the data entry person can record information for new plans 
checked into the Vault.  Error prevention needs dictated an unusually helpful screen 
with popup lists, help text, and aggressive error checking routines.  Data entry is 
actually conducted in user workspaces, allowing multiple, simultaneous data entry 
sessions. Then, an update routine adds the new records to the master files.  An 
example of the VPI menu is seen in the next figure.



From the Vault Plan Index menu, the user has the option to associate the plan he or 
she has just entered with its geographic location.  Pressing the [Add Graphics] button 
brings up the Plan Editor interface.  The user may now window in manually or by 
entering a street address on the geographic area covered by the plan.  After selecting 
street arcs and intersections and choosing the type or types of construction involved, 
the information is posted to a cross-reference file.  This cross-reference file, containing 
only the plan number, the construction type, and the plan reference number for the arc 
or node selected, provides the capability of the database to have both a single street 
with many plans and a single plan with many streets.  The important aspect of this 
menu is that it addresses the situation where, although a plan covers many blocks, the 
construction impacts vary for different blocks.  So, for example, the user can assign 
water and sewer construction to a few streets, and paving and sidewalks to several 
others.  Once again, error checking and prevention are addressed at every point of the 
process.  This application, however, is single user and changes are immediately 
reflected in the database.

It is important to note that although the logical data entry process in terms of new 
plans may be from the VPI menu to the Plan Editor, this is in no way the rule.  The 
Plan Editor can be, and is being, run by itself  to georeference plans already in the 
tabular database.  Additionally, the user can start with the Plan Editor, assign the 
street and intersection reference numbers, and then press the [Add VPI Info] button to 
pull up the VPI menu and enter information there.  Connectivity is handled by passing 
the current plan number from menu to menu.

Query
Querying the Vault database is done using the Vault Plan Index menu, the same menu 
used for data entry.  Basically, there are three types of query available:  tabular, 
geographic by address, and geographic by quarter section.

The Query VPI menu allows the user to created rather complicated logical expressions 
without knowing the first thing about "XOR" and "not contains".  Commonly queried 
database items such as construction type, plan name,  and construction dates can be 
combined in much the same manner persons using the vault describe them.  A 
customer wanting to know what kind of paving and sidewalk activity has transpired on 
Alaskan Way in the last 15 years can easily be served using this menu.  Check boxes 
and input field restrictions prevent long, frustrating queries.  An example of the query 
menu is seen in the next figure.



The Find Address Interface also allows the user to search for certain plan types built 
during a certain time period.  Here, however, the customer's address or street 
intersection can be used to find the plans rather than relying on the plan name for 
location information.  With the Query VPI menu, for instance, all plans with Alaskan 
Way in their recorded name will be located, but with the Find Address capability, all 
plans within a 500 foot radius of Alaskan and 1st are what he/she gets.  This more 
robust functionality is based on the work done using the Plan Editor, and as such, is 
not complete at this time.  Until all plan extents are entered graphically, only a subset 
of the actual plans at that location may be found.  Other useful information obtained 
from the Find Address menu include the Quarter Section number, the City of Seattle's 
Central Library Database tile number, and the Vault Plan Index page number which is 
an index to the historic method of data storage, a 2’X 3’ map book with plan numbers 
and extents scribbled in manually.  An example of the Find Address capability is 
shown in the following figure.



Both of these query menus interface with the Vault Plan Index menu.  This means that 
plans selected with Query VPI or Find Address are available for viewing and editing.  
The user can thus scroll through all of the selected plans and access additional 
information not shown using the [List] buttons on the either query menu.

The final query capability provided for is a rather simple search for a quarter section 
number entered by the user.  The VPI page index number and the CLDB tile number 
are output for any input quarter section.  This helps the Vault staff in its efficiency at 
converting from an old to a new system and in locating standard maps generated by the 
City by quarter section.

Public Access
Although public access has been the driving force for the VPI interface, public access 
may still be a twinkle in the City's eye.  This interface does contain a prototype public 
access menu, basically an expanded version of the Find Address menu developed for 
in-house use.  This Find Address menu, however, attempts to compensate the user's 
lack of familiarity with the system with detailed, step-by-step instructions for finding 
one’s address.  Everything from the importance of cursor placement on the menu to 
quitting the popup list of plans found is covered.  Use of  this menu is limited mainly 
by hardware constraints.  Future enhancements will surely make public access a 
reality and a wonderful thing, but hardware and software changes will likely be 
needed.

IMPLEMENTATION ISSUES
A number of issues arose as the system implementation phase  for VPI was entered.  The 
following issues and recommendations were provided to the City.

Staffing is a major issue.  Once the plans are entered, staff time will be saved.  
However, for the conversion of data, additional staff are required.  The Vault 
staff have good knowledge of the plans.  No one else can provide that.  Help is 
needed on the technical side, for data entry into the system.  Dedicated 
temporary staff could meet that need.
Equipment upgrades would speed up the conversion and make the tasks less 
tedious.  Existing machines are not sufficient.
A proper work area, where plans can be laid out and a workstation is 
available, is needed.  A quiet area, without the interruptions of the counter, 
would be preferable.
Some plans, such as fire boat plans, have no geographic location.  These 
should be kept in the database and searched for by plan name or other means.
Other plans are located at sites that no longer exist.  We recommend that they 
be located as close to the original site as possible.  The plan name will keep the 
record of the original location name.

This list highlights one of the key factors in the development of any GIS application.  The 
conditions for the implementation are rarely ideal.  The constraints and solutions must be 
understood by staff and project managers.

THE FUTURE
As with any project, completion always ignites the imagination of other exciting things 
that could be done with today's technology.  For the Vault Plan Index, of course, the 
primary concern is still completion:  completion, that is, of the geographic data entry 
of the 30,000 plus plans already in the tabular database.  Estimated data entry time is 
2 years.  Making the current editor multi-user would certainly help this effort.  The 
system is quite useable in the meantime, though.  People are generally more concerned 
with the paving done 5 years ago than some wood planking effort of the late 1800s.  
And many areas of the city have very few plans.  Thus, with some strategic data entry, 
most of the Vault's customers could likely be served within a respectable time.

The fun stuff can then begin.  Public access is certainly a priority.  Porting some 
variation of the system to a PC version of ArcView seems the logical way to go.  The 
casual customer off the street is not usually in a position to pick up the three-button 
mouse and start clicking away on an ArcPlot menu.  ArcView, however, may likely be 
friendly enough and visually pleasing enough to make most customers' visit to the 
Vault enjoyable and productive, not to mention the Vault staff's job easier.

Scanning is now seen as the final frontier.  Oh, to pull up a digital image of a plan and 
say "yes, that's the one" or "nope, next".  Scanning 30,000 plans will not be quick and 
probably not easy.  But those old, ten foot long rolls of sidewalking plans from the 
turn of the century may live eons after the original has disintegrated and blown away.  
But seriously, the Vault is huge.  The staff spends countless hours searching for and 
unraveling plans looking for the right ones.  Once digital, the user can see it all on 
screen first and maybe that will be enough.

Ann Boyd
Gambrell Urban
720 3rd Ave.
Suite 2015
Seattle, WA 98104
Telephone: (206)467-6900
Fax: (206)467-0456
E-mail: gambrellurb@delphi.com