PARCEL MAINTENANCE: LESSONS LEARNED

Authors: Stewart Dary, Celeste Murdock.

Orange County Property Appraiser's Office (OCPA), Orange County, FL, converted its legacy GIS data base from Vision to Esri’s ArcInfo and Spatial Data Engine (SDE) in 1999. During the conversion, OCPA also replaced all of its existing GIS applications – and created additional applications for a more effective, user-friendly, enterprise solution. The new applications included a parcel maintenance application, an enterprise desktop GIS solution based on customized ArcView, data management Arc Macro Language (AML) programs, and an internet map server. Due to plans at the Property Appraiser's Office to embark on a major, countywide parcel re-engineering project using the Esri data model, the time allowed to convert the data base and develop applications was limited.

This paper focuses on the lessons learned both during and after the initial development of Orange County Property Appraiser's parcel maintenance application. The parcel maintenance application, called "PAMAP," was developed in just six months using contract assistance and contributions from OCPA employees. PAMAP is a Visual Basic (VB) application that employs ArcInfo’s Open Development Environment (ODE) to edit coverages on NT workstations. The application provides a graphical user interface to many of the tools available in ArcEdit, including many coordinate geometry (COGO) functions and custom validation routines. The short development time described above presented unique challenges and taught the staff at the Property Appraiser's Office some valuable lessons. Topics include: the legacy system, current work environment, program requirements/performance issues, software & code bugs, contract development, training, operating system/hardware constraints (e.g., NT vs. UNIX), and solutions.

In the late 1980's and early 1990's, the Orange County Property Appraisers Office (OCPA) developed a digital parcel map for all of Orange County through the process of scanning tax maps, digitizing and rubber sheeting. Once the data was made available, it needed to be maintained. This was done by staff and contract cartographers using Vision (formerly known as GeoVision and currently held by Autodesk as Vision Solutions). The system consisted of a DEC 4100 Server, which hosted the Vision licensing and all of the data in an Oracle database. Each cartographer's workstation consisted of Dec-Alpha 500 workstations with their own copy of Oracle and the Vision software. Data work packs were extracted from the server and placed on each cartographer's workstation. The work packs were processed and then returned to the database. The cartographers used Vision's graphical editing tool, Graphics Editor, to update data changes in the work packs (See Figure 1).

Over the years, the cartographers became familiar with the use of the Graphics Editor and staff programmers were able to customize features to increase productivity. Features were customized using Vision's Graphical Macro Language (GML). Although there was an out-of-the-box feel to the Graphics Editor, there were multitudes of GML's in the background that made the process seem seamless. These GML's did everything from validating a layer's data types to checking the field values of a new subdivision. Although the entire system seemed flawless, there were a few drawbacks. One of these drawbacks became a nuisance for the cartographers. This was the calculation of curves, or lack thereof. Since Vision did not contain a complete set of commands for coordinate geometry, curves were input using derived calculations or digitization. Another concern for this system was the fact that it allowed duplicate labels, collinear arcs and unclosed polygons. Without a specific translator, this made exporting data to other systems very cumbersome.

In 1998, a thorough review of OCPA's enterprise GIS system found that all of the Vision products should be replaced. By December 1999, the Vision licenses were retired and replaced with Esri's products.

FIGURE 1. Graphics Editor Interface

Along with the data conversion in 1999, the GIS system was converted to Esri's suite of products. The workflow for updating data remained the same as the legacy system and is for the most part transparent to the cartographers. The main change for them is that their desktop system now consists of an NT workstation equipped with ArcView 3.1 and workstation ArcInfo 7.2.1. All of the converted data is stored in SDE version 3.0.2. A series of AMLs are used to check data in and out of SDE. A data work pack is checked out in coverage format, given to a cartographer for processing and then checked back into SDE with the new changes. Parcel records selected for editing are locked in SDE using a Job-ID column in Oracle. Once the parcels records are updated, the lock on the Job-ID column is removed.

