Steve Allenstein

Model-Based ArcView Development:

A County Tax Parcel Interface

Abstract

Once an ArcView application has been developed for a particular client and problem context, it can be difficult to re-use in other different but similar circumstances. When adapting such applications, major code revisions are often needed due to differences in underlying data models, and in the logical data views and operations desired by different clients. Also, the difficulty of revising Avenue scripts increases with the size, complexity, and functional scope of the application.

This paper examines an approach to ArcView development which is model-based. A GENERIC model of the application and its database is developed by simulating the creation of higher-level objects relative to those available in ArcView. The model is specified by the developer who makes entries in ArcView table documents. Once a model has been developed, it may then be CUSTOMIZED to similar situations. Customization is accomplished by adjusting the table entries, or more dramatically by deleting or adding new table records.

The technique has several advantages. Within certain constraints, it accommodates the transformation of different data models into that of some standard. It allows a certain level of independence of the application from its data. It allows for easy revision and re-use of previous developed applications. It may also be generalized into an object-oriented framework that employs a truly extensible programming language.

Introduction

The common thread which binds the attendees of this conference is an interest in GIS technology relative to a particular problem or area of application. Software engineering technologies such as Object Oriented Programming (OOP) are part of a global economy that has revolutionized the production of software components across ever-expanding domains. It does so through efficient assembly of parts into marketable products. The transfer of this technology across institutional structures is reorganizing society and the way we work. As the dissemination of GIS technology continues to open new doors for application, new questions and priorities will emerge. The question of appropriate product design will come to fore, not only in the marketing of such products, but also in the use of these products to address issues of concern at the local level.

The premise underlying this paper is that global forces will never be able to fully respond to the requirements of local situations. Almost by definition, marketing strategies respond to the aggregate characteristics of populations, rather than idiosyncrasies of local initiatives such as landuse planning, or the re-districting of legislative representation or school attendance zones. Local situations encompass many more variables than a marketing strategy can formulate. Local situations also display a 'fast dynamic' that requires 'real-time' application planning and design. GIS application developers who respond to local situations require additional flexibility in the products which they use in order to respond in kind.

In this context, this paper reviews an approach to GIS application development which is "model-based". The approach encompasses the topic of GIS/model integration, yet it goes beyond this to suggest that the whole of a GIS application and its problem context is amenable to model-based representation. A local Land Records initiative concerned with data integration provides the vehicle for the discussion.

Project Background and Overview

The purpose of this project is to develop an ArcView interface for use with local Land Records, one which might be used in a local land information or tax assessor's office. Specifically, the interface is to support nominal browse and query operations on tabular and spatial databases. A consortium of eight County governments in Wisconsin and Illinois, a private consultant, and University researchers is involved in the effort, with various County agencies serving as clients. The initial phase of the project focused upon issues related to implementation the interface within an agency context. Later phases will be concerned with Public Access to information contained in these databases.

Objectives: Various goals and objectives were established from a series of consortium meetings and survey questionnaires. From the standpoint of GIS application development, the main requirements and constraints are listed below.

(1) Data Integration -- The interface will serve to integrate local tax assessment records in tabular form, land ownership parcel coverages, and related land-based information.
(2) Browse and Query Capability -- The interface will support nominal browse and query operations on tax parcel data only. In later phases this functionality may be expanded to other thematic types.
(3) Exclusive use of ArcView/Avenue -- Exclusive use of Esri's ArcView/Avenue product as the application development environment. Limited financial/technical resources rules out 'high-end' solutions such as an integrated ArcView/SDE/Oracle solution. Later phases of the project may examine the use of other software to augment interface functionality.
(4) ArcView Look and Feel -- Maintain and otherwise enhance the ArcView interface.
(5) Separate Database for the Interface -- A separate database will serve project needs in order to protect coverages and tax files from potential abuse by users. It will be a relatively static database which is periodically updated. Feature-based data will be in shape file format to enhance ArcView performance. Image data will be in TIFF format. A second interface project (not discussed in this paper) coordinates the necessary format conversions and other pre-processing needed by the shape file database.
(6) Use of high-end PC hardware -- under NT or Windows95


Questions: From this, several challenges of a technical nature can be inferred.

(1) How does one design a 'single' application for each client without extensive revisions to Avenue code each time the interface is installed and/or enhanced with new features?

The interface must be installed for each county participant. The manner in which databases are organized varies widely across the different county participants. Some have fundamentally different data models. Moreover, each client has somewhat different desires and expectations. While agreement was reached as to what constitutes 'core functionality' for the interface, customization and revisions are expected.

(2) How does one manage 700 to 1000 ArcView themes in a single project?

The databases for County-level Land Records and Tax Assessment can be quite large. Some of the data layers are tiled by PLSS township. Good cartography, graphic design, and other operations require representation of a full range of available feature types for any particular thematic type. This leads to a lot of themes in a single ArcView project.

