The International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences. Vol. XXXVII. Part Bl. Beijing 2008
infrastructure. GeoSWIFT 2.0 uses Pastry 1 (Rowstron and
Druschel, 2001) as its underlying DHT infrastructure. Each
SLN owns a Pastry node instance. This provides the DHT
putney, value), remove(fey), get (key), and updat e(key, value)
APIs. The SLN’s DHT APIs allow us to implement P2PSAM’s
spatial query mechanisms. Finally, on top of the DHT APIs and
P2PSAM APIs, we can then implement the SLN Layer
Management APIs to build, maintain, update, and query the
SSW Layer. Next, we describe how the SLNs using P2PSAM,
as the spatial query framework, to offer a P2P-based SSW
service.
4.2.3 SLN’s P2P-based SSW Service
The SSW service provided by the SLNs can be described using
the following sample spatial query statement. For illustration
purposes, we will use this sample query as an example
throughout this section.
Given a rectangle W, find all observations of phenomenon X
within W
In our P2P-based SSW service architecture, the client can
choose any SLN from the system and send the above request to
the chosen SLN. After an SLN receive the query, it uses
P2PSAM to process the query. Therefore, the SLNs process the
query in three P2PSAM steps: (1) Filter Step, (2) Forward Step,
and (3) Refinement Step (Figure 2).
mfihwSiM
P2P SAW tayw
B*«*B«**i*
;G«tOti8*t»alén
'request Wo s
P2PLOT
ioitJettoSMPte
<GetObservations>
1
OGC SWE Interfaces
SIN P2PSAM layer
"1
WindowOueryQ
P2PLQT Layer
n—I Î r
put() remove!) get() update!)
\ 1 \ J
tflEanastSfeo
AaosAKAgtotiMtra&xne»
troni she «Ser «8p. kvwKd the
<5e(OiS*»vation «Quest » the
esnsWBäsSUte
DHT layer
An SIN
A Pastry DHT overlay network
formed by all SLNs
Figure 2 A diagram of how the SLNs offer a P2P-based SSW service
using P2PSAM as the spatial query framework
1. Filter Step: The filter step finds the candidate nodes.
The candidate nodes are the SLNs that can potentially
contribute to the query, i.e., the nodes whose mbbox
intersects rectangle W in the query. The filter step is
cooperatively performed by the SLNs, because the
SLNs are also Pastry DHT nodes running P2PSAM
application software. The final result of the filter step
is a list of endpoints of the candidate nodes.
2. Forward Step: After the initial SLN gets the
endpoints of the candidate nodes, according to the
1 P2PSAM is not coupled with any DHT infrastructure.
Therefore, SLNs can be easily implemented with other DHT
infrastructures, such as Tapestry or CAN.
endpoints it can then forward the query message to
the candidate nodes.
3. Refinement Step: Upon receiving the queries the
candidate SLNs independently process the queries.
Each candidate SLN executes the query against the
spatial properties (e.g., locations) of their hosting
SSNs. This step is required because of the fact that
the sensing area of the SLN (i.e., the SLN’s mbbox)
overlaps the query does not mean that all of the
SLN’s sensor observations overlap the query. After
finishing local query processing, each candidate node
returns its own results to the SLN that initiated the
query message. The SLN then streams the refinement
results from the multiple candidate nodes back to the
client that issued the query message.
5. CONCLUSION
In this paper, we presented the GeoSWIFT 2.0, a new P2P
based interoperable SSW architecture. GeoSWIFT 2.0
integrates the interoperable OGC SWE architecture (i.e., open
standards-based GIService for the SSW) with the scalable
P2PSAM architecture in order to realize an interoperable and
scalable SSW service.
GeoSWIFT’s design improves existing Internet GIService’s
scalability by removing their centralized topologies. As we
discussed in section 2, the centralized topologies are not
suitable for large-scale and highly dynamic data sources.
GeoSWIFT 2.0’s P2P model removes the potential single point
of failure and the system performance bottleneck. 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. This unique P2P design differentiates the GeoSWIFT
2.0 from other GIService systems or SSW service systems, such
as the Univerity of Minnesota’s MapServer
(http://mapserver.gis.umn.edu/), Universität Minister's 52North
SOS (http://52north.org/), or GeoSWIFT 1.0 (Liang et al., 2005;
Liang and Tao, 2005; Tao et al., 2003).
REFERENCES
Androutsellis-Theotokis, S. and Spinellis, D., 2004. A Survey
of Peer-to-Peer Content Distribution Technologies. ACM
Comput. Surv., 36(4): 335-371.
Balazinska, M. et al., 2007. Data Management in the
Worldwide Sensor Web. IEEE Pervasive Computing, 6(2): 30-
40.
Botts, M., Robin, A., Davidson, J. and Simonis, L, 2006.
OpenGIS Sensor Web Enablement Architecture Document,
Open Geospatial Consortium, Inc.
Guha, S., Daswani, N. and Jain, R., 2006. An Experimental
Study of the Skype Peer-to-Peer VoIP System, The 5th
International Workshop on Peer-to-Peer Systems, Santa Barbara,
CA.
Liang, S.H.L., 2008. A New Fully Decentralized Scalable Peer-
to-Peer GIS Architecture, ISPRS XXIth Congress, Beijing.
1012