To assist the cartographers with processing the work pack, a front-end application was needed. They were shown commercially available "off-the-shelf" parcel editors, but chose to develop a custom application. Using Esri's CoolEdit application as base code, an application called PAMAP was written in Visual Basic using ArcInfo’s Open Development Environment (ODE) tools. It tries to remove the necessity of command line knowledge by providing point and click routines for processing the data work pack. The main focus of the application is for the maintenance of converted data. It was created by a contract developer at the end of 1999 and was meant to be the equivalent to the legacy system's Graphics Editor (See Figure 2).

FIGURE 2. PAMAP from Contract Developer

In May of 1999, the requirements for the PAMAP application were written and given to the contract developer. Some of the major necessities included the following; First, the application had to emulate the look and feel of Vision's Graphics Editor, while running efficiently in ArcEdit. Since the cartographers were very comfortable with how the Graphics Editor worked, the ideal situation was to make sure they were provided with something very similar. To get this accomplished, a list of menu commands and their descriptions were a part of the contract guidelines for the final product. Second, the work flow must be handled efficiently. Not only was the cartographer trying to create a quality product, he or she was always trying to complete the work quicker. The application could not hinder this flow by requiring the cartographer to process numerous steps. Third, there had to be a module capable of importing files in DXF format. This was to enable the cartographers to see data compiled by outside sources. Fourth, digitizing was a must. Since a main intent of PAMAP was to provide the cartographer with an application that accesses all of the commands, a function was needed to allow connection to a digitizer. Fifth, the application had to provide the basic functionality of ArcEdit. Because of the differences in Vision and Arcedit, there were a number of commands that did not directly correlate between the software. In these cases, additional buttons were to be added for the Arcedit commands. And finally, a basic set of Coordinate Geometry (COGO) tools would be provided. All of these requirements were considered a part of the delivery, which was due the end of September, 1999.

There were many constraints that hindered the development of this contract. The contractor was allowed five months to develop the application. The application had to be developed using Visual Basic and ODE. The use of ODE became an issue because only one command could be handled by the processor at a time. Meanwhile, the NT operating system had limitations processing the panning of many large data layers. In addition, some concepts were different on how to process data between the Graphics Editor and ArcEdit. Such features as grouping different features or working all layers of data at one time were not available in Arcedit. Since the cartographers were comfortable using Graphics Editor, there was reluctance to change to any other application.

Per the contract, the application was developed off-site. After some delays, the OCPA requested daily progress reports on its completion. The application was delivered in November of 1999, but was somewhat different from what the cartographers expected. Some of the features that were in Graphics Editor were not in this new application. As the requirements stated, the main focus for the development of the PAMAP application was to create an emulation of Graphics Editor. Many of the commands had the same name as the Graphics Editor but executed differently. This again was due to the different concepts of the software. By this time, it was obvious that there was more work to be done in order to get close to the level of Graphics Editor. Another contract was written for "enhancements" to the application. Time was now of the essence. Taking this into consideration, some changes needed to be made. The modules of the most critical nature were altered or replaced. Those that could be used, would be changed at a later date by staff programmers. Still there were other modules that were removed altogether. These included importing DXF files and connecting to a digitizer. The enhancements were in place by January of 2000 and another delivery of the application was provided.

The cartographers were allowed to review the revised deliverable. They found problems with the application. Some of these were logic errors, some were business rule errors. Others were larger problems. Examples of the logic errors included starting a never-ending loop while checking input on a number of text boxes. Another issue was allowing empty values to be passed as the text string to an annotation feature. Some of the business errors included not updating certain fields on the data layers and not providing any type of field verification or validation. Some of the larger problems involved fatal errors that crashed the entire application, for instance, building different coverages consecutively or reentrancy errors, which are specific to the way commands are passed to ArcInfo's ODE. 

There were also problems that were not as obvious. These involved data becoming corrupt by scrambling of the Polygon Attribute Tables. For no apparent reason, all of the polygons would pick up the attribute values of just one of the polygons or the attribute values would not be the same as when the cartographer last saved the data. There were processes that bogged the cartographer down. Each time a different edit feature was chosen the screen was redrawn. There was nothing in place to allow for multiple processing of features. In other words, if a row of lot numbers needed to be aligned, the cartographer had to constantly go back and forth to the menu to choose the move command. This slowed the cartographers down.

