Status Report on ArcGIS Data Models

GIS data management, by its very nature, is distributed since it fundamentally involves the integration of data from multiple sources. To address the need to build and share geographic information, Esri has been actively involved with our user community in the development of common content standards (i.e., common data model designs). The series of ArcGIS data models provide a common design framework for key layers of GIS information.

Our objective to develop a GIS design methodology for ArcGIS data models that could be applied by any GIS practitioner (not only Esri software users) resulted in a number of design goals. Foremost, each data model has to be more than a conceptual framework. It has to support real GIS work including the update and maintenance of data content as well as the derivation of specific information products.

Another key design goal is that each design must be open, multipurpose, and standards based. We built each design on appropriate implementations of the Open GIS Consortium (OGC) simple features specification in which the spatial data is managed in database management system (DBMS) tables.

Data models are designed to be usable in practical application by a wide range of users. We want to ensure that these designs are easy to understand and implement. Each data model must readily support migration from existing file-based systems regardless if they were based on coverages, shapefiles, CAD files, etc. And finally, each design has to be extensible, flexible, and easily adaptable to meet each organization's requirements.

Design Methodology

The ArcGIS census data model consists of five thematic layers.

Evidence in the past decade has shown that traditional GIS database design procedures are sound and need not change drastically with the migration of GIS data management into a DBMS. While object-oriented design tools are useful when used appropriately, fundamental GIS design principles and methods still apply.

Fundamentally, a GIS database design is built on the concept of thematic layers of information. First, determine the set of GIS themes to address your particular application and information requirements. Then define each layer in more detail. The characterization of each thematic layer will result in a specification of standard GIS data types such as feature classes, tables, relationships, raster data sets, and so forth.

GIS Database Design Steps

1. Identify the key thematic layers.
2. Specify the scale ranges for data use and spatial representations for each scale range.
3. Decompose each representation into data sets: feature classes, raster data sets, tables, etc.
4. Identify the attribute fields for each.
5. Specify any valid values and relationships.
6. Identify subtypes for your feature classes.
7. Define spatial relationships, integrity rules, and behavior (i.e., topologies and networks).
8. Propose a geodatabase design.
9. Implement, prototype, review, and refine your design.
10. Design work flows for building and maintaining each layer.
11. Document your design using appropriate methods (e.g., data dictionary, database schema, rule bases, UML diagrams).

Note the first seven steps are the same across any GIS. Some differences can arise in the last four steps involving physical implementation and prototyping. In our case, specific decisions were made for the physical design based on geodatabase capabilities and ArcGIS.

What's in a GIS Database Design?

GIS has the ability to organize information into a series of layers that can be integrated using geographic location. At a fundamental level, each GIS database includes the series of thematic layers used to represent and answer questions about a particular problem set such as hydrology, tax parcel management, transportation, etc. For each theme, specifications for the contents in the physical database are also described. These include how the geographic features are to be represented (e.g., point, line, polygon, raster), how the data is organized (into feature classes, attributes, relationships, etc.), and what are the database integrity rules and GIS behaviors (e.g., topologies and network definitions).

At the simplest level, a specific geodatabase design will include a specification for a number of feature classes, raster data sets, and other tables plus a series of relationships among the tables. Each feature class is managed as a simple table. Feature data sets contain a set of feature classes that share common spatial relationships. In each of the ArcGIS data models, you'll see representations for simple feature classes plus topologies that are used to implement integrity rules and behavior among these integrated feature classes.

The information types in a GIS database include all the common relational data types (e.g., tables, relationships) plus GIS-specific content. All the ArcGIS data model designs include the following:

• Feature classes--Collections of points, lines, polygons, or annotation (map text) managed as feature tables. Related feature classes (i.e., those that participate in a topology or a network) are managed as a collection in feature data sets.
• Raster data sets--Individual images or multi-tiled rasters managed as raster tables.
• Tables--A collection of rows or records containing fields or columns used to represent nongraphic objects (e.g., parcel owners)
• Relationships--A mechanism to select records from one table (or feature class) and find records in a corresponding table (or feature class).
• Domains--A list (or a range) of valid values for a column.
• Subtypes--A classification of a feature class into subgroups, each having its own integrity rules and GIS behaviors (e.g., road class in a streets feature class).
• Spatial relationships--As defined by topologies and networks. A topology design is a rule base for how features in a given feature class share geometry with other features (parcels cannot overlap) or between multiple feature classes (lot lines must be covered by parcel polygons). You can read about topologies implemented in the new ArcGIS 8.3 release in the article "ArcGIS 8.3 Brings Topology to the Geodatabase" in the Summer 2002 ArcNews.
• Metadata--Documentation about each element in the database.

A geodatabase design includes the specification for each of these (and other) information types as they apply to particular applications (e.g., parcel management, transportation, or hydrology).

Sharing the Results

In conjunction with the release of ArcGIS 8.3 this fall, we will begin to share and publish the results of these design efforts in a number of ways:

Three design alternatives could be used to model condominiums: (1) as a table with one record for each unit; (2) as overlapping polygons for each floor; or (3) using relationships between polygons.

• In a series of books and publications, Arc Hydro, GIS for Water Resources, is one new book that deserves particular recognition. Based on good work by the user community and then compiled and edited by Dr. David Maidment, Arc Hydro, GIS for Water Resources explains in detail the GIS representation of a science-based hydrological information system and the resulting geodatabase model.
• General versions of these designs will be shared across the broader GIS user community. Because our design efforts are standards based, fundamental parts of each design are deployable in other GISs.

For more information, including copies of data model design posters, example data sets, downloadable schemas, and other information, visit the Esri Online Support Center at support.esri.com. Select the Data Models link under the expandable ArcGIS Desktop link on the left side of the page or visit www.esri.com/arcgisdatamodels.