(3) How does one design a responsive ArcView interface under these constraints?

A Solution for a Tax Parcel Interface: Given the requirements and constraints discussed above, the challenge of this project was not the implementation of the usual interface functionality that is commonly associated with ArcView. Rather, the challenge was responding to the social context of the application -- the needs of the consortium and individual agencies, including financial/technical resources and established practices in handling spatial data.

A 'modeling environment' was developed for creating ArcView-based interfaces to tabular and spatial data. Once the developer constructs a model, the ArcView interface becomes operational only if the model is internally consistent and the data to which it refers can be found. The strategy allows for development of a generic model of an interface that might be expected to accommodate a range of needs. It may then be customized to meet specific needs.

The Tax Parcel Interface is based upon this development strategy. The underlying model, or Application Model, consists of two sub-model components and a user interface for model specification. The Operations Model component is a 'finite state machine' for use with ArcView. The Data Model component is a high-level data manager for the application. Using ArcView Table documents, the developer makes record entries for various 'high-level' interface entities, constructs which are not built-in to ArcView/Avenue. The fields of the record entry constitute a set of properties for the entity. Such entities are discussed in detail in this paper.

The development activity for this project consisted of two phases, the first concerned with developing the necessary tools and functionality, and the second concerned with constructing a generic Application Model for the clients. Subsequent phases will involve model customization for individual agencies.

The remainder of this paper examines various aspects of the solution which is organized into four sections.

(1) GIS Application Modeling Approach
(2) Operations Model Component
(3) Data Model Component
(4) Model Specification and Viewing Interface
(5) Appendix: Tax Parcel Interface Screens

GIS Application Modeling Approach

The approach used to develop the Tax Parcel Interface is based upon the idea of a 'model'. Models are simply abstractions or generalizations of real-world phenomena, in this case a software system, its users, their agency and related mandates. The Tax Parcel Application is based upon such a model. The approach is rooted in an Object-Oriented (OO) system analysis methodology which is part of this author's interest in issues surrounding GIS/model integration.

Object-Oriented Approach: There are numerous approaches to the analysis of real-world systems, most of which use abstractions of various sorts to organize concepts and manage real-world complexity. These approaches have been developed over past decades for a number of different purposes. Recent years have witnessed the development of Object-Oriented Programming (OOP) and related techniques for system analysis. With roots in the discrete modeling methods of the 1960's, the various OOP approaches are enjoying growing success in software engineering and database design. In contrast to some other methods, they tend to focus upon systems of technology rather than the social-institutional contexts which use such technology. However, some applications are starting to appear that are concerned with the development of enterprise-wide object standards, as driven by efforts related to corporate or agency re-engineering.

The advantage of the OOP approach, relative to other approaches, is that it provides an explicit methodology for conceptualizing a system at different levels of abstraction. Whether one is developing a software application or a simulation model, a basic distinction is made between the real-world system and its modeled surrogate. In particular, a model of the DOMAIN is distinguished from a model of the APPLICATION (Rumbaugh 1994b). The Domain Model is bound by issues related to problem definition and associated perceptions. The Application Model is a high-level translation of the domain into constructs that are meaningful for software development.
The model building process begins with the perception of a real-world phenomena relative to the problem at hand. These are mapped into pictorial diagrams which capture entities, relationships, and system boundary, possibly at several levels of abstraction. Gradually, initial perceptions are refined into definitions that are called 'classes'. Objects are created in a computer from such definitions. They may be related to a real-world domain, or they may have no meaning outside of the computer application.

GIS/Model Integration: Building upon the framework of Rumbaugh (1993,1994b), the approach can be refined to accommodate particular concerns that are increasingly relevant to GIS applications, that of (1) GIS/model integration, and (2) an explicit recognition of the social and/or policy context of model development and use. Relative to GIS/model integration, most of the work to date has focused upon environmental modeling (see Nyerges 1993), which encompasses a limited number of real-world domains. GIS technology will continue to disseminate to new applications and become increasingly relevant to new domains. The models employed by these disciplinary specializations are explicit representations of the Domain Model. The second area of concern is necessarily related to the first, since the social (scientific or policy) context of model development and use determines, to a large extent, the frames of reference and epistemologies in which problems are defined and negotiated (King and Kraemer 1993). These considerations have certain procedural ramifications for a modeling effort, which are beyond the scope of this paper (see Checkland 1981, Dutton and Kraemer 1985, King and Kraemer 1993).

GIS Application Model Framework: By incorporating such refinements, one may define four general components of a GIS Application Model according to data abstraction principles. These components are classes of general functionality that are required for building spatial models. Depending upon the nature of the application and technology employed, certain components might be omitted or otherwise combined. Note that the functionality commonly associated with a commercial GIS is embedded across the component models. The framework is compatible with emerging notions of a distributed, object-oriented GIS.