The combined problems of software bugs and the differences between the Graphics Editor and PAMAP caused frustration for the cartographers. They were very patient as solutions were formed. Two solutions were formulated with the awareness that now there were two groups of cartographers, each processing data in a different way. These groups of maintenance cartographers and re-engineering mappers each had special needs to process their data. The first solution was to eliminate the bugs in the current PAMAP and add any enhancements that would make it run smoother for the cartographer. This solution was put in place as soon as possible. There were over 75 changes made to PAMAP since its final delivery (See Figure 3). These changes were a combination of removing errors and making enhancements. There was a robust set of validation tools added to PAMAP so that errors could be found quickly. Although there were concerns about underlying errors that cause scrambling of data, the application could still be used for the cartographers doing maintenance.

Figure 3 Current PAMAP Interface (showing enhanced functionality)

The second solution was to completely replace PAMAP for the annotation placement and attribute input for the re-engineering mappers. The task of the re-engineering mappers was to re-engineer the entire county parcel map using survey control, plats, legal descriptions, and coordinate geometry (COGO). Since many of the re-engineering mappers were knowledgeable about ArcInfo, they felt comfortable working in ArcEdit to input line work. The main need for this group was to have a tool that quickly inputs annotation and attributes. This tool was written in AML by OCPA staff and is called B3TEXT (See Figure 4). It is used strictly for text, but the user can access the command line to input line work.

FIGURE 4. B3text Interface

Although these solutions are working very well for each group, other solutions for both groups are being investigated, including upgrading to the ArcInfo 8.X.

With any new application, training is a necessity. This case was no exception. Since this was a switch from Unix to NT, not only did the cartographers need training on the application, but also training on the operating system. With the application itself, the concern became how much knowledge was needed for the cartographer to accomplish his or her job. Again the intent of PAMAP was to eliminate the need for command line knowledge, but the cartographer would still need to understand simple ArcEdit rules, topology and syntax. Since certain modules would be removed from the original set of requirements, the cartographers would need to know how to complete those processes manually. This was somewhat confusing for the cartographers, especially once they learned PAMAP, where many of the commands are represented with equivalent names used in Graphics Editor. They now had to learn the basic commands to startup ArcEdit and conduct a session to digitize. Procedural manuals were written and distributed as a guide to using both PAMAP and B3text.

In conclusion, there were many hard learned lessons during and after this project. One is to fully assess the background and time available of a vendor. Find out if they have completed this type of project before and ask for examples. Also, have them work on-site to ensure constant communication for quality assurance purposes. Another is to know your end users, know what works for them now and what would make their job easier later. Make sure the end users are involved in the development of the requirements. The requirements should SPELL IT OUT. In other words, be very clear about the type of application needed as a final product. The contract developer on this project was allowed to make many decisions about the application because they were not spelled out in the requirements. Be aware of hardware, operating system, and software constraints. Once your application is delivered, take the time to thoroughly review it. If the requirements were very specific you should not have a problem with what was delivered. In addition, allow sufficient time for contract development, user needs analysis, application development, testing and training. Be sure to have sufficient staff to support the application after the product is delivered. Any contract developer is going to have concerns about "Scope Creep" and will not want a project to become a never-ending story. This is where decisions have to be made about how to continue. Once the decisions are made, be prepared to live with them by supporting any new changes or contracting for upgrades.

Stewart Dary
Information Technology Director
Orange County Property Appraiser's Office
200 South Orange Avenue, Suite 1700
Orlando, Florida 32801
(407) 836 5376
sdary@ocpafl.org

Celeste Murdock
Sr. GIS Programmer Analyst
Orange County Property Appraiser's Office
200 South Orange Avenue, Suite 1700
Orlando, Florida 32801
(407) 836 2745
cmurdock@ocpafl.org