|
SensorGrid
SensorGrid project aims to develop a flexible computing environment for coupling real-time data sources to High Performance Geographic Information Systems (GIS) applications. The system will be developed around Service Oriented Architecture (SOA) principles and High Performance Web Services ideas where real-time sources publish their data products via standard interfaces in common formats and clients have access to both streaming and archived data.
Traditionally GIS applications such as simulation, visualization and data mining tools are developed to access and manipulate archived geospatial data. But advances in real-time data acquisition techniques from various types of sensors introduced a new group of applications that are being designed to run on real-time data to provide real-time or near-real time results; such applications are gaining ground in platforms like Crisis Management or Early Warning Systems because they allow authorities to take action on time. Earthquake data assimilation tools are good examples of this group since they use data from Seismic or GPS sensors. However, most of these tools currently consume data from repositories and they do not have access to real-time data due to several reasons.
SensorGrid architecture will utilize open GIS standards and Web Services methodologies to couple data assimilation tools with real-time data. The system will use
NaradaBrokering as the messaging substrate and this will allow high performance data transfer between data sources and the client applications. The Standard GIS interfaces and encodings like
GML and
SensorML will allow data products to be available to the larger GIS community.
Figure 1. Major SensorGrid Components
Figure 1. depicts a client's interaction with SensorGrid to gain access to streaming sensor data. The client discovers the related Sensor Collection Service (SCS) information by using search interfaces provided by Information Service (IS). IS returns a handler which contains the WSDL address of the SCS that has access to the particular sensor client requests. The client then sends a getData query to SCS. Depending on the nature of the query SCS may take two actions; if the query is for archived sensor data then it requests data from the Observation Archives and returns it to the client. But if the client wants to access real-time data then it returns a data handler which contains the broker information and topic name for the sensor. Also depending on the size of the archived data SCS may choose one of two options for data transfer; if the result size is relatively small then it is returned via SOAP message, otherwise NaradaBrokering is used. SCS also keeps information about the sensors themselves. This information is encoded in SensorML. After receiving the broker address and the topic name, client may subscribe to the NaradaBrokering server to receive real-time data.
Next: Background and Related Technologies
|
