ArcInfo 8.0 Geodatabase Models for Analytical Products

ArcInfo 8.0 Geodatabase Models for Analytical Products
Ross Paulson
6.22.2001

Abstract

The Combat Terrain Information Systems (CTIS) program is modeling geodatabases for analytical products for the Digital Topographic Support System (DTSS). DTSS now employs data models when importing and manipulating its various data types. In addition to models for ingesting data, data models are created for the analysis products that DTSS generates. By utilizing such models for these analytic products, further analysis can be performed using the data query and topographic analysis functions offered by DTSS. Building on our repository of models for importing and using National Imagery and Mapping Agency (NIMA) Vector Product Format (VPF) data, DTSS has developed the data models for these analytical products. This presentation will describe the modeling of output data from DTSS in the geodatabase object format.

Introduction

Data modeling plays an important role in all software environments. Data models can be used as simple representations of reality. The focus of most geographic information systems (GIS) is on the spatial relationships between entities in the real world. Having an accurate and structured dataset is crucial to the validity of the complex spatial analysis that is to be performed by a GIS. In order to maintain the integrity of data imported and edited by the end user, strict controls must be imposed via the model.

DTSS uses several tightly structured data models for the various user/system interactions, which can be categorized into two main types: One type has been developed for importing data into the system. The other is for the organization of data output from custom DTSS Tactical Decision Aids (TDAs). Both model types hold the system together and give data a structured form.

ArcInfo 8 introduces the geodatabase data model. This provides several benefits to the database designer, most notably the ability to create object-oriented models. This allows for increased flexibility in the design of databases in many respects. From controlling behavior to setting attribute values, object-oriented databases provide more power than the previous ArcInfo coverage data model. DTSS’s two model types were designed to maximize the benefits that the geodatabase has to offer

Data Entry and Editing

To meet the requirements of strict data control, DTSS utilizes template geodatabases. To date, four data models have been developed for this purpose, which correspond to the following NIMA data types:

1. Interim Terrain Data (ITD)
2. Vector Interim Terrain Data (VITD)
3. Foundation Feature Data (FFD)
4. Digital Topographic Data (DTOP)

Each model is ultimately rendered into a template geodatabase. These models were built from the various NIMA specifications pertaining to each data type. The templates are designed to mimic the most fully specified possible structure of the data types so that when real data is imported into the database, every feature/attribute/value that the data contains will be accommodated by the model.

In addition to the fully implemented specification provided by the template geodatabases, the underlying models enforce data integrity by restricting the values that may be assigned to attributes. The template geodatabases make it very easy for the user to “value-add” to the data using the Editor function in ArcMap. The template restricts the features/attributes/values that can be added by the user to those allowable by the selected data type. The feature attribute graphical user interface (GUI) includes pull down menus that reflect data controls built into the underlying model.

Tactical Decision Aids

Besides data editing, DTSS has additional custom analytical capabilities. DTSS has a number of TDA products, which are used for producing beneficial information for the battlefield. For the purpose of this paper the Mobility TDA will be highlighted to show how DTSS models topographic data for output. The current custom mobility supports two data formats: VITD and ITD. Within the mobility TDA there are three components

1. Cross Country Mobility (CCM)
2. On-Road Mobility
3. Gap Crossing

The "engine" behind the mobility TDA is the North Atlantic Treaty Organization (NATO) Reference Mobility Model II (NRMM-II), developed by the US Army Waterways Experiment Station (WES). DTSS’s mobility application allows the user to enter parameters such as vehicle type, weather, and soil condition. Data is generated from the mobility algorithms and modeled so the user can view the output in ArcMap.

Cross Country Mobility

CCM computes off-road movement by selected military vehicles. Output from the CCM analysis is a polygonal structure. These polygon features are called terrain units and are generated from areas of similar soil, slope, and vegetation types. Each terrain unit has ten layers of information. These layers contain attributes for various speeds and reasons. All of this is coded in the data model. The output is a custom geodatabase. For CCM there is only one feature class, "feature_class_ccm_area".

Figure 1: feature_class_ccm_area



	Figure 1: feature_class_ccm_area
	TU_ID	Terrain unit identifier attribute.
	UP_SPD	Speed at which chosen vehicle can go uphill.
	UP_RSN	Reason for up hill speed.
	DOWN_SPD	Speed that vehicle can attain going downhill.
	DOWN_RSN	Reason for speed going downhill.
	XSLP_SPD	Speed at which vehicle can go across terrain.
	XSLP_RSN	Average speed that the vehicle can obtain in that terrain unit.
	AVG_SPD	Reason for that speed.
	CLT_VEH	Control Vehicle attribute is used when more than one type of vehicle is being calculated.

To compute the above values the mobility engine uses polygon information from soil, vegetation, and slope features. Using ArcMap each of the different attribute values can be mapped cartographically. For example, with "feature_class_ccm_area" the user can essentially make nine distinct maps from the same dataset. This is done by setting different color values that correspond to the attribute values in each of the terrain unit’s separate layers (not counting the "OBJECTID" attribute). In previous versions of ArcInfo each of the output displays would need to be rendered individually.

The two major attribute types in mobility concern speed and reason. Speeds represent how fast a vehicle can travel across selected terrain. A resulting speed of "NOGO" means that the vehicle has a great deal of resistance to travel. Numeric codes are generated that represent possible reasons. The example below describes a reason code of "-2".

	Figure 2: Reason Description A reason code of "-2" corresponds to a Soil. This is shown here within the Mobility_RSN domain, which is used throughout ccm_area.

On-Road Mobility

On-Road Mobility provides the speed and reason information for features such as roads, runways, and other transportation entities. Point, linear and polygonal data are generated from this mobility product. The domains for this component are generally the same as the CCM, but apply for all the transportation features in the dataset.

Gap Crossing

Gap crossing gives speeds and time information for crossing surface drainage features. Gap Crossing returns a series of codes that represent the suitability for travel across streams and other waterways. These codes are then written to the appropriate attribute field in the output geodatabase and the TDA is symbolized accordingly.

Mobility Attribute Domains

Attribute domains are included with the mobility geodatabase. Domains are essential for setting the values of the attributes. Coded value domains, shown in figure 4, and range domains, shown in figure 5, are examples of how attribute domains can be designed. Domains are useful not only for setting values, but also for displaying values with annotations. When the user is trying to define a feature in the data they can only enter (or select) allowable domain values.

Mobility Related Tables

Each of the three different mobility components use attribute information from the VITD and ITD stored in their own data models. These attribute values are needed to compute the terrain unit values for the various mobility components. Through the use of relationships and data joins the analyst can access the attribute values of the source data for any of the output terrain units. This provides the user with the ability to drill down in the output product to obtain the input features, attributes and values. This information can be used for additional analysis and/or to assess the validity of the output product. An example of this is shown below:

Figure 3 On_Road_Related_Table	Figure 4: onroad_rst This coded value domain identifies what pavement conditions are possible in the dataset.
	Figure 5:onroad_wid represents possible width values. This is an example of a range domain where the road width can only be between 0 and 300 meters.

The On_Road_Related_Table has all of the attributes needed by the mobility engine to create onroad values. The engine will extract certain values needed such as the road surface types. A combination of information goes into building the result.

Conclusion

The DTSS uses ArcInfo geodatabases to provide the user with a structured model of both input data and output products. Template geodatabases of input data facilitate data display, query, and editing. Output product geodatabases permit the user to run a single analysis and obtain many views of the resulting product. Integration of DTSS analysis models with ArcInfo geodatabases enhance battlefield understanding through the use of tactical decision aids.