by Joseph K. Berry

Berry & Associates // Spatial Information Systems, Inc.
2000 South College Avenue, Suite 300, Fort Collins, Colorado, USA 80525
Phone: (970) 490-2155 Fax: -2300 Email: joeb@cnr.colostate.edu

Abstract¹

Object-oriented technology is revolutionizing the computer industry and, by association, geographic information systems (GIS) technology. Three forms of objected-oriented technology are identified and their probable impacts on GIS are discussed. Although object-oriented user interfaces and programming systems are natural extensions, object-oriented data base management imposes discrete parceling and object linkages which do not conform to many resource and environmental applications.

____________________________________

At every turn, from researchers to salespersons, the buzz words "object-oriented" crop up. Mere mention of the concept greases the probability of funding and immediately places the competition on the defensive. But what does object-oriented really mean? Are there different types? Are there shades of object-oriented-ness? Can a system be "just a little" object-oriented? How can you tell? Like most over-used and under-grasped terms, object-oriented technology has a variety of near religious interpretations. In reality, however, there are just three basic forms: 1) Object-Oriented User Interfaces (OOUI) , 2) Object-Oriented Programming Systems (OOPS) and 3) Object-Oriented Data Base Management (OODBM).

OOUI uses "icons" in place of command lines and/or menu selections to launch repetitive procedures. It is what used to distinguish Apple computers and UNIX Motif, but with the advent of Windows ’95, OOUI’s have moved from "state-of-the-art" to commonplace. These graphical objects include all those things on the screen you that drag, drop, slide, toggle, push and click. On the "desktop" they include file folders, program shortcuts, a recycle bin and task bar. In a "dialog box" the basic objects include the check box, command button, radio (or option) button, slider bar and spinner button, in addition to the drop-down, edit and list boxes. When activated, these objects allow you to communicate with computers by point ‘n click, instead of type ‘n retype.

In addition to icons, OOUI’s use "glyphs," which are graphical objects controlled by programs to perform specific functions. The best examples of glyphs are in screen savers. The little dog, man or monster roaming across your screen which "destroys" it piece by piece is actually a "screen object" expression of a computer program. In a GIS/GPS package, the blinking dot or arrow depicting a vehicle’s movement utilize glyphs that roam across a registered GIS map, responding to real-time positioning. In advanced systems, such as air traffic control, the glyphs are often intelligent. When two graphical objects (airplanes) come within a specified distance of each other, they can blink rapidly or change color. In short, OOUI’s icons and glyphs encapsulate program parameters, control and linkages.

Just about every GIS out there uses an object-oriented user interface, which technically makes them all object-oriented. However, you might ask a few more questions to differentiate the nature and degree of "OO-ness." OOPS technology uses "widgets" in the development of computer code. Visual Basic and Delphi are examples of object-oriented programming systems. These packages allow a programmer to generate code by simply flowcharting a program’s logic. At each "drafting" step, a widget (flowcharting object) is moved into place and a dialog box is popped-up. Completion of the dialog box writes the appropriate code defining the step to a "command macro" file. Whereas an OOUI dialog box is independent, an OOPS dialog box is one in a linked set of commands depicted in the flowchart. Most modern GIS display at least a minimal level of OOPS-ness. By turning on the "command log" or "macro builder," a series of dialog box entries can be stored to a file, which in turn, can be rerun to repeat the processing. A robust OOPS, however, uses rigorous flowcharting structure, rules and mechanics to "graphically" assemble a computer application. From this perspective, OOPS is an effective programmer’s tool for developing fully structured computer programs.

From the end-user’s perspective, an OOPS flowchart is a succinct diagram of an application’s logic, as well as a link to the actual code. As GIS moves from descriptive geo-query applications to prescriptive modeling of complex spatial interactions, the communication of logic becomes increasingly important. Most end-users do not want to simply behold a colorful map rendering of a complex expression, such as an elk habitat map. Their visualization of a mapped result quickly turns to discussion of the assumptions and expressions used in its derivation. This focus becomes one of cognitive space, as much as geographic space. An OOPS flowchart provides a mechanism for both communicating and interacting with model logic. It provides a mechanism for a "humane GIS interface" which fully interacts with the "dynamic map pedigree" of a modeled map.² The next generation of GIS software will allow users to "interrogate and interact" with the logic of a GIS model by simply mouse-clicking on the widgets (boxes for maps and lines for processing steps) forming the model’s flowchart, or more aptly termed, the modeled map’s pedigree. If an end-user takes exception to the calibration or weighting of a step in the model (e.g., "Hey, slope isn’t that important to elk habitat"), then click on the disagreeable portions of the flowchart, change them, and rerun the model. In this manner, end-users can compare their "personalized" versions with those of others and readily assess the spatial impact of the different cognitive perspectives. The full incorporation of a robust OOPS makes the transition of GIS from simply a "data-painter" to an interactive "spatial spreadsheet."

