What is Sensor Observation Service (SOS) in XML?

This article provides an overview of the Sensor Observation Service (SOS), an open standard for accessing real-time and historical sensor data. It details the architecture of SOS within the Open Geospatial Consortium (OGC) framework, the primary service operations used to query data, and the precise role XML formats—specifically Observations and Measurements (O&M) and SensorML—play in structuring and delivering sensor readings.

What is the Sensor Observation Service?

The Sensor Observation Service (SOS) is an open API standard defined by the Open Geospatial Consortium (OGC) as part of its Sensor Web Enablement (SWE) initiative. SOS provides a standardized web service interface that allows clients to query, retrieve, and manage real-time or archived observation data from heterogeneous sensors, sensor platforms, and sensor networks.

By standardizing the interface, SOS abstracts the underlying hardware and database details, allowing systems ranging from weather stations to satellite feeds to be accessed using a single, unified protocol.

Core Operations of SOS

An SOS server processes requests using standardized operations, which clients typically invoke over HTTP via GET, POST, or SOAP requests:

• GetCapabilities: Returns service metadata, listing supported operations, coordinate reference systems, and the available sensor offerings and observation types.
• DescribeSensor: Retrieves detailed metadata about a specific sensor, such as its calibration, accuracy, physical location, and vendor data.
• GetObservation: Retrieves actual observation data and measurements based on spatial, temporal, and thematic filters defined by the client.

How SOS Delivers Sensor Readings Using XML

SOS utilizes Extensible Markup Language (XML) to format both requests and responses. The transmission of sensor data relies on two fundamental OGC XML encoding standards: SensorML and Observations and Measurements (O&M).

1. Sensor Description via SensorML

When a client executes a DescribeSensor request, the SOS responds with an XML document formatted according to the Sensor Model Language (SensorML) schema. SensorML describes the sensor’s physical and mechanical properties, inputs, outputs, and internal processes.

2. Delivering Readings via Observations and Measurements (O&M)

When a client requests sensor readings using GetObservation, the SOS packages the output into an XML payload defined by the Observations and Measurements (O&M) standard (OGC / ISO 19156).

An O&M XML response encapsulates several key elements: * om:phenomenonTime: The exact timestamp or time interval during which the measurement occurred. * om:resultTime: The time when the measurement result was generated or recorded. * om:observedProperty: The phenomenon being measured (e.g., air temperature, water level, atmospheric pressure). * om:featureOfInterest: The real-world object or location targeted by the observation (e.g., a specific river basin or weather station coordinate). * om:procedure: A link or reference to the sensor that generated the measurement. * om:result: The actual data payload. This can be a simple scalar value, a structured record, or a compact array of values separated by standard delimiters.

The Data Delivery Workflow

1. Request: A client sends an XML-encoded GetObservation request to the SOS endpoint, specifying parameters like temporal range (e.g., last 24 hours), geographic bounding box, and the target observed property.
2. Processing: The SOS server parses the request, queries its connected sensor database, and maps the proprietary sensor data into standard OGC data models.
3. Response: The server serializes the retrieved data into an O&M-compliant XML document and returns it over HTTP with an XML MIME type.
4. Consumption: The client parses the standardized XML tags to extract the measurement results, timestamps, and locations for visualization, analysis, or integration into geographic information systems (GIS).