During the past year, a public access system was designed using ArcView for the Jefferson County Property Assessor. The assessor has been providing public access for many years, but this information has been limited to the tax roll only. The large parcel database ( 280,000 parcels ) has only been available in the form of standard tax maps. A system was designed to provide the public access to the GIS which combines both the map and tax roll. This paper outlines the process of designing such a system and highlights the successes and difficulties which occurred along the way.
The concept of using a GIS system for public access is not exactly new. For the past several years, many communities have implemented GIS public access systems and many of those were implemented using ArcView2. So when the decision was made to go forward with the design and implementation of a parcel public access system for Louisville/Jefferson County, the project was expected to be completed with little difficulty. The actual system implementation turned out to be extremely challenging and many road blocks were encountered along the way. This paper outlines the successes and difficulties which occurred along the way. The Property Valuation Administrator's office, PVA, has been providing public access in the form of database inquiry terminals for many years. In addition to computerized database records, a set of tax maps are made available to the public. These tax maps have been produced and maintained using ArcInfo for the past ten years. It has long been a goal of the assessor to replace the constant production of tax maps, with computerized public access terminals which provide both map and assessment information to the public in an up to minute fashion. The project started with a meeting with the PVA to discuss the desired system requirements for the application. During this stage, no assumptions were made as to what software would be used or what hardware platform the system would be deployed on. Simply, what was their vision of a public access system. This meeting produced the following design goals. 1) Easy to use 2) Fast access 3) The system needed to be secure from public sabotage. 4) The system should provide attribute information using the same familiar screens the public had been used to seeing for the past several years. 5) The system should provide hardcopy maps in both 8.5 x 11 and 11 x 17 format. 6) The user should be able to locate a property by: Owner Name, Property Address, Parcel Id, Subdivision Name, or Taxing Block. 7) Once zoomed to a parcel, the public should be able to Pan and Zoom or set a precise map scale. The largest number of users of the current system are land developers and appraisers and the ability to produce hard copy at precise scale was a requirement. 8) Finally the system should allow the information for any parcel on the screen to be identified by clicking on the parcel of interest. Following this meeting, a design team was formed to brainstorm the creation of the system. This team formalizes the implementation of design concepts into a software design from which all team members could code from. Typically this focuses on the Graphical User Interface, GUI, making decisions of database requirements, and modularizing the system into definable programming parts. During this phase, it became apparent that the choice of which GIS software to use was not so clear. Both ArcInfo and ArcView had strengths and weaknesses which had to be evaluated before a given programming direction could be started. The following outlines the strengths and weaknesses of each software: ArcInfo Strengths: 1) Application staff were familiar with and had many years of experience implementing ArcInfo applications using AML. 2) ArcInfo has better cartographic quality. Better line symbols, markers, and annotation font quality were available in ArcInfo. 3) The icons could be made to any size. 4) The GUI is more customizable. The ArcView GUI is fixed to a MENUBAR, A BUTTONBAR, and a TOOLBAR each of which is located in a predetermined location. Dialog boxes are extremely limited and the location of the dialog box is not controllable. 5) ArcInfo provides full support for all of the ArcInfo data structures. This is especially true of libraries in which all data for this application would be accessed from. ArcInfo Weaknesses 1) Expensive. ArcInfo carries a lofty price tag and this cost would limit the number of public access seats. 2) Everything needs to be programmed. While the ArcInfo GUI is not as limited as ArcView2, without programming, it is non existent. 3) UNIX workstation platform only. ArcView2 Strengths 1) Cheaper. ArcView has a lower up front cost and no yearly maintenance. 2) ArcView2 can run on UNIX workstation or WINDOWS PC. 3) Predefined GUI already does many of the required features (ex. pan, zoom). 4) New development environment. Staff love a challenge. ArcView Weaknesses 1) GUI is inflexible. Interface is limited to MENU, BUTTON, TOOL design. Popup Forms with user verification and custom look and feel are non existent. 2) Icons are fixed in size and generally too small. 3) ArcView support of ArcInfo Libraries is not very strong. You can not store item indexes on Library layers. 4) ArcView has its own geocoding structure which requires each client to rebuild those structures whenever the data changes. Our streets and site address layers change daily. 5) Longer development time. When analyzing other public access applications written on ArcView, it became apparent that we were alone in trying to develop a system that accessed real-time GIS databases. Each of the systems we reviewed, used raster images to display GIS data and not vector ArcInfo coverages. Even with all of the uncertainty of ArcView development, the team decided to proceed using ArcView2. The low cost and the challenge of a new way of development were too great. All along the way, different technical obstacles were encountered. These obstacles would of course set the development schedule back as staff worked on innovative work arounds. Commonly we would have to replace what was thought to be able to be performed with standard ArcView functionality with custom Avenue programming. The following paragraphs outlines the problems encountered and the techniques employed to overcome them. 1) The first problem encountered was how to tie the Real Estate Master File, REMF, to the parcel polygon layer. This was always done using a simple ordered relate in ArcInfo. It did not take long for us to come to the conclusion that ArcView does not relate. ArcView wants to do a virtual table join when a view is opened to join two tables. There are 280,000 parcels in the county and the REMF is over 100 Mb. in size. Using standard ArcView joins or links, this process would take either hours to complete or would simply lock a UNIX workstation up. No PC was capable of performing the join because it would lock up or run out of disk space trying. The solution was to write an avenue script which would perform a binary search on the REMF. This provided fast access to the REMF but required the identify functionality to have to be re- written in Avenue. 2) Another major obstacle was the whole issue of ArcView item indexes. ArcView2 item indexes are extremely limited. ArcView indexes are only used for equal to searches. Any search which uses greater than or less than performs a sequential search. This limitation would make searching for an owner by name impossible as users typically provide starting characters to quickly select the proper owner name choices. A sequential search of the REMF would take 10 minutes on a UNIX workstation and an unknown amount of time on a PC. The fact ArcView2 uses its own indexing structure further complicates things. Another problem is in the way ArcView does reselecting from an already selected set. While an index could be used to quickly produce your initial set, a subsequent reselect query performs a search on the entire set of records and then "AND"s the two results to form the sub-selection. The most severe indexing problem however involves the fact the ArcView indexes are not stored for Library layers. If an index was to be built on the PARCEL ID field, the index would have to be rebuilt each time the project was re-opened and creating an index on 280,000 features takes a long time, so how could we zoom to parcels quickly if indexes could not be used. The answer was to build our own indexes. Using our own index tables we could once again use Avenue binary searching to quickly find , equal to, greater than, less than, queries. Once we quickly found the proper set of parcels by owner name or subdivision, we still had the problem of zooming to those parcels. The solution was to store the x and y coordinates of the feature in our index tables. Where attribute indexes were not compatible and limited, spatial indexing and spatial searches within ArcView is fast. When we need to zoom to a parcel, we would look up in the index to get the x,y coordinates of all parcel pieces, and then select all of the parcel polygons that intersected those points. 3) The requirement to zoom to a parcel by an address, again turned out to be one of those areas which would require major re- thinking. This required using our site address coverage for geocoding. This coverage contains a point for each address in the county and is maintained on a daily basis. The problem is that ArcView uses its own geocoding structures and these structures would be rebuilt by each public access workstation at the beginning of every day. It would take a workstation 45 minutes to build the required geocoding structures and a PC close to 4 hours. This pretty much eliminated using standard ArcView techniques. The solution was once again to build our own table of parsed addresses and their XY coordinates. We used ArcView2 to parse the user input into standardized fields and then utilized standard binary searching techniques to locate a match. We had to write our own reject mechanism to provide the user choices when a value was not found. Our reject mechanism is nowhere near as powerful as the ArcView2 engine, but the performance of this approach far out weighed the minuses of a more simplistic reject engine. 4) An innovative approach was used for the display of the attribute information. The user required displaying the four pages of information for a parcel in the same format as what was used in the current public access system. It was felt that popping up a display window which would obliterate the screen was not desirable. The user would have to be knowledgeable of raising, lowering and moving windows, not an inherent skill of the general public. Our solution was to connect a VT100 terminal to the serial port and the Avenue application would drive the display of attribute information to the attached monitor. This meant that each public access terminal would actually have two screens, one for the graphics and one for the text. This removed the difficulty of windows management and made it possible to look at a page of attributes and the associated graphics at the same time. The requirement of the extra terminal added little cost to the overall public access seat. 5) Difficulty was even encountered with the normally simple things in life, like sending a plot to the plotter. On workstation, plot files are created in Postscript format and spooled to the printer. When this was first tried, plot after plot would come out with a blank page. If we spooled the file from outside ArcView all was well. We therefore theorized that the plot file was not being closed and soon found out there was not a request to close a plot file. We tried opening another plot file once we were completed with making the plot, but this had no effect. The final solution came some two frustrating days later when we decided to delayrun the spooling script. It seems that the plot file would not close until the script exited and a delayrun of 1 second was sufficient to allow Arcview time to close the file. During the entire development process, we tried to keep the decision of whether to use a PC or workstation open. We measured performance and assessed security issues and quickly came to the decision to use the workstation. Workstation ArcView is much quicker at drawing and this difference in speed is even greater when drawing polygons. The other problem with the PC solution involved trying to make the Windows environment such that a user could not ALT TAB or escape the ArcView application. If the user could get out, there was nothing to stop them from erasing the local PC hard drive. When we were unable to find sufficient PC experience within our organization, the obvious decision was to go with the UNIX workstation, where we were experienced at modifying the keymap file and customizing the login scripts. In reviewing this project there were several conclusions that one could make. The final system was an easy to use tool utilizing ArcView2 software that was fast and very user friendly. The billing of ArcView2 as a public access tool is a bit over sold. The core Arcview functionality had to be commonly discarded and replaced by Avenue trickery. ArcView can be an excellent tool for developing a public access, but be prepared to due a large amount of Avenue development.