The OODBM concept provides database procedures for establishing and relating spatial objects, more generally referred to as "data objects." Early DBM systems used "flat files," which were nothing more than long lists of data. The records, or data items, were fairly independent (usually just alpha-numerically sorted) and items in separate files were totally independent. With the advent of "relational databases," procedures were developed for robust internal referencing of data items, and more importantly, indexing among separate data sets. OODBM, the next evolutionary (or quite possibly, revolutionary) step, extends direct data indexing by establishing procedural rules that relate data. The rules are used to develop a new database structure that interconnects data entries and greatly facilitates data queries. They are a natural extension of current concerns for data standards and contemporary concepts of data dictionaries and metadata.

The OODBM rules fall into four categories: encapsulation, polymorphism, structure, and inheritance. Keep in mind that "object-oriented" data base management is actually a set of ideas about data organization, not software. It involves coupling of data and the processing procedures that act on it into a single package, or data object. In an OODBM system, this data/procedure bundle is handled as a single unit; whereas the data/procedure link in a traditional database system is handled by separate programs. It can be argued that traditional external programs are cumbersome, static and difficult to maintain, as they incrementally satisfy the current needs of an organization in a patchwork fashion. Horror stories abound about corporate databases that have as many versions as organizational departments (with 10 programmers struggling to keep each version afloat). The very real needs to minimize data redundancy and establish data consistency are the driving forces behind OODBM. Its application to GIS is simply one potential expression of the looming radical changes in data base technology.

Encapsulation is OODBM’s cornerstone concept. It refers to the bundling of the data elements and their processing for specific functions. In a GIS, for example, a map feature has a set of data elements (coordinates, unique identifier, thematic attributes). Also it can have a set of basic procedures (formally termed "methods") it recognizes and responds to, such as "calculate your dimensions." Whenever the data/procedure bundle is accessed, "its method is executed on its data elements." When the "calculate your dimensions" method is coupled with a polygonal feature, perimeter and area are returned; with a linear feature, length is returned; and, with a point feature, nothing is returned. If the database were extended to include 3-dimensional features, the same data/procedure bundle would work, and surface area and volume would be returned— an overhaul of the entire application code isn’t needed, just an update to the data object procedure.

The related concept of polymorphism refers to the fact that the same data/procedure bundle can have different results depending on the methods that are executed. In the "calculate your dimensions" example, different lines of code are activated depending on the type of map feature. The "hidden code" in the data/procedure bundle first checks the type of feature, then automatically calls the appropriate routine to calculate the results— the user simply applies the object to any feature and it sorts out the details.

The third category involves class structure as a means of organizing data objects. A "class" refers to a set of objects that are identical in form, but have different specific expressions, formally termed "instances." For example, a linear feature class might include such diverse instances as roads, streams, and utility lines. Each instance in a class can occur several times in the database (e.g., set of all roads) and a single database can contain several different instances of the same class (e.g., different types of roads). All of the instances, however, must share the common characteristics of the class and all must execute the set of procedures associated with the class.

Subclasses include all of the data characteristics and procedural methods of the parent class, augmented by some specifications of their own. For example, the linear feature class might include the subclass "vehicle transportation lines" with the extended data characteristic of "number of potholes." Whereas the general class procedure "calculate your dimensions" is valid for all linear feature instances, the subclass procedure of "calculate your potholes per mile" is invalid for subclasses of streams and utility lines. The hierarchical ordering embedded in class structure leads to the fourth rule of OODBM— subclass inheritance. It describes the condition that each subclass adheres to all the characteristics and procedures of the classes above them. Inheritance from parent classes can occur along a single path, resulting in an inheritance pattern similar to a tree branch. Or, it can occur along multiple paths involving any number of parent classes, resulting in complex pattern similar to a neural network. In general, complex structure/inheritance patterns embed more information and commonality in data objects which translates into tremendous gains in database performance. However, designing and implementing complex OODBM systems are extremely difficult and technical tasks.

