ArcInfo 8.0 Geodatabase Models for NIMA
Specifications
Ross Paulson and Gary Fickling
Date
6.1.2000
Abstract
The Digital Topographic Support System (DTSS) of the Combat Terrain Information Systems (CTIS) program currently utilizes ArcInfo 7.2.1 for Solaris to exploit National Imagery and Mapping Agency (NIMA) Standard Linear Format (SLF) and Vector Product Format (VPF) feature data. DTSS is migrating to ArcInfo 8 for NT, and it will model geodatabase objects and associated behavior rules for VPF products. The ArcInfo geodatabase data model facilitates complex data editing and validation. This presentation will focus on the process of modeling NIMA data in the geodatabase data model.
Introduction
This paper details the process by which the DTSS has modeled NIMA data in the geodatabase data model. This object-oriented data model and its many advanced features play a key role in the success of DTSS. Inheritance, reusability, class behavior control, subtypes, complex editing and other useful properties associated with object-oriented design contribute to the robustness and extensibility that enable DTSS to handle multiple data specifications.
The Need for a New Data Model
The
geodatabase data model serves as the foundation for the entire vector data exploitation
system within DTSS. This model is
employed when the user imports data into the system to create products to
support various Tactical Decision Aids (TDAs).
TDAs include mobility, intervisiblity, hydrology, weather, and other
products. Having a structured data
model is vital to the system, allowing the user to control what and where
attribute values are entered. This is a
benefit when editing the data. When
characteristics of a feature are added or changed, the user can only define
them based on the limitations of the particular data model, which is different
for each product. DTSS currently
supports four NIMA vector products: Interim Terrain Data (ITD) in SLF and
Vector Product ITD (VITD), Foundation Feature Data (FFD), and Digital
Topographic Data (DTOP) in VPF.
Data Model Design
The first data model created by TASC was for NIMA VITD. The tool used to create the data model was VISIO 2000. TASC successfully leveraged the modeling tools associated with this software. The software facilitates data model design in a clear and organized manner.
An incremental approach for creating the VITD data model was implemented. Individual layers were created, reviewed, and revised in isolation before being integrated into the larger model. Only when the current layer was run cleanly, exported properly, and working in ArcInfo as a standalone geodatabase did we move to the next layer.
The VITD transportation layer was selected as the first development target. Following the NIMA Performance Specification for Vector Product Interim Terrain Data (VITD) (MIL-PRF-89040A), TASC modified an Esri-supplied FFD transportation geodatabase data model into a format appropriate for the VITD transportation layer. The existing Esri FFD data model provided a natural point of departure from which to explore the intricacies of the model and the representational language. The experience of adapting the Esri transportation model to that of the VITD proved to be a valuable learning tool which was leveraged throughout the remainder of the development process.
The
overall structure of the transportation layer includes seven feature classes:
one area feature, four complexEdgeFeatures, and two SimpleJunctionFeatures
representing area, lines, and nodes respectively. Each of the feature classes contains one or more subclasses, with
a total of twenty-two subclasses for the entire set. The NIMA specification spelled out the organization of the model
in the following schema tables.
Area Feature Class: feature
TRNAREA (transportation area)
Line Feature Classes: complexEdgeFeatures
TRBLINE (transportation bridge line)
TRDLINE (transportation road line)
TRNLINE (transportation line)
TRRLINE(transportation railroad line)
Node Feature Classes: SimpleJunctionFeatures
TRBDGND (transportation bridge node)
TRNNODE (transportation node)
Each
of these schema tables represents a feature class with a list of attribute
domains. Each feature class was
individually coded with its particular list of attribute domains. The TRRLINE
is a good example of how a feature class is laid out.
Figure 1.0. TRRLINE is a good example of a set of
subtypes from that feature class.
Within
this feature class, there are three features: Railroad, Railroad
Siding/Railroad Spur and Railroad Yard/Marshalling Yard, as shown above. Each of these features has the same list of
attribute domains, since attributes and attribute values are defined at the
feature class level. This is where
utilizing object-oriented modeling allows us valuable flexibility and
functionality. There are seven
attributes in this class abbreviated with the three-letter codes shown below:
·
CTL - Cumulative Track length
·
EXS - Existence Category
·
FCO - Feature Configuration
·
LEN - Length/Diameter (meters)
·
RRA - Railroad Power Source
·
RRC - Railroad Categories
·
RSA - Railroad Spur/Siding Attribute
Each
attribute contains a set of numbers representing its possible values. The data model has two types of domains:
discrete and continuous. The EXS
attribute, for example, is a discrete or coded value domain because its
attributes are constrained to a list of predefined values. Figure 2.0
illustrates this notion, showing the possible coded values of #0, # 1, #5, or
#8 for the EXS category. All other
values are prohibited. Alternately, the
continuous or range domains are restricted only at their upper and lower
bounds. Figure 3.0 shows the CTL
attribute, the values of which can be any integer from 0 to 99,998 meters
Figure 2.0. Existence Category attribute description.
Figure 3.0. Cumulative Track Length attribute description.
Attributes
are associated with features using the Feature Code (FCODE) identifier as
defined by the Feature Attribute Coding Catalogue (FACC). In both of the above figures, the FCODE
applicable to a particular attribute/attribute value combination is listed on
the far right. While a feature class
defines a set of possible attributes and attribute values for one or more
features, certain attributes and attribute values are often specific to only a
subset of features within a given feature class. Inapplicable attributes for a
given feature are assigned an attribute value of Null. In the case of the EXS
example, four coded attribute values are available. Figures 4.1 and 4.2 represent adaptations of the attribute
description detailed in Figure 2.0.
Figure 4.1. exs_trn shows one of three EXS coded
value domains:
Figure
4.1 shows that the attribute value for dismantled
is not coded. This is because some of
the features, such as Railroad Siding/Spur and Railroad Yard/Marshalling Yard,
do not employ the dismantled value in
their EXS domain. Instead, they use exs_trn, which
is coded to meet their more restricted needs.
Figure 4.2. exs_trn_dismantled shows EXS coded value domain with the dismantled value present:
Figure 4.3. exs_trn_abandoned is another exs domain
needed for another EXS attribute for an Area feature. 
The railroad feature uses exs_trn_dismantled,
while the other two features use exs_trn. The
third domain represented in Figure 4.3 is used for a feature in a different
feature class. Runway_Area is another feature in the Area feature class, not shown
in Figure 1.0, which requires an “Abandoned/Disused” value for its Existence
Category attribute.
All
three of these domains are used throughout the model. For the purpose of reusability, the number of domains was limited
by creating those that applied for multiple features. Depending on the attribute values that a feature requires, one of
these domains should suffice.
Figure
5.0. wid_runway is an example of a
range domain
Figure 5.0 shows how the information shown in Figure 3.0 (a range domain) is coded. Range domains are simply coded with a MinValue and a MaxValue. The unknown value of zero is included in the MinValue. This allows the user to enter a value instead of selecting a value when editing. If the attribute uses a coded value, the user would select one of the values provided. Here the values are set 0 to 99998; when entering values during editing, they cannot exceed the MaxValue limit.
In
Figure 1.0 some of the attributes are defaulted to null. This is because not
all attributes apply to all features in the feature class. A special null coded value domain was
created to accommodate this. Its
default value is –2147483647. Attributes
that do apply default to 0, indicating that their value is unknown. When data is imported into the system, these
defaults are replaced by actual values.
After import, users have the ability to add or correct the data as
necessary. The user can only enter or
select the defined values that are previously encoded in the data model.
An
example above can be illustrated when the user creates a new railroad
line. After he has digitized the entity
into the data, he must populate the attribute values. In this feature class there are seven attributes to be
assigned. Using the ArcMap editing GUI,
the user can assign values to attributes in two ways. For range domains, he can enter a value from a set minimum to a
designated maximum. If the attribute is
not a range but a coded value domain, he can use the pull-down menu to select a
designated value. This is the key to
controlling data integrity, since only the allowable values for every feature
are modelled. By creating feature classes with default attribute values,
features can inherit these rules for their use.
Working with the Geodatabase
When
the data model is exported out of VISIO, a data repository is created. To create a personal geodatabase in
ArcCatalog, the user goes to a folder location and right clicks, selects new,
and chooses “Personal Geodatabase”. He
names it and creates a “Feature Data Set” in the same manner, then fills in the
name of the feature data set and enters the geographic coordinate information. Once that is done, he must use the schema
wizard, created by Esri, to import the database. This schema wizard takes the data repository and creates the
geodatabase from the various feature classes, features, ranges, and coded value
domains as well as all of the other entities that have been modeled. Currently this is done semi-automatically
using the schema wizard, but in the future, full automation should be possible.
There
are some aspects of this process that need further refinement before a fully
automated system can be created. The
wizard steps the modeler through several windows to finalize the specifications
for each feature class. For example,
the model creator must manually enter user-friendly aliases for each attribute
code during the import process. To
avoid this, one static geodatabase is created with all of the aliases for the
attribute codes filled in, along with all of the other manual operations
associated with creating geodatabases.
The coordinate system will be set to the entire world in order that
everything will be covered.
The
first stage of creating a TDA product is the import process. The system will recognize the NIMA product
and will use the proper geodatabase template.
The data will filter through the importer and generate the appropriate
entities. The geodatabase will have
every possible data entity coded and available even if it does not exist in
that particular data set. This is
required for editing and adding information to the data.
The Benefits of Object-Oriented Modeling
DTSS
benefits greatly from an organized object-oriented model. The current DTSS UNIX data editing software,
Terrain Update Module (TUM), uses a data model that is not
object-oriented. Instead,
it has sets of text files that define all the attribute feature classes and
codes for particular layer types.
Object-oriented modeling allows the DTSS software to evolve beyond the
limitations inherent in this approach, taking advantage of inheritance for
reusing and constraining TDAs. An
object-oriented database provides a great deal of flexibility for dealing with
terrain data.
NIMA
produces many different types of terrain data products with varying
resolutions, as well as different sets of features and attributes. These data products provide different
capabilities for analysis. The goal for the future is to develop an inheritance
hierarchy that allows the DTSS software to work with any appropriate data
product without regard to the details of its structure and feature/attribute
schema. For example, all data models powerful enough to run a mobility analysis
will inherit from the same parent. As
new data products are added to the system inventory, DTSS will be able to
exploit them without requiring drastic software changes.
Conclusions
Object-oriented data models provide a natural means of representing the complex relationships inherent to geospatial modeling. As DTSS evolves, the goal is to maintain the generality and flexibility that the object-oriented paradigm of ArcInfo 8 has affords in order to continue to accommodate changing and complex data formats.
Ross Paulson
MTS, Litton TASC, Inc.
4801 Stonecroft Blvd.
Chantilly, VA 20151-3822
Fax (703) 793-3700 x2712