The International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences. Vol. XXXVII. Part Bl. Beijing 2008 
Figure 1 The GeoSWIFT 2.0 architecture and the key components of the 
architecture 
GeoSWIFT 2.0 architecture consists of the following four 
components: 
1. SSW Layer: Logically, the GeoSWIFT 2.0 system is 
composed of multiple SSW Layers. Each SSW Layer 
offers a distinct sensing service for a specific phenomenon. 
For example, an SSW air temperature layer provides a 
service for air temperature observations. At the 
implementation level, each SSW Layer is composed by 
multiple SSW Layer Nodes of the same observation type. 
2. SSW Layer Node (SLN): GeoSWIFT 2.0 is 
composed of many SLNs. SLNs play a service provider 
role in the SSW. SLNs are P2P nodes providing SSW 
services using a P2P spatial query infrastructure (i.e., 
P2PSAM) with high level OGC SWE interfaces. From an 
SSW client’s perspective, all GeoSWIFT 2.0’s 
participating SLNs, as a whole, act as a single 
interoperable SSW service node. 
3. Spatial Sensor Node (SSN): SSN is a network 
gateway that links the sensors and the SLNs. It plays a data 
provider role in the SSW. Each SSN collects raw data from 
sensors and streams the data to one or more SLNs. 
4. GeoSWIFT 2.0 Client: This is an OGC SWE client 
that provides a 2D/3D map and allows user to use the SSW 
functions. 
Next, we further illustrate the design of the GeoSWIFT 2.0 
architecture. 
4.2.1 SSW Layer 
We use the “SSW Layer” concept, which is similar to the GIS 
layer concept, to manage the different types of observations 
offered in the GeoSWIFT 2.0. Logically, GeoSWIFT 2.0 
consists of multiple SSW Layers. Each SSW Layer offers one 
and only one distinct type of the observation. Therefore, 
conceptually, each SSW Layer can be considered as a map 
layer of a particular phenomenon. For example, the air 
temperature SSW Layer provides a sensing service for air 
temperature observations. Employing the SSW Layer concept 
allows us to manage multiple logical sensing services in a 
single physical service framework. 
As a naming convention, each SSW Layer has a layer name, a 
unique identifier, called the SSW Layer URN (L URN ). L URN is 
the Uniform Resource Name (URN) of the phenomenon 
observed by the SSW Layer. For example, an SSW Layer for 
air temperature may have an L URN of 
urn: ssw :def:phenomenon: AirTemperature. 
With the URN, sensor owners or SSW users can find the 
description or definition to explain the meaning of the L URN in 
detail. How to define the URNs and maintain an infrastructure 
(e.g., a URN resolving service) to provide the URN definitions 
is out of the scope of this paper. However, we expect in the near 
future that there will be an international standards organization 
for managing and maintaining a set of standard URNs for 
phenomenon definitions. One existing example is the NASA 
SWEET ontology (http://sweet.jpl.nasa.gov/ontology/). 
An SSW Layer is a collection of entries, i.e., [mbbox, endpoint] 
pairs. Each pair links to one SLN network location. The mbbox 
is a minimum bounding box in a 2D space that approximates 
the sensing area covered by the SLN’s sensors (i.e., the SSNs), 
and the endpoint is a service endpoint allowing service requests 
to be forwarded to the SLN. 
What makes the SSW Layer unique is how we build, maintain, 
update and query it in a P2P environment. We use P2PSAM as 
the framework to implement the SSW Layer. At an 
implementation level, each GeoSWIFT’s SSW Layer is in fact 
one Linear Quad-Tree (LQT) that is realized using a DHT 
overlay network. This means that the SSW Layer (i.e., the 
[mbbox, endpoint] pairs) are split into Quadtree nodes 
according to data density, and the Quadtree nodes are uniformly 
and randomly distributed and stored in the DHT overlay 
network. Next, we introduce the atomic component of 
GeoSWIFT 2.0: the SSW Layer Node (SLN). 
4.2.2 SSW Layer Node (SLN) 
SSW Layer Nodes (SLNs) are the atomic component of the 
GeoSWIFT 2.0 system. Physically, the GeoSWIFT 2.0 system 
consists of many SSW Layer Nodes (SLNs) connected to the 
Internet. As a whole, the SLNs together provide a P2P-based 
cooperative SSW service. 
What makes the GeoSWIFT 2.0’s design unique is the SLNs’ 
fully decentralized Peer-to-Peer model, where each 
participating SLN has equal responsibilities. A GeoSWIFT 2.0 
client can choose any SLN from the system and send requests 
to the chosen node. This means that any single SLN can be the 
access point of the service, and can accept client requests. Upon 
receiving the request from a client, the SLN forwards the 
request to the SLNs, which can potentially answer the query 
(i.e., forwarding the queries to the candidate nodes). After 
receiving the query, the candidate SLNs then independently 
process the query and reply with the results in parallel. 
The core of the SLN’s P2P model is the P2PSAM introduced in 
section 2. P2PSAM enables spatial lookup in a P2P 
environment. In order to implement the P2PSAM spatial query 
framework, we need a DHT overlay network to provide the 
P2P-based message routing and distributed file storage