ge proc-
stributed
type of
. by spa-
ze that a
stributed
ICCESS to
:h as the
flexible
ard- and
ding the
available
tial
ble
by
be
the
sor,
ure
asy
ide-
and
st at
rver
dja-
—
ick-
user
and
tifi-
nust
e to
ser-
nent
i.
tem.
. for
con-
rain
port
ng.
Figure 1: General Layout of the GDSS. The Central Server(CS) holds the browsing map and quicklooks of all attached
archives. The CS is accessed from Retrieval Clients via a Local Server at each site, archives remain invisible to the
3.2 General Layout
The GDSS responds to the requirements in Table 1 with a
layout of five main components, as illustrated in Figure 1.
The Central Server is the main component of the system and
will be described separately in the next section.
Image Archives are maintained by commercial vendors or
public institutions but have to fulfill special requirements in
order to become participants of GDSS (Rehatschek, in print).
Local Servers have to be set up at every user site. This server
is responsible for local caching, data prediction, user man-
agement, accounting and batchjob processing.
The Retrieval Client provides users with query definition
forms and the interactive map browser. The map can be
overlaid by vector and raster data. Vector data can be image
borders, contour lines, names and extents of topographic
features, user defined graphics like regions of interest, point
marks or personal annotations. Raster data are quicklooks of
available images.
The Network defines the overall system performance and the
availability of the entire GDSS. In 1991 ATM
(Asynchronous Transfer Mode) was proposed by the former
CCITT (now: ITU-T) as the standard for B-ISDN. ATM is
designed as a physical layer independent protocol and can
transport all existing and future B-ISDN services. It supports
connection-oriented and connection-less services as well as
isochronous services (Prycker, 1994). Furthermore ATM is
the only currently known network technology supporting
high bandwidth up to 2.4 GBit/sec, a guaranteed quality of
service throughout a session and WAN geographical scope
(McDysan, 1994; Saito H., 1994; Sadiku M., 1995). Hence
ATM is likely to become a world wide integrating network
329
technology in the near future. In addition ATM defines
standard interfaces to existing protocols (Ethernet, FDDI,
Token Ring), which makes LAN integration of the Local
Server sites easy. We propose an ATM network as the ideal
backbone for a system having high requirements to the
bandwidth like the GDSS. To grant worldwide scope the
usage of the TCP/IP protocol is obligatory. TCP/IP, which is
settled at OSI layers 3 (network) and 4 (transport) makes the
GDSS independent of the underlying physical components.
Because IP over ATM still suffers from lack of performance,
there are several ongoing research projects investigating
TCP/IP over ATM (IETF, 1995; Perloff, 1995: Hongging, in
print) for performance improvements.
3.3 Layout for the Central Server (CS)
Table 2 describes the CS components and Figure 2 outlines
the main CS modules and communication paths.
4. IeMPLEMENTATION MILESTONES
We have begun to implement a functional prototype of the
proposed GDSS. This implementation initially focuses on the
Magellan data set, the needs of PDS scientists and their
hardware platforms. A functional prototype will be available
by the second half of 1997. Milestones and expected results
are addressed in the following subsections.
4.1 Building the Network
We have begun with a testbed for GDSS using a total of
three institutions, initially all of them in Austria. The Uni-
versity of Vienna participates through the Vienna Parallel
Computing Center (VCPC) with its massively parallel
computer Meiko CS-2, setting it up as a CS. At two
University institutes in Graz a Local Server is being set up
with several user workstations attached to each server.
International Archives of Photogrammetry and Remote Sensing. Vol. XXXI, Part B2. Vienna 1996