(1) Domain Model -- A representation of a real-world system of entities and relationships. Practically any model that is linked-to or embedded-in a GIS may qualify as such. Possible domains include Environmental modeling, Demography, Econometrics, Decision modeling, and so forth. It may include non-mathematical algorithms and control of a heuristic nature. The disciplinary specialization of more established domain models requires that GIS applications will increasingly need to reference such models as stand-alone components, possibly in a distributed object environment (see Maxwell and Costanza 1995).

(2) Data Model -- A representation of a real-world system entities and relationships whose attributes may assume values for model instantiation. This is a type of Domain Model which is treated separately here because of the specialized role it may play in GIS applications. It may systematically structure the data -- provide for high-level schema and logical views of data, among other things. It may also provide access to spatial metadata or other data standards.

(3) Operations Model -- A representation of software structure and behavior. The model conceptualizes the underlying application technology relative to algorithm, control, and human behaviors involved in use of the application. It does not represent elements of any real-world domain, unless it is somehow combined with a domain model. It may include algorithms and control that generalize across many domains and hence are not specific to any, such as spatial analysis, dynamic simulation, location/allocation, optimization, machine learning, etc.

(4) Model Specification and Viewing Interface -- A representation of software structure for model specification, viewing, and communications. This is a type of Operations Model that provides a user interface for modeling purposes, and includes alternative representations for any of the model components listed above. Such functionality enables user control over model parameters and structure.

This framework also borrows ideas from more traditional simulation modeling methods, particularly System Dynamics (see Roberts et al. 1983). Applications which are designed to respond to a policy or social decision-making context require alternative means for representing the model and its output. Such provisions 'open-up' the model and allow participants to view model organization. This facilitates storage and retrieval of model abstractions for public scrutiny in a manner that clarifies underlying assumptions and promotes negotiation of alternative problem definitions. This is vital to determining (external) model validity. Such provisions might also be combined with those used for model specification. Iconic representations have become popular for such purposes, as implemented in some commercial modeling packages such as STELLA for System Dynamics (Richmond et al. 1996).

Concept for a Tax Parcel Interface: Under the framework discussed above, the Tax Parcel Interface requires an Operations Model, Data Model, and Model Specification components to fully implement an Application Model. For this application the Domain Model discussed above is essentially the SAME as the Data Model. Furthermore, the Data Model was embedded as a component to the Operations Model, for reasons that will be discussed later (figure 1).

Figure 1: Application Structure

The functionality of the Operations model was developed as modular code or 'tools' to allow easy customization of the application (figure 1). These include a Query tool, an Report generation tool, a Layout tool, a Location map tool, among others. They may be loaded into and unloaded from the ArcView project. Use of particular tools are dependent upon Operations model, and ultimately upon problem context. The remainder of this paper discusses each model component in turn.

Operations Model:

Organization of Application Objects

The first component of the Application Model is the Operations Model, which is a direct incarnation of the OOP methodology employed. The interface design phase commenced with preliminary 'design sketch' stages, and proceeded through development and review of prototype software. The resulting model describes a general-purpose 'finite-state machine' designed for use in ArcView. The developer specifies application states using an table documents associated with the Operations Model, and implements transitions as actions defined in application controls. The latter task involves some 'top-level' custom scripting using Avenue.

General Operations: A generic set of interface operations were identified in preliminary design phases of the project. This represents the kinds control the user will have over the behavior of the interface. While the ultimate needs of each client differed, basic agreement was reached over what constitutes a core functionality for the interface. A fundamental breakdown of interface operations is listed below with more description to follow.

* Data Layer Selection
* Geographic Navigation -- feature-based location of geographic extents
* Parcel Query -- spatial and attribute query over a range of geographic scales
* Output-- make maps and reports

Interface Organization: At the design concept level, the interface was conceived as a set of 'screens' in storyboard fashion. Each SCREEN corresponds with an analysis and breakdown of particular user behaviors, or set of behaviors involved in using the interface. Through the course of client review and subsequent development the organizational scheme changed only in the details of implementation. The basic organization of the interface includes the SCREENS listed below.

Introductory Orientation Screen -- opens with a county-scale view of default data layers including Minor Civil Divisions, Major Roads, and Major Hydrological features displayed in a Primary View document. An adjoining menu document contains custom GUI controls which allow transition to the screens listed below (Appendix - figure 8).

Choose Data Layers/Attributes Screen -- presents the user with 'check-mark' style of GUI control for selecting particular data layers, including thematic attributes. Another controller allows return to the Introductory Screen at which time the display of the Primary View is updated (Appendix - figure 9).

Navigate Screen -- offers different geographic navigation modes to locate a feature or geographic extent. The user may navigate by Parcel ID Number, Owner Name, Owner Address, Street Intersection, Zoom Rectangle, and Lake Name. Located features or extents are displayed in the Primary View document. Locating a feature does not change the parcel selection set, rather a located feature is indicated using a colored outline. An adjoining menu document contains custom GUI controls which allow the user to proceed to an Output Screen, or return to the Introductory Screen (Appendix - figure 10).