Whereas object-oriented user interfaces and programming systems are actual or near realities in contemporary GIS software, object-oriented data base management is in its infancy. The OOBDM concept provides database procedures for establishing and relating data objects. In which the data and relationships are handled as a single unit. Within a GIS implementation, one "hit to disk" defines the where (locational attribute) and what (thematic attribute) of a map object, as well as its spatial context and linkages.

Such a system (if and when it is implemented) is well suited for organizing the spatial objects comprising a GIS. For example, we know that all airports must have a road connecting it to the highway network. In an OODBM, this connection is part of the data/procedure bundle. In a traditional "layered" GIS, you must overlay a map of all roads with a map of all municipal facilities, then select the airport/road coincidence to identify the connection. For years GIS users have preempted this process by constructing a single, huge "vector composite" which overlays all of the maps within a data base. Once constructed, a simple database command selects the "regions" (i.e., the "wee" polygons formed by the intersection of the multitude of lines) which meets any conceivable query. In a sense, the vector composite approach results in a OODBM-like system based on spatial coincidence. It generates a complete set of spatial objects with a direct data base link to their characteristics. The objects might not be readily recognizable (e.g., a timber stand will be "broken" into a multitude of pieces representing different soil and slope conditions not easily recognized in the field), but the GIS can quickly respond to any queries involving the coincidence of any map layers.

A major problem of both OOBDM and its related "vector composite" comes from their static and discrete nature. With OODBM, the specification of "all encompassing rules" is monumental. If only a few data items are used, this task is doable. However, within the sphere of a corporate GIS, the rule set geometrically expands and soon becomes unmanageable. The vector composite technique provides a mechanism to automatically generate at least one dimension for defining objects (spatial coincidence). However, each time a layer changes, a new composite must be generated. This can be an operational problem if there are a lot of layers that are frequently changing. New data base "patching" procedures (map feature-based) hold promise for generating the updates for just the areas affected, rather than repeated overlay of the entire set of layers.

Even if the "mechanics" of applying OODBM to GIS can be streamlined, problems still exist. First, the approach assumes all spatial objects are discrete—bounded by well-defined edges. While this might be the case for a house or a road, it’s a bit more "fuzzy" for soils (uncertainty) and barometric pressure (continuous gradient). In fact, the concept of a "fuzzy object" itself seems a contradiction. Secondly, many GIS applications involve cognitive expressions as much as they involve spatial objects. For example, areas of good elk habitat are not physical things, but interpretations of spatial relationships. Most often, these applications involve interactive processing as users run several "what if…" scenarios. From this perspective, habitat and sales maps are not composed of spatial objects as much they are iterative expressions of differing opinions and experience (spatial spreadsheet). For OODBM to work and garnish data accessing efficiencies, there must be universal agreement on the elements and paradigms used in establishing fixed data objects. In the broadest sense, the logic of a GIS model for habitat can be equated to an OODBM rule as it carries both the data (base map ingredients) and procedure (command macro recipe) defining something.

In fact, GIS applications are like banana-bread. If all cooks can agree on the recipe, then it can be stored as an object; however, if each cook insists on adding varying amounts of ingredients and/or entirely new ingredients, then banana-bread is not a "fully structured object." In these instances you need a cupboard full of directly accessible basic ingredients (i.e., base map layers). In short, object-oriented data management holds promise for increased efficiencies the handling of spatially discrete data (for descriptive inventory and mapping), while process-oriented GIS modeling systems (for prescriptive analysis and spatial reasoning) gives the user "a license to color outside the lines."

GIS technology is rapidly incorporating object-oriented user interfaces and programming system designs. These approaches are making the technology less complex and cumbersome for users at all levels. They are rapidly moving GIS from a "down-the-hall-on-the-right" centralized office to the user’s "desktop." The impact of object-oriented data base management, on the other hand, is less certain. In many respects the impact is the reverse, as it makes GIS more complex and cumbersome through the definition and imposition of its rules. In routine operations involving geo-query of pre-defined map objects, the efficiency gains are obvious. However, the planning and management of natural resources often involves dynamic analysis and modeling of spatial relationships expressed in continuous geographic space. In these instances, agreement on discrete map objects do not exist.

Similar to the 1970’s quest for "universal truth" in GIS data structures, a mixed solution is most likely. That earlier debate resulted in the recognition that both vector (discrete) and raster (continuous) data structures are necessary, as different applications benefit from the unique capabilities of each. Neither is best, and both are essential. When the dust settles from the current, near religious debate over data management approaches, the last word will likely find a place for both object-oriented (map objects used in descriptive inventory) and process-oriented (map layers used in prescriptive analysis). Neither is best, and both are essential.