International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Volume XXXIX-B4, 2012
XXII ISPRS Congress, 25 August — 01 September 2012, Melbourne, Australia
3.1.1 Sensor System Description: it describes the sensor's
purpose / field of application, manufacturer and user details are
provided in the basic system description. This information can
help the sensor data user to understand the exact purpose of the
application of the system.
3.1.2. Sensor Process Model: Provides serializations of
executable components in a sensor system which includes
inputs, outputs, and parameters. The schematic view of sensor
process model (Figure 2) provides information about how
collected data is received and transmitted by different nodes in
the system.
3.1.3 Sensor Process Chain: Defines a serialized execution
methodology of sensor (Botts and Robin, 2007). It also
explains details of individual sensor and its input, output,
accuracy, etc.
3.1.4 Sensor Connections: These are part of the process chain
and defines the connections between inputs, outputs, and
parameters. The connection property uses a link object to
reference the source and destination of a connector (Botts and
Robin, 2007).
3.1.5 Sensor System Physical Layout: It is the process chain
that includes positional information (spatial and temporal) of
all sensor components in the real world. For example, the
Stargate (base station) in AS system is taken as a reference and
relative position of each mote are located, similarly individual
mote is considered as reference and position information of
each sensor is calculated (Figure 4). Similar approach has been
used to form physical layout of FS system.
Sensor System Description
System Search Keywords
System Identifiers
Relevant Contacts
Sensor process model
System Location
System Inputs
System Output
Sensor Process Chain
Node System Components
(e.g. temperature sensor,
humidity sensor, etc)
Sensor Connections
connections between inputs, outputs,
and parameters
Sensor System Physical Layout
Position of Base Station in Lat, Lon, Alt
Position of Node with reference to
Base Station
Position of temperatura sensor in
Node reference frame
Figure 4. Outline of SensorML GeoSense
4. SERVICE ORIENTED ARCHITECTURE
The Layered architecture of the service consists of Distributed
Application Clients, Sensor Observation Service and WSN
GeoSense, respectively (Figure 5). The database architecture
for SOS is based on an open source implementation of SOS
(Walkowski et al., 2011).
4.1 SOS Wrapper
The data from two different WSN systems has been collected
together in SOS database by using SOS wrapper and
subsequently it is accessed by the geographically distributed
application clients through standard XML-HTTP requests. The
SOS wrapper helps to convert raw data from different formats
(text format in AS and XML format in FS) to real data in the
SOS database. It processes the raw sensory data and converts it
into real values at fixed intervals by using the calibration
equations specified in the SensorML, which is stored in
required relations of SOS database by executing Structured
Query Language (SQL) insert statements. The SOS wrapper
facilitates transactional data insertion, which helps in the real
time observations of the data.
= = lu Distributed Application Clients :
GetCapabalities, Capabalities,
GetFeatureOfinterest, FeatureOflnterast,
GetObservations, etc. Observations, etc.
Sensor Observation Service
SOS Wrapper
f Î Sensor Measurements
GeoSense
AgriSens j
(Zigbee mote based fislisorver
WSN) (Wi-Fi based WSN)
Figure 5. Service Oriented Architecture for GeoSense
4.2 Distributed Application Client
An AJAX (Garrett, 2005) based web application client has
been designed with open source tools (GWT, 2011), which
facilitate the visualization of sensor data on the web by
executing standard XML-HTTP requests (e.g. GetCapabilities,
GetFeatureoflnterest, etc.) on SOS database (Figure 6). The
geographically distributed client also has the ability to locate
the sensor on the web mapping service (e.g. Google Web Map
Service is used after signing the terms and conditions on the
Google website), plot sensor data for given time interval in the
table and/or chart formats.
m]
api ard recut so sace 6 7 mant i fuot hy
Non Wand wi nd es ORAS, Agent ad tel! Sotmares | nriten aman
Service Oriented Architecture for GeuSense
Home‘. Sm
URL: peep: cc aihost U8 /62nSOSv3, WAR/S0S
3 cas pem
= ipi A
[zt > sm AMA
i
MN
mme-kfThh mm 536€
1318 48 463-0600
2009-08-27113 18 48 453-4 00
3 end CareTima 2009-11-)7T07 22:36 344-0600
2009-08-27T17:18.48.453-04.00
2399-99-27 [1
Í A : DRE "
Figure 6. Sensor Observation Service Client
438
Internatic
The back-en
8.4 (Postgre
PostGIS ver:
template h
Environment
been used v
convert soui
Apache Tom
application 1
used to test a
4.3 Modellin
The SOS has
near-real tim
temporal re:
minute), thei
data on cliei
original Get
Standards, 2(
was obtained
Through Ren
were process
transferred to
specified pt
grouped by u
analysis (min
Figure 7, sh
modified Ge
understand tl
meteorologica
malfunction if
GetOE
Reques
1. Phenomer
(e.g. temp
2. Time inter
(from day
3. Grouping«
(group by
—
Figure 7. F
The SensorMI
to obtain valu
Evapotranspira
SensorML for
method (Allen
Through integr
Penman-Monte
be improved ar
