1124
The International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences. Vol. XXXVII. Part B4. Beijing 2008
The three systems are independent of the DSS and each other,
and the only way to utilize their functions is through the open
access interfaces provided by them. On the contrary, the DSS
must rely on the three systems, because they are able to provide
a series of data and functions necessary for decision making
analyses, for example, supplying surroundings-relevant data of
an incident, modeling incident evolution and committing model
computations. The decision support subsystem is the core of the
DSS, which couples the other three systems together loosely to
support decision makings. Outer data that commonly are hold
by different organizations, such as urban transportation data,
demographic census, meteorology etc., are able to be employed
easily by the DSS in decision making analyses under the
assistances of the underlain three systems.
The DSS is constructed in client/server architecture. The server
side consists of the decision support subsystem and the three
underlain systems, which physically are distributed but
logically form an integral system. The client side is composed
of a web interface that acts as the user interface of the DSS and
communicates with the decision support subsystem. This design
makes all operations to the DSS be able to be completed in
network. For example, inputting incident-related data and
viewing incident evolution all can be done remotely.
The DSS is not designed for any specific kinds of emergencies.
Essentially speak, it likely provides an emergency DSS
framework that can by extended quickly and expediently to
support decision makings of a great span of emergencies. The
capability is obtained greatly owing to the underlain systems
from CyberSIG.
In fact, the DSS is a typical application of digital city that
presents and validates the capability of CyberSIG in the sharing
of resources of different organizations. In the following, some
detailed introductions to each segment of the DSS are given.
2.2 Spatial Database Management System
SDMS, as the core technique platform of Urban Spatial Data
Infrastructure (USDI), is built upon Oracle database
management system, and consists of a database, a metadata
base and some function modules (Li et al., 2004) (see Figure 2).
The database stores a fundamental urban geospatial dataset that
are utilized extensively in different applications. The elements
of the dataset include image, DEM, vector map and traffic
network of a city. The data layers of the vector map component
involve river, road, administrative district, building, facility,
organization and agency. These elements together constitute the
urban geospatial framework data. Different data models, as well
as spatial indexing approaches and data transmitting policies,
are designed to manage these elements in the database for
achieving high access speed and efficiency. The function
modules offer dataset administrators the capability of managing
the dataset and users the accessibility to the dataset. New data
are able to be updated into the database quickly under the
support of the data update module. Multiple image and
geospatial data formats, such as Tiff, JPEG2000, shape files,
mif, kml, gml, etc., are supported, which greatly improves the
usability of SDMS. The management module is implemented
on the ground of the metadata of the dataset that are recorded in
the metadata base. Users employ the access module to query
and abstract data needed from the database. For the
convenience of remote access, three nuclear OGC services for
data access, WFS, WMS and WCS, are developed and deployed
within CSB.
Administrator
User
Management
Update
Maintance
Access
Database
Metadata Base
Figure 2. SDMS overview
In the DSS, the main function of SDMS is providing geospatial
data that are related with an incident and relevant with decision
making analyses. When an incident occurs, some data requests
are to be generated by the decision support subsystem and
submitted to SDMS. The contents involved in these requests
have relationships with the type of the incident and are usually
predefined in the decision support subsystem.
2.3 CyberSIG Service Bus
CSB, implementing a Service-Oriented Architecture (SOA), is a
service management and invocation system for the purpose of
resource sharing (Shi et al., 2006). Figure 3 gives a general
illustration of the architecture of CSB. Resources of different
organizations are required to be packaged as web services that
may contain data, business operations or models. Services are
registered into the resource catalogue that is constructed in
terms of the UDDI (Universal Description, Discovery, and
Integration) specification. The service management module
provides fundamental functions for service providers and
consumers, for instance, service register, lookup, invocation.
The workflow engine gives support to cross-organization
business processes that are defined as orchestrated web services.
One organization can share its resources with other ones by
registering specific web services into the resource catalogue,
and at the same time it also is able to employ resources supplied
by other organizations.
c
Service
Provider
Service
Consumer
Service Management
Register
Query'Lookup
Match
Invocation
Workflow Engine
Create
Management
Parse
Execution
Resource Catalogue
Figure 3. CSB overview
CSB satisfies the requirement of the DSS for data integration.
During emergency preparation, organizations package their data
as web services and enrolled them in the resource catalogue.
When an emergency occurs, these data can be acquired in real
time by calling to the registered services, and then are able to be
used in prepared emergency models. Consequently, the results
given by the models are guaranteed to be generated on the basis