Parcel Query Screen -- offers different modes of query on the parcel database, including Attribute Match, Attribute Range Query, and Parcel Buffering. Executing a query changes the selection set, which is displayed in the Primary View document. Once a query is executed, the user may SCAN the selected set of parcel features and corresponding tabular attributes. This is accomplished using a split-screen composed of the Table and View documents (not shown). An adjoining menu document contains custom GUI controls which allow the user to proceed to an Output Screen, or return to the Introductory Screen (Appendix - figure 11).

Map Output Screen -- displays a Layout document of the current extent in the Primary View document. An adjoining menu document contains custom GUI controls which allow the user to print the Layout document, or return to the Introductory Screen (Appendix - figure 12).

Report Output Screen -- displays selected Parcel attributes in text format using a Layout document. The user may scan through possibly multiple pages of such data. An adjoining menu document contains custom GUI controls which allow the user to print the Layout document, or return to the Introductory Screen (not shown).


Model Development: In this project the Operations Model deals exclusively with Application Objects (Rumbaugh 1993). These are computer representations of entities which have no meaning in the real-world, and whose sole purpose is presentation of domain objects or to otherwise implement a computer interface. ArcView is essentially a collection of Application Objects. Domain entities are represented in the Data Model discussed in the next section.

The interface itself is organized into a set of STATES and TRANSITIONS between the states. Only the interface states are represented in the model. Transitions between states are defined by the actions of interface controllers and tracked through the use of a system-based stack. The conceptual SCREEN object generally corresponds to an interface STATE, which is implemented as a collection of ArcView documents that are appropriately placed on the computer monitor's screen.

Additional functionality was developed to augment ArcView's concept of a GUI Control. Early in the process it was recognized that a proliferation of ArcView Buttons and Menu Choices would not serve the needs of novices (and ultimately the general public). An alternative controller concept was designed which uses ArcView Graphic objects with an object tag that store the names of a Click and an Update script. These are executed by a controlling process which the developer specifies as part of the interface structure. Such custom controls may be used in View or Layout documents and allow the use of 'instructional text' and other graphics in conjunction with the control box (appendix 1, figure 9). This functionality is packaged as a separate script module.


Simulation of High-Level Objects: The Object Model (OM) diagraming method (Rumbaugh et al. 1991) was used to structure thinking on interface design. The method is useful for organizing programming concepts used in the Application Model. As such, the storyboard of SCREENS identified at the conceptual level is roughly translated into the diagrams shown in appendix 1, figures 8-12.

Figure 2: Simulation of High-Level Objects

Such treatment integrates component Operations and Data model into a hierarchy based upon relationships of Aggregation or Association (figures 2, 3). Note that the OM diagrams are used differ slightly from the usual intent, for reasons that stem from the use of ArcView/Avenue as a development environment. Typically such diagrams are used to portray Generalization schemes -- the inheritance of attributes and functions across a class hierarchy. However, an inheritance mechanism was not implemented in this project. The OM diagrams could be reworked in terms of generalization given the use of a true OOP language.

Because Avenue is not in itself an Object-Oriented Programming language, any new class defined by the Application Model cannot be realized using Avenue. Consequently any new 'pseudo-classes' portrayed by the OM diagrams can be thought of as 'data types'. These were implemented as tuples in the form of Avenue Lists (figure) and are stored in an internal Dictionary . This may be considered analogous to the definition of a table relation. The technique employed in this project constrains the creation of new data types to the association of at least one existing Avenue class with additional (new) attributes.

Likewise, 'pseudo-objects' instantiated from such definitions are technically not objects at all, but rather an association of at least one pre-existing Avenue object with a set of VALUES (figure 2). Such associations are also implemented as tuples stored in Avenue property lists. Typical attribute values include the identifier(s) of associated Avenue objects, default settings for the attributes of associated Avenue objects, and values for new attributes of the 'pseudo-object'. Examples of new attributes include the names of scripts which handle new kinds of 'pseudo-events', such as opening and closing an interface state or changing the extent of a view. There are a number of such attributes in the Operations Model. Together they provide a framework within which the behavior of the application is defined. The developer writes custom scripts and assigns them as handlers for these properties, some of which are listed below.
The development of Avenue scripts was modularized relative to the new data types defined in the OM diagrams. Here again, since Avenue is not extensible these are not member functions which belong to a class. A script naming convention is imposed in order to logically group the scripts by a name substring. The resulting module also includes scripts which provide definitions for the data types which are encapsulated with the script module.

Pseudo-classes for the Operation Model are shown in figure 3 as an hierarchy defined by Association and Aggregation, rather than the usual Generalization relation implemented in inheritance. Where exceptions occur (indicated by the 'isa' label), the tuple of the corresponding pseudo-class employs a Boolean item to flag the data sub-type. The remainder of this section describes the 'objects' which were defined using this method.

