Laserfiche WebLink
(9) <br />I. INTRODUCTION/BACKGROUND: <br />HISTORY: <br />CITY OF SANTA ANA <br />EXHIBIT I <br />SCOPE OF SERVICES <br />In 2005, the City of Santa Ana Public Works Agency (PWA) initiated a project to scan their existing <br />engineering drawings and as -built plans. The City had already selected the Laserfiche Document <br />Management system and the Clerk's Office was using the system to store the City's official records <br />and documents, such as agendas, minutes, resolutions, ordinances, etc. Since the software selection <br />had already been set, PWA moved forward with the project and did not perform any requirements <br />analysis of the software to determine if it would meet the needs of the PWA EDMS. <br />During the initial analysis it was determined that, while Laserfiche was suitable for the Clerk's <br />documents, the indexing method that Laserfiche utilized was insufficient for the storage of engineering <br />drawings, due to the way the existing index of the documents was created. The existing Microsoft <br />Access index of engineering drawings included normal things like drawing types, project types, <br />numbers and dates, but it also included a rudimentary spatial index based on the project extent <br />recorded as the street name, from street to street. Each drawing was meticulously indexed to include <br />ALL possible streets that the project included, even if that meant indexing the drawing MULTIPLE <br />times. <br />At that time, the indexing schema for the Laserfiche database could not accommodate the multiple <br />indexing method for the streets without storing the document multiple times in the system. The City's <br />Consultant devised a method that would allow indexing of the drawings using the existing index <br />keeping only one drawing in Laserfiche. <br />1. A "go-between" SQL server database (EDMS) was created to store the multiple location index <br />information and would point to a single file stored in Laserfiche. <br />2. A web -based front end allowed the users to search for the drawings using controls they were <br />familiar with: Project numbers, drawing types and street locations. <br />• The database is "spatially aware" and when a street is selected as "on street," it only shows <br />the streets that could intersect with that street and it shows them in directional order. <br />• A separate "EDMS Update" application (EditEdmslndexDGV.exe) was developed to allow <br />new drawings to be added to the EDMS database. <br />• The application connects directly to the SQL Server "EDMS" database and performs the <br />following functions: <br />■ Allows user to add new drawings to the EDMS database with street locations, <br />drawing type, etc. <br />■ Generates new "Drawing Number" for each new drawing based on a set of drawing <br />types prefixes and sequential numbers (see below for example). <br />Drawing Number Convention <br />TT-XXXX where TT is the drawing type and XXXXX is a unique, system -generated sequence number <br />(Currently generated from the EDMS Update application) <br />Expectation is to continue this format using Laserfiche Workflow custom programming if possible. <br />23-009 EDMS LASERFICHE UPGRADE & MIGRATION WITH GIS INTEGRATION 18 <br />