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