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