## 3 New Generation Sensor Web Enablement
### SOAP Binding Introduced
#### 3.3.2 Access to Observations and Sensor Metadata  
Standardized access to sensor observations and sensor metadata is provided by the Sensor Observation Service (SOS). The service acts as a mediator between a client and a sensor data archive or a real-time sensor system. The heterogeneous communication protocols and data formats of the associated sensors are hidden by the standardized interface of the SOS. Sensor data requested by a client are returned as observations. The interface of the SOS supports access to heterogeneous sensor types, stationary as well as mobile sensors which gather their data _in-situ_ or remotely. Currently, the development of the second version of the SOS specification [72] has finished the public comment phase, and is about to be submitted to the standard approval process. The main advancements from SOS 1.0 to SOS 2.0 are outlined in Table 3 and described in the following. \begin{table}
\begin{tabular}{|l|l|} \hline
**Specification** & **Description of change** \\ \hline  & Restructuring of the specification by separating into core and extensions \\  & KVP binding introduced \\  & Increased interoperability: \\  & \(\bullet\) Mandatory set of operators and operands for temporal and spatial filters \\  & \(\bullet\) Spatial Filtering Profile defines interoperable access to spatial observations \\  & \(\bullet\) O\&M as default and mandatory response format for observations \\  & Capabilities redesign: \\ SOS 2.0 & \(\bullet\) One sensor per observation offering \\  & \(\bullet\) Related features instead of all features of interest are listed in Capabilities \\  & Result handling redesign: \\  & \(\bullet\) New operations for result insertion (_InsertResult_ and _InsertResultTemplate_) \\  & \(\bullet\) New operations for result retrieval (_GetResult_ and _GetResultTemplate_) \\  & Advanced feature retrieval by extending the _GetFeatureOfInterest_ operation \\  & Removed operations for the retrieval of types (_DescribeObservationType_, _DescribeResultModel_, and _DescribeFeatureType_) \\ \hline SOS 2.0—Get Data & Added extension for the retrieval of metadata about available data \\ Availability Extension & (_GetDataAvailability_ operation) \\ \hline \end{tabular}
\end{table} 
Table 3: Major changes of SOS 2.0. Restructuring of the Specification  
By aiming at a clearer structure of the specification document, SOS 2.0 divides its operations and functionalities into a _core_ and its _extensions_. The _core_ comprises the mandatory operations for retrieval of the service metadata and its content (_GetCapabilities_), for accessing observations (_GetObservation_), and for querying sensor descriptions (_DescribeSensor_). The _transactional extension_ contains operations for inserting new sensor descriptions and sensor observations. The _result handling_ extension specifies operations for insertion and retrieval of pure observation results without observation metadata to increase performance and scalability. The _enhanced extension_ amends the SOS functionality by providing optional operations, for example, to enable the retrieval of observed features. Also SOS 1.0 has separated its operations into four distinct parts, so-called _profiles_. However, this terminology was misleading, since a _profile_ of a standard is defined as a subset of the base standards requirements [73], and not as a part of a standard. Increased Interoperability  
The flexibility and the generic character of the SOS 1.0 interface have been identified as a factor that may reduce interoperability between different SWE based systems. Multiple SOS 1.0 server and client implementations exist and have been used in various applications [74, 75, 76, 77]. However, a single client application capable of retrieving and processing observations from various SOS servers from different vendors without according code adjustments is, to the best knowledge of the authors, currently not available.