Figure 3: OM Diagram for the Operations Model

Application Document: Beginning at the bottom of the OM diagram in figure 3, the standard ArcView document classes (View, Table, Layout, etc.) are augmented with additional properties, resulting in data types with names such as "App_View" and so forth. Properties common to all these data types are associated with the abstract type "App_Doc". Some of the new properties introduced at this level include defaults for the event handling properties of ArcView's Doc class. These are listed below.

* Open script, Close script, Update script -- for instances of ArcView Doc class
* Screen Tiling script, Screen Tile rectangle (if cached)
* App_GUI alias -- link to Application DocGUI and associated properties

An App_Doc data type is also associated with an App_GUI data type, by primary-foreign key relationships. The App_GUI data type is an aggregation of an ArcView DocGUI and properties which allow for sorting and toggling of ArcView Control visibility, as well as substitution of a Control's event handling scripts. Alternatively, the developer may also clone a default GUI, customize it, and simply associate it with an App_Doc, without incurring the overhead of sorting and visibility toggling.

Application State: Moving up the hierarchy of the OM diagram in figure 3, the "App_State" data type is encountered next. It models the STATE of the ArcView application, which was referred to as a SCREEN at the conceptual level of development. An App_State is composed of a set of App_Docs with coordinated attribute values. For instance, a state may consist of two views and a table whose associated windows are open and positioned such that they tile the monitor screen (appendix 1, figure 11). Some additional properties introduced at this level are listed below.

* Open State script
* Close State script
* Activate State script -- invoked when document focus changes

There are two kinds of App_State -- non-operational, and operational -- which are not shown in the diagram. These are essentially modes. Non-operational states are used for development and configuring the interface to specific data sets. Operational states are used for in a functioning interface, and includes a single pre-defined state -- the "Intro State". All other operational states are defined by the user/developer.

Application Model: The top-level of the OM diagram in figure 3 is the "App_Model" object. This is a the top-level data type in the Operations Model. Its properties are global to the interface application. Some new properties introduced at this level are listed below.

* Application Startup Script -- non-op/op mode transition
* Application Shutdown Script -- op/non-op mode transition
* Enforce Script -- enforces (operational) state properties
* Project window visibility flag

A set of App_States comprise the App_Model, along with an association with ArcView's Application object. Associated scripts provide control for application state transitions, and enforcement of current state properties. The script module which packages this functionality is the heart of the system, upon which all other script modules are dependent.

Data Model:

High-Level Views and Data Independence

The second component of the Application Model is the Data Model. It is an incarnation of the Domain Model defined by Rumbaugh (1994b), but is treated separately because of the specialized role it may assume in GIS applications. Here the term is used in a more general sense than is usually connoted in the database community. Its use is closer to the notion of a 'high-level' view or database schema (which may accommodate alternative data structuring methods). The schema employed by the organization or agency is used to organize and reinforce an understanding of its role, purpose and related mandates. Hence for an agency that supports a parcel-based Land Records system, data that is used for spatial referencing and Parcel Ownership is central to a schema which organizes a view of the database. Other data themes tend to play a supportive role relative to primary functions and operations, and may even be represented as attributes to the parcel. As the agency begins support additional roles such as 911 emergency response or update of Census Bureau TIGER data, the schema may serve to support an integrated data type, such as parcels with street centerlines, addresses, and hydrography.

In implementation the Data Model can be thought of as a specialized spatial data manager for GIS applications. Whether it is the top-level of a DBMS or explicitly embedded in a separate application, it comprises an interface -- another layer of distinct software -- between the GIS application and its database. It may also provide access to metadata documents, which in turn might be used to constrain the use of spatial data. With increased use of spatial data in a distributed computing environment, the Data Model component has many other potential uses.

Other functions of the Data Model are more pragmatic. By introducing a data manager, an ArcView application can achieve a certain degree of independence from its database. The data manager can defer data object instantiation to a time when it is needed, which in ArcView has certain performance advantages. Since the Data Model may provide for 'higher-level' views of spatial data, relative to those available in ArcView, the definition of high-level data types is required. Such data types can be used for implementing a data content standard (within certain constraints). They may also be used to overcome deficiencies in ArcView performance by transforming data into forms that are more efficient to process.

Thematic Data Types: In this project, the Data Model may be thought to encompass the 'common' data elements across situations likely to be encountered, or it may also be based upon some agreed-upon content standard. It specifies the thematic data types required by the application. Participating counties will use local coordinate systems for spatial reference, and each county will be responsible for accompanying annotation and ArcView legend symbology.

* Tax Parcel Database (tabular)
* Parcel Coverages
* Local Roads, Street CL, Addresses
* Landuse, Zoning
* Minor Civil Divisions
* Soils, Hydrology, Wetlands, Watersheds
* PLSS Towns and Sections
* Base Mapping
* Data Layer Symbology and Annotation for the above

Model Development: The remainder of this section examines the abstract data types managed by the Data Model. A review of the client data sets revealed a range of strategies and feature types used to represent a particular data theme. It was determined that certain transformations would be required as part of the processing of the interface database. ArcView/Avenue is capable of handling other types of transformations on-the-fly, or as part of interface initialization procedures.

Figure 4: OM Diagram for the Data Model

Aggregation of Themes into Layers (App_Layer): As in the Operations Model discussed above, the Data Model was conceptualized in terms of OM diagrams. The Data Model component is embedded under the data type "App_View", at the top of the OM diagram in figure 4. The App_View data type was discussed above, but in more detail we can see an association of an ArcView View document, and one or more instances of an "App_Layer" type (not to be confused with Library Layers).
The App_Layer type specifies an aggregation of one or more App_Themes (see below). Such aggregations are modeled in ArcView List objects. This type of aggregation is a simple and useful technique for transforming fundamentally different data representations into a single 'standard' recognized by an application.
For instance, a single interface-based request for display of a hydrologic data layer may add themes of several feature types, including several classes of annotation, lines for streams, and polygons for lakes. In another example, one county may employ ortho-photography for purposes of base mapping, while another county might use planimetric data supplemented with various annotation layers. By using this technique and with nominal revision to the application, both local databases can be accommodated by the same interface.

Data Dictionary (App_Theme): Moving down the hierarchy of the OM diagram in figure 4, the "App_Theme" data type is encountered next. An App_Theme is an abstract type which defines the properties common among several sub-types, some of which are discussed below. The sub-types ultimately reference at least one of the standard ArcView Theme classes. The common properties define a Data Dictionary for a theme. Properties include defaults for data source path, scale thresholds for visibility, standard legend symbology, classification field, geocoding parameters, metadata source, and so forth. The various App-Theme sub-types are flagged as well. Only one branch of this hierarchy is examined here.

Figure 5: OM Diagram for the TILE_Theme and MAT_Theme

Tiled Spatial Data (TILE_Theme): Some spatial data is so dense in feature representation that to create a single shape file would be inconvenient for handling and result in poor ArcView performance. One relatively 'low-tech' response to the problem is to partition the overall extent into manageable units called TILES. It was necessary to handle tiled data types for themes derived from parcel coverages, as well as other data such as soils coverages. All the county participants tiled such data on the basis of PLSS Townships.

The data type "TILE_Theme" was designed to handle such cases (figure 5). TILE_Theme is associated with an Ftab index and functionality that dynamically tiles a View extent. Any image or feature-based theme may be tiled. The auto-tiling function is also coordinated with pan/zoom tools and general query functionality. TILE_Theme will accommodate either shape files or coverages, and may point to an ArcInfo Librarian directory structure. Non-Librarian files require a directory structure which emulates that of Librarian.

Figure 6: Master Attribute Theme

Master Attribute Theme (MAT_Theme): One of the primary goals of this project was to integrate the Tax Parcel Tables with the spatial representations of Land Ownership Parcels. Such integration is recent in the local Land Records business. The Tax Tables are typically maintained by a tax assessment or other revenue function of the state, while the Ownership Parcels are usually maintained by a Land Information office. Moreover, such data sets are large by most standards, and the financial/technical resources available to participating county governments precluded implementation of an integrated ArcView/SDE/Oracle solution.

The data type "MAT_Theme" was designed for such data integration. It consists of two data sets -- a tiled spatial coverage comprised of polygon features, and a point coverage derived from a tabular database. The MAT_Theme type is a sub-type of TILE_Theme and provides an alternative way of organizing the attributes of tiled spatial data (figure 5). It was found that certain conveniences and query efficiencies were gained by keeping the attribute data separate from the spatial coverages. The attribute tables may be converted to point coverages and related to the spatial database using geometric methods and/or spatial joins (figure 6).

The method responds to inefficiencies of querying large tiled data sets in ArcView. A single table can be sorted or indexed, then searched using binary methods. This leads to search times that are much more efficient, when compared to similar operations based upon sequential processing of tiled PATs. It relies on the use of Avenue theme-on-theme query to implement point-in-polygon and other spatial relations. This is required in order to coordinate record selections between the two data sets. Any use of such Avenue 'batch' requests will be much more efficient than replicating the same operation in Avenue code. Despite the additional coordination and code overhead, the method displays greatly enhanced query times when used over large-scale extents.

The MAT_Theme data type supports table attribute query and spatial query across tiled extents (figure 6). For spatial query, the selection operation is performed on the tiled-MAT component (ie, parcel coverages), and the selection transferred to the point-MAT component (ie, parcel attributes) using a polygon-contains-point relation. For attribute query, the selection operation is performed on the point-MAT, with the selection transferred to the tiled-MAT using a point-in-polygon relation.

