EA
4. EVALUATION CRITERIA
Since there will be so many divergent groups
involved, NSDI requires more than what current spatial
data interchange standards offer. Therefore, needed was
a more detailed criteria than those suggested earlier
noticeably by the works of Lee and Coleman (1990)
and Kottman (1992). Therefore, an evaluation criteria
which examine a IF in terms of its data model,
implementation, and interchange environment have
been determined. In very general terms, what the
evaluation criteria looks for are generality and
extendibility in terms of data model, flexibility and
hardware independence implementationwise and
availability of services and tools which would
facilitate the development of translators and enable
efficient interchange of data considering interchange
environment.
4.1 Data Model Criteria
Data model type: Spatial data models may be either
"Feature-based" or "Record-based". IF's data model
should be general and flexible enough to enable
complete translations between as many different data
representations as possible.
Raster data: Raster data may be represented in many
different ways yielding various formats such as TIFF,
GIF, Landsat TM, SPOT, RLE, JPEG, PICT, TARGA and
many others. IF's data model should support various
raster representations.
Cartographic representation: Cartographic
representation of spatial information may take very
different forms. For instance, in one form river names
can follow the curvy shape of the river while in
another, names might be through straight lines only.
Similarly symbology, projections used in supplier and
client may be rather different. IF should allow various
cartographic representations.
Coordinates: IF should allow 1-, 2-, 3-, or 4-
dimensional coordinates with varying resolution, and
recognize different reference and projection systems.
Topology-geometry separation: If the client
has topology builders and its topological data structure
is rather different from that of the supplier then only
geometry may be transfered and topology can be
rebuilt in the client. However, topology may be used
to verify the geometry of the transfered data. Also, a
real-time application may prohibit topology building.
Therefore, IF should allow the transfer of topology or
geometry alone as well as both.
Complex objects: IF should enable direct
representation of complex objects. Complex objects
should be able to be treated as single units like simple
objects.
Object sharing: Object sharing is the capability
that an object can be shared by a number of other
objects. For instance, two polygons may refer to the
common boundary instead of each dupplicating it.
Object sharing is very valuable especially when
polygonal data is involved. Therefore, it is highly
desirable that IF's data model supports object sharing.
Metadata: Metadata is needed to determine the fitness of
the data for a specific application. Metadata can be specified
generally for the entire transfer data set or specially on the
basis of individual features. IF should allow both general
and special metadata specification in varying levels of
detail.
Feature-based interchange: Traditionally, spatial data
interchange has been practiced over the transfer of an entire
file corresponding to a map sheet, data set, or coverage.
Interoperability requires that interchange be performed at
the individual features level (Herring and Pammett, 1992),
which is called "feature-based interchange" here. Feature-
based data models would more readily offer feature-based
interchange support since their fundamental modelling unit
is a "feature".
Temporal data: Conventional GIS databases represent
only a one-time snapshot of the reality (Vrana, 1989). This
creates problems for the applications requiring temporal
data. "Temporal Topology" (Vrana, 1989; Edwards et al.,
1993; SAIF, 1994) has been proposed to handle the
incorporation of temporal data into GIS databases, which is
not a resolved issue yet. With the availability of temporal
data, queries like "when the building was established on this
parcel, what was the situation in the neighbouring ones?"
could be answered. It would be most unfortunate if both sides
of the interchange but the IF can handle temporal data.
Multimedia data: IF should support multimedia data
types such as voice.
Extendibility: It is widely accepted that a general spatial
data model which would meet any requirement is not viable
(Pequet and Marble, 1990). Unpredictability of the
requirements at the outset due to the diverse backgrounds and
ever evolving requirements of the spatial data users renders
the design of an all encompassing spatial data model very
difficult, if not impossible. That is, modifications or
extensions over time are unavoidable (Lee, 1990; Pascoe
and Penny, 1990). Nevertheless, changes have to be carried
out with mimimum side-effects. This is possible only if the
data model of IF is extendible. Extendibility 1s perhaps the
most important of the data model criteria for the fact that
even if an IF does not have sufficient provisions for some
criteria, required extensions can be done easily if it is
extendible.
4.0 Implementation criteria
Profiles: Since a general and flexible IF will necessarily
be rather complex, its implementation via a single large
translator would be inefficient and impractical: A large
translator would require a considerable development time
(Friesen et al, 1993), which may contradict the time
constraint of the project at hand and contain much more
than what is needed for specific data transfers. Therefore, it
is more practical to implement a general format through its
special purpose subsets called profiles (Fegeas et al., 1992;
Friesen et al., 1993). For instance, for an IF capable of
handling both vector and raster data, a vector profile can be
defined for just vector data. Profiles are also useful for
harmonizing general and specific IFs.
62
International Archives of Photogrammetry and Remote Sensing. Vol. XXXI, Part B2. Vienna 1996
Fea
Coc
feat
hier
a cl
cod
Sev
Coc
pro
clas
star
des
fea!
inte
dic
En
dat:
and
line
and
an
acc
(IS!
(IS!
has
unc
apr
enc
opt
enc
4.3
rat]
(S4
be
cor
pla
use
Sel
dec
eas
dig
CO!
enc
en
nes
suf
acc
ext
ap]
pai
cal
use
de:
8 |
be!
the
CO!
