PN ee 0). RM m,
yj
al
le
le
id
rs
y
Or
)e
1e
1e
at
1e
ly
ge
ge
ne
ne
it
its
2;
of
be
Feature/attribute coding: Traditionally, Feature
Codes (FC) are used to differentiate between the
features of a geographic database. FCs may be
hierarchical generated with respect to the hierarchy of
a classification of features or non-hierarchical. Feature
coding is another area where standardization is needed.
Several standards, like FACC (Feature and Attribute
Coding Catalogue) (NATO, 1993), have recently been
proposed for this purpose. An IF may have its own
classification scheme or allow external feature coding
standards to be used with. IFs offering both options are
desirable. Also, IF should enable the transfer of
features/attributes which may not be covered by
internal or external standards through a data
dictionary.
Encoding scheme: For the interchange, supplier
data has to be encoded into a series of bits and bytes
and transmitted to the client. Transmission may be on-
line over communication lines or off-line via magnetic
and optical transfer media. Encoding of the data with
an underlying schema and data model is carried out
according to an encoding scheme such as ISO 8211
(ISO 1985) and ASN.1 (Abstract Syntax Notation One)
(ISO, 1987). To understand the encoded data, the client
has to either know the codes (tags) used in encoding or
underlying supplier schema if a tagless encoding was
applied. In addition to tagged/tagless encoding, an
encoding scheme may offer ASCII or binary encoding
options. Encoding scheme should enable a condense
encoding and be hardware independent.
4.3 Interchange environment criteria
Documentation: Since a general format would be
rather complex and require a certain level of expertise
(SAIF, 1991; Altheide, 1992), its documentation must
be clear and easily understandable. As is the case with
many traditional IFs, data model and implementation
concepts should not be mixed. The documentation will
play an important role for an IF to obtain a widespread
use.
Services: By "services" we mean translator, encoder,
decoder, and communicator rutines or modules, which
would enable constraction of interchange interfaces
easily, in a modular fashion. Translations between two
digital data representations may be simple or
complex. Encoder and decoder rutines are for
encoding/decoding the transfer data according to an
encoding scheme. Finally, communicator rutines are
needed for physically moving the data between
supplier and client. Conventional methods have been
accepted unsuccessful in producing extendible software
(Meyer, 1988). A high degree of reusability and
extendibility can be provided through object-oriented
approach. Methods or services are already an inherent
part of the object-oriented data model. Thus, services
can be encapsulated within the objects and can be re-
used for various interfaces. Through a "good" initial
design extendibility can also be ensured.
Tools:
- Compiler/Interpreter tools : Since the translation
between two digital data representations is similar to
the one between programming and machine languages,
compiler/interpreter techniques can be benefited from
in spatial data interchange (Pascoe and Penny, 1990). That
is, if data representations can be expressed formally,
translators can be developed automatically. This is
especially valuable for rendering direct translators a feasible
approach against traditional neutral translators. Direct
translators are preferable over neutral translators mainly for
providing more complete translations. Even in the case of
neutral translators, compiler/interpreter tools namely
parsers, scanners, code generators, and executors
accompanying an IF will be an important asset in its
promotion as a standard.
Formal Description Language (FDL) : To prevent
misinterpretations, the abstract definition of IF should be in
an FDL. A textual FDL is needed for both expressing
extensions to the IF standard schema and
compiler/interpreter tools. A graphical description
language would also be helpful for users in understanding
the abstract definition. Ideally, translation between the
textual and graphical languages must be automatic.
- Selection tools : In an ideal interchange environment, the
client should, desirably via a GUI, be able to query supplier
data and then import only what is needed. Selections should
be able to identify either individual features or a sub-group
of features Selection tools may involve query languages,
browsers, visualization tools, and proper organization of
data.
5. EVALUATION
DIGEST (Digital Geographic Information Exchange
Standard) (NATO, 1993), has been developed by the Digital
Geographic Information Working Group (DGIWG) of NATO.
NATO has formally adopted DIGEST in 1993 as its
interchange standard. It has been designed for producer to
user and user to user. spatial data the interchange. Either
feature-based or relational implementation, which are
referred to as DIGEST-A and DIGEST-C respectively may be
applied.
SAIF (Spatial Archive and Interchange Format) (SAIF,
1994), has been developed by the Geomatics Unit, Surveys
and Resource Mapping Branch (SRMB) of the British
Columbia (BC) Ministry of Environment, Lands, and Parks.
Current version (V3.2) was released in 1994. SAIF has been
used to deliver SRMB data since 1992. Canadian General
Standards Board, Committee on Geomatics has approved
SAIF in 1991 as the National Standard for geographic data
interchange (SAIF-FAQ, 1995). SAIF has an Object-
Oriented data model and supports Object-Oriented
implementation.
SDTS (Spatial Data Transfer Standard), is the culmination of
approximately 9-years work of the development team
(Fegeas vd., 1992). US Geological Survey (USGS) is
currently the maintenance authority for SDTS. All the
Federal agencies in the US were legally required to release
their data in SDTS starting from February 1994. USGS and
US Census Bureau now offers their DLG and TIGER data in
SDTS (GIS-L, 1994). On the other hand, Australia and New
Zeland have been working on adopting SDTS. SDTS has a
feature-based data model implemented relationally.
The evaluation of DIGEST, SAIF, and SDTS by the
evaluation criteria is summarized in Table 1. In terms of data
63
International Archives of Photogrammetry and Remote Sensing. Vol. XXXI, Part B2. Vienna 1996