The MAT_Theme type requires its data to be structured in a particular form. In the ArcView application environment this means that the data must be pre-processed. Processing requires a key field (with unique keys) common to the spatial and attribute data sets. For this application the Parcel ID (PIN) was used. The steps for such processing are listed below and may be performed in ArcInfo or ArcView.

(1) Generate parcel centroids, and store in tax parcel table, or component thereof
(2) Regionalize the parcel features into complex polygons (if needed)
(3) Combine multiple Tax Parcel Table components into a single table (if needed)
(4) Convert the resulting table attributes into a point coverage

To summarize, the MAT_Theme data type became the heart of the application due to its data integration role. Its design responds largely to contemporary 'low-tech' practices in spatial data handling -- partly to the computational complexity inherent to query operations on large tiled data sets, and partly due to limitations in ArcView performance. The advantages of the data type in this application are listed below.

(1) Integration of traditional IT database with Land Records spatial database
(2) Accommodates data set tiling
(3) Enhanced query performance, especially at county-wide (large) scales
(4) Enables use of custom indexes and search methods
(5) Allows for convenient report generation
(6) A generic method which may be applied to any thematic type

Application Model Specification

and Viewing Interface

The third component of the GIS Application Model is a means of model specification and viewing of model structure and organization. Recall that the pseudo-objects instantiated by the model are aggregations of object references plus additional attribute values. The aggregation is represented internally as a tuple (figure 7). Such organization lends itself to use of ArcView Table documents as devices for model specification. They are also useful, but not ideal, for viewing the organization of a model. While iconic representations are generally superior for such purposes, the table metaphor has become fairly ingrained in the computer-using public mind. Such Property Tables are easy to implement in Avenue, though they are unable to represent explicit relationships between model entities.

Figure 7: Model Specification

Property Table Creation: The new data types defined in the Operations and Data model are represented using ArcView Lists. Such definitions are stored in an internal Dictionary. Generally, any 'pseudo-object' created from such definitions corresponds to a single tuple, also in list form. Creation of a Property Table input device is straightforward, involving the simple projection of List items to a field structure. Item types which are not compatible with the resulting field structure are not projected, or if they are projected then the corresponding field may be simply hidden from the user. Any spurious input in such fields is ignored when the table is converted back into its internal representation.

Input Checking and Compilation: The user/developer uses standard ArcView functionality to edit these property tables. Once all entries are complete, the table values are read back into the internal list format. The model must be 'compiled' before the interface becomes operational, which proceeds in two passes. The first pass checks the internal consistency of the model representation. The second pass checks all references to external data sources, such as legal file names and other entities such as field names.

Having two phases of checking enables the developer to construct a basic model without worrying about explicit references to external data sources. The model can then be transferred to a different database environment and configured to a local data set. If an error is found, the compiler opens the appropriate input table, selects the record which contains the offending input, and displays an error message.

Upon successful compilation an internal representation of the model is constructed and the interface application becomes operational. One payoff of the Application Modeling approach is some degree of independence of the application from its database. This is because the model mediates the creation of ArcView objects. Several options are incorporated which control just how and when an ArcView Theme or Table is instantiated. In general it is useful to defer instantiation until a data object is needed. If instantiated objects are never 'saved' with the ArcView project (due to high-level control), then one can avoid the inevitable 'training' phase invoked during ArcView's project startup (if ArcView cannot find a previously created data object). However, this strategy involves certain tradeoffs in performance of the interface application.

Viewing and Specifying Model Organization: Because the Application Model aggregates pre-defined ArcView classes and new attributes, the Table representations are necessarily inter-related according to primary-foreign key relationships. Such relationships are implied by the various aggregations. For example, appendix - figure 13 shows the Property Tables for the pseudo-classes App_State, App_View, and App_Layer. Each record in the table nominally represents a pseudo-object. Certain key item values in one table 'point' to record entries in another table.

Specifically, the field named "Visible Doc Aliai" in the "State Properties" table contains entries for the Object IDs of all ArcView documents which are visible at each application state. In this case the OIDs are document alias names. Tracing such references to the "View Properties" table, one can find a key field named "Alias" which contains these values. Such relationships provide access to other properties. For instance, each entry in the "View Properties" table contains the name of the script which calculates the screen rectangle used to tile the document, and so forth.

To carry the example even further, there is another field in the "View Properties" table named "Layer Aliai" which lists the alias names of App_Layer data objects that are to present in a view at a particular interface state. The "Layer Properties" Table has record entries for each of these alias names, which are in turn mapped to various theme alias names and associated data sources.

Conclusions

OOP methodologies are powerful tool for conceptualizing software organization. They may be extended to incorporate emerging concerns in GIS application development. This project takes a stab at integrating basic modeling functionality into desktop GIS. It incorporates an Operations Model that can be used to coordinate the behavior of Application Objects (Rumbaugh 1993). It uses a Data Model to represent new data types and logical views of data that are 'higher-level' than those available in ArcView. It includes provisions for model specification and viewing, which allows the model to be opened-up for public scrutiny and review. In the case of this project, such provisions also have a number of pragmatic benefits related to data independence, model revision, application portability and re-use.

The approach undoubtedly has general application to domain-specific GIS modeling efforts, but still requires further development. Despite the promotional efforts of the software industry, the question remains as to the effectiveness of OOP methods in responding to the social context of application development, including that of modeling for policy debate (see Dutton and Kraemer 1985, King and Kraemer 1993). In particular, appropriate procedures and representations are needed for communicating model concepts. As graphic languages, the OM diagrams of Rumbaugh et al. (1991) and Entity-Relationship (ER) diagrams of Chen (1976) are precise enough to enable constructive software and database development. Because they are designed for this, they are too complicated for use in a public setting. Simpler representations are more appropriate for addressing issues surrounding a policy debate. Perhaps a multi-level approach which employs different languages for different purposes is a more appropriate approach.

Other implementation problems can be traced to ArcView/Avenue performance and limitations as a development environment. In particular, Avenue lacks the extensibility required to do such work efficiently. A fair amount of programming discipline and a significant code infrastructure is required to implement the ideas discussed in this paper. Certain strategies may be employed to minimize the additional code overhead required by the technique. Moreover, to handle a large project in the ArcView/Avenue, the developer must implement a suitable development environment. Finally, the performance of ArcView suggests that this approach is best implemented on a high-end Pentium, though this also depends upon the particulars of system configuration and the complexity of the Application Model. Such concerns place limitations on the scope of application development that is possible using ArcView. On the other hand, technology marches onward. Emerging industry standards such as OLE2/COM and CORBA suggest that a distributed object framework for integrating the required functionality is close-at-hand.

Acknowledgments

John Amundson, Dane County GIS Manager, WI
Andy Erdman, Jefferson County LIO, WI
Chuck Kell, Portage County LIO, WI
Mike Romportl, Oneida County LIO, WI
Chris Lucas, Shawano County LIO, WI
Kevin Struck, Ed Harvey, Sheboygan County LIO, WI
John McLaughlin, DuPage County LIO, IL
Don Ferber, University of Wisconsin - Madison, WI
Pete Thum, Bill Holland, GeoAnalytics Inc - Madison, WI

Appendix

Tax Parcel Interface Screens

Figure 8: Introductory Orientation Screen (text reference)

Figure 9: Choose Data Layer/Attribute Screen (text reference)

Figure 10: Navigate Screen (text reference)

Figure 11: Parcel Query Screen (text reference)

Figure 12: Map Output Screen (text reference)

Figure 13: Tables for Model Specification and Viewing (text reference)

References

Checkland, P. 1981. Systems Thinking, Systems Practice. Chicester: John Wiley and Sons.

Chen, P. 1976. The Entity-Relationship Model - Towards a Unified View of Data. ACM Transactions on Database Systems, 1(1): 9-36.

King, J.L. and Kraemer, K.L. 1993. Models, Facts, and the Policy Process: The Political Ecology of Estimated Truth. Environmental Modeling with GIS. Michael F. Goodchild, Bradley O. Parks, Louis T. Steyaert eds, pp. 353-362.

Dutton, W.H. and Kraemer, K.L. 1985. Modeling as Negotiating: The Political Dynamics of Computer Models in the Policy Process. Ablex, N.J.

Nyerges, T.L. 1993. Understanding the Scope of GIS: Its Relationship To Environmental Modeling. Environmental Modeling with GIS. Michael F. Goodchild, Bradley O. Parks, Louis T. Steyaert eds, pp. 75-93.

Maxwell, T. and Costanza, R. 1995. Distributed Modular Spatial Ecosystem Modeling. International Journal of Computer Simulation: Special Issue on Advanced Simulation Methodologies, 5(3).

Richmond, B. et al. 1996. STELLA Research Technical Documentation. High Performance Systems, Inc., Hanover, NH.

Roberts, N. et al. 1983. Introduction to Computer Simulation: A System Dynamics Approach, Addison-Wesley, Reading.

Rumbaugh, J. et al. 1991. Object-Oriented Modeling and Design, Prentice Hall, Englewood Cliffs, N.J.

Rumbaugh, J. 1993. How to Find and Use Application Objects. Journal of Object-Oriented Programming, 6(6).

Rumbaugh, J. 1994a. How the Object Model Changes During Development. Journal of Object-Oriented Programming, 7(3).

Rumbaugh, J. 1994b. Using Use Cases to Capture Requirements. Journal of Object-Oriented Programming, 7(9).

Author Information

Steve Allenstein
GIS Consultant
Land Information and Computer Graphics Facility (LICGF)
University of Wisconsin - Madison
B102 Steenbock Library, 550 Babcock Drive
Madison, WI 53706

phone: (608) 263-5534
fax: (608) 262-2500

email: slallens@facstaff.wisc.edu