Deprecation Notice

Notice: This convention has been deprecated due to IOOS’ transition from the OGC SOS/SWE suite of standards to ERDDAP for in situ data dissemination.

All relevant guidance in this standard has been superceded as of the 2020-01-10 publication date of the IOOS Metadata Profile 1.2. Please refer to the IOOS Metadata Profile for current guidance.

The information below is retained for historical reference purposes only.

Introduction

This Web Service Description Document (WSDD) provides a description of a Sensor Observation Service (SOS) that has been developed by U.S. IOOS for deployment by NOAA data providers and IOOS Regional Associations (RAs). This service provides a service consumer with the capability to access ocean observations data products, such as time series and profiles, which are encoded in XML and included in the SWE Common Data Model.

The service interface is a collection of operations, messages, types and elements descriptions. It provides detail on how the SOS data requests and responses are constructed independent of the messaging transmission technology.

The Milestone 1.0 interface is considered a composition of several OGC specifications: in addition to the cornerstone Observations and Measurements standard, elements of the OGC Sensor Web Enablement Suite (SWE) have been identified as useful for the encoding and provision of observational data. While further SWE specifications may be implemented in the future Milestones, at the present IOOS have used the following:

• Sensor Observation Service (SOS) v1.0.0 as a service for the provision of observational data;
• SensorML v1.0.0 for the provision of procedural information;  and
• SWE Common Data Model Encoding Standard v1.0 and v2.0 for result encoding options.

The interface is comprised of some operations, parameters and attributes, which are considered mandatory by the specifications and others which are not. This information, referred to as a Profile, includes information on specification extensions (operations, parameters and attributes not included in a specification) and exclusions (operations, parameters and attributes that are not implemented). The following sections describe the IOOS SOS Profile for Milestone 1.0 providing additional detail about parts of the OGC specifications supported by the Milestone 1.0 implementation and how they are used.

Conformance to Standards and Conventions

OGC SOS Implementation Standards

Figure 1 depicts the Unified Modeling Language (UML) diagram for the OGC O&M core model, which specifies the core conformance classes, which are described within the SOS specification.

As the SOS 2.0 standard has been approved as an official OGC standard while Milestone 1.0 has already been in development, the use of this new and updated version was postponed to the Milestone 2.0, and at present, the SOS v1.0.0 is used for operations.

Figure 1: Core Model Diagram for Observations and Measurements (O&M)

The subsequent sections provide more detail on the service interfaces, including information on data types, messages, operations, and interface descriptions.

NetCDF Climate and Forecast Metadata Convention

The Climate and Forecast (CF) Conventions introduce the standard ways for naming and description of feature types, data components, dimensions, variables and attributes, coordinate systems definition, axis order, etc. The CF Conventions were originally framed as a standard for data written in netCDF format, with model-generated climate forecast data in mind. However, it turned out to be equally applicable to observational datasets presented in various other formats. The IOOS has adopted the CF 1.6 Conventions for both 52⁰North and ncSOS implementations in order to provide SWE encodings for the feature types that are relevant for the IOOS community. In IOOS SOS implementations, the CF Conventions are used for description of data quantities (such as CF standard names, physical descriptions, code spaces, UoMs, etc.) as well as data location in space and time.

IOOS Convention and SOS Templates

To facilitate the practical implementation of the OGC SOS, IOOS has started the development of a series of Templates that explicitly define the IOOS SOS operation responses for the CF feature types. Within Milestone 1.0 timeframe, the templates have only been developed for “point”, “timeSeries”, and “timeSeriesProfile” feature types (https://code.google.com/p/ioostech/source/browse/#svn/trunk/templates/Milestone1.0); the templates for other feature types are planned for Milestone 2.0. The templates are intended as a mandatory guidance for all developers of IOOS-compliant SOS applications.

The Milestone 1.0 templates fully conform to the OGC SOS 1.0.0 Implementation Standard; however, in some “grey areas” where the SOS 1.0.0 is vague and does not provide sufficient guidance, it has been refined with a special IOOS Convention. The IOOS Convention contains additional constraints, definitions, requirements and “best practice” sort of recommendations that SOS 1.0.0 lacks; for future transition, the Convention follows SOS 2.0 requirements and definitions wherever they have been considered applicable, and do not contradict the SOS 1.0.0 specification. The provisions of the IOOS Convention are captured in the IOOS SOS Templates, and described further in this document.

Coordinate System Axis Order

Historically, there was considerable confusion regarding axis order in GML documents, and coordinate reference systems. This confusion started with the introduction of the very first version of theOGC WMS, where axis “x” (longitude) preceeded axis “y” (latitude), while coordinate reference systems defined the opposite order of axis. After some discussion, it was agreed that if CRS is explicitly defined in the service interface or payload, then coordinate values shall be listed in the axis order specified by the referred CRS (OGC 06-135r1 “Specification best practices”).

For IOOS SOS implementations, the CRS reference procedure is defined in OGC 06-121r3 “OGC Web Services Common Specification”, and additionally specified by the IOOS Convention. As the EPSG::4326 CRS is required to identify a station horizontal coordinates, the axis order must match the EPSG::4326 definition, i.e. latitude must precede longitude. The vertical coordinate must always be listed after the horizontal ones, and explicitly follow the definition of the vertical CRS.

Namespaces

The XML type references in the subsequent sections make use of XML namespace prefixes to fully qualify their namespaces. The map of prefixes to standardized namespaces is:

• sos – “http://www.opengis.net/sos/1.0”
• swe – http://www.opengis.net/swe/1.0.1” (SWE Common v1.0)
• swe2 – http://www.opengis.net/swe/2.0” (SWE Common v2.0)
• ows – “http://www.opengis.net/ows/1.1”
• gml – “http://www.opengis.net/gml”
• om – “http://www.opengis.net/om/1.0”
• xlink –”http://www.w3.org/1999/xlink”
• xsi – “http://www.w3.org/2001/XMLSchema-instance”

Note that an IOOS-compliant SOS service shall conform to the following specific patterns for the namespace references in the GetCapabilities and GetObservation response XML headers:

• In GetCapabilities, and DescribeSensor the <swe:> prefix may be omitted, as only one version of SWE Common is used in these operations (see list above).
• In GetObservation, the <swe:> and <swe2:> prefixes must present, as both SWE Common v1.0 and v2.0 are used in this operation, and the prefixes refer to different versions of SWE Common (see list above).
• In both GetCapabilities and GetObservation, the <gml:> prefix may omit reference to a version number, as shown above (just because GML 3.1.1 has been a default version for the O&M 1.0 schema).

Capitalization

The use of the upper and lower cases in SOS response documents and requests is defined by the OGC 06-121r9 “OGC Web Services Common Standard”, clauses 11.5.2 and 11.6.2. To extend and augment the OGC assertions, IOOS Convention require the following:

• service name must always be in UPPERCASE (i.e. “SOS”);
• in requests, parameters (keys) must be case insensitive, and values must be case sensitive;
• operation names must always be in UpperCamelCase (e.g. GetCapabilities);
• in XML documents, element and parameter names, titles, gml ids, and attribute values meant as human readable labels must be written in a lowerCamelCase (e.g. “sensorLocation”). Text containing acronyms should treat the acronym component as a normal word for readability (e.g. bprLocation instead of BPRLocation).

The IOOS Convention stipulates for the following exceptions:

• the “network_all” name must always be in lowercase;
• labels containing the short version of an identifier or definition URI that contains underscores keep their original case (e.g. air_temperature, station_12, etc);
• identifier values and terms from established vocabularies (e.g. http://mmisw.org/ont/cf/parameter/air_temperature or urn:ioos:station:RA_authority:station_name) keep their original (vocabulary) case.

Use of URL in HTTP GET and POST Requests

HTTP supports two request methods: GET and POST. In a GET method, request parameters are transmitted as part of the service URL, and in a POST method, request parameters are transmitted in the body of the POST message.

The OGC 06-121r9 “OGC Web Services Common Standard” defines a complete URL for HTTP GET requests as a URL prefix with appended additional parameters in order to construct a valid operation request. Each operation may have a different prefix, and each prefix is entirely at the discretion of the service provider.

A URL prefix for HTTP GET consists of (in order) IP servername or numeric address, optional port number, path to a server resource, and mandatory question mark “?”:

http://SERVERNAME:[PORT]/SOS-WEBAPP/sos?

A prefix is appended by operation-specific request, which is an optional string of one or more name/value pairs in the form “name=value&” (parameter name, equals sign, parameter value(s), ampersand). As “&” is just a separator between name/value pairs, it is therefore optional after the last pair in the request string:

http://SERVERNAME:[PORT]/SOS-WEBAPP/sos?</a>[name=value&amp;][name=value]

For HTTP POST operation, a URL does not require additional parameters to be appended to it in order to construct a valid target for the operation request (as opposed to a prefix as in the HTTP GET case). Thus, the URL for the HTTP POST does not end up with a question mark “?”.  The servername, port and path to SOS resource may differ from GET URL, or be the same, at the discretion of the server provider:

http://SERVERNAME:[PORT]/SOS-WEBAPP/sos

Service Operations

The OGC SOS interface is based on the OGC Web Service Common specification, thus, it has shares structures and data types of service requests with the other OGC Web Services. In the case of SOS, the operation signature is constrained by the observation schema, as it defines the response model. The SOS v1.0 defines three operational profiles:

• Core Profile operations (mandatory, within scope of the Milestone 1.0)
  • GetCapabilities
  • DescribeSensor
  • GetObservation
• Extended and Transactional Profiles operations (optional, out of scope for the Milestone 1.0)
  • RegisterSensor
  • InsertObservation
  • GetResult
  • GetFeatureOfInterest
  • GetFeatureOfInterestTime
  • DescribeFeatureOfInterest
  • DescribeObservationType
  • DescribeResultModel

The Core Profile has been identified as relevant to IOOS DMAC; the implementation of the Core Profile operations within the Mileastone 1.0 framework is described hereinafter. The Core Profile operations are based on the stateless HTTP request/response model. A diagram illustrating the basic message sequence is shown in Figure 2.

Figure 2: SOS Request/Response Pattern

At the start of the interaction, a consumer issues a GetCapabilities request to a server. Returned information includes metadata describing supported interface versions, supported formats, functional extensions, available offerings, etc. The supported SOS versions and features are common IOOS-wide, minimizing differences between deployed i52N and ncSOS server instances, although the available observation data for a particular server will vary from instance to instance.

Following a successful GetCapabilties operation, a consumer optionally issues one or more DescribeSensor requests to get more information about stations/platforms and sensors. A consumer than uses the information obtained from GetCapabilities and DescribeSensor responses for a GetObservation request that specifies an observed property, offering, an optional spatial and/or temporal extent, and other criteria. The server retrieves all matching data and returns it to the consumer in the GetCoverage response.

Erroneous requests detected by the server result in a response containing an XML-based exception message rather than an SOS response.

Examples of the consumer requests and SOS server responses are shown in subsequent sections. Unless something different is specified, the encoding samples have been taken from the set of IOOS SOS Milestone 1.0 templates.

GetCapabilities

GetCapabilities operation provides the interface for any client to access metadata about a specific service, which in this case is SOS. This operation allows clients to retrieve service metadata about a specific service instance, including metadata about the tightly-coupled data served. In addition to more generic capabilities response elements such as filter options, the SOS GetCapabilities returns a list of so called Offerings, which are groupings of available observations described by their feature of interest, procedure, observed property, temporal coverage and the like. This allows the user application to clearly identify the types and quality of data that can be requested from this service.

Please note, that SOS in version 1.0 does not restrict creation of observation offerings. On the other hand, SOS 2.0 is more specific and defines that each observation offering is limited to be associated with exactly one procedure, which can be a network, station, or sensor. The U.S. IOOS has made a decision to imply that limitation starting at Milestone 1.0 with SOS v1.0; this not only solves the issue of the SOS 1.0 with ambiguous groupings of observations to offerings but also ensures the continuity of the Milestones.

GetCapabilities Request

GetCapabilities request may be sent to the server as HTTP/GET or HTTP/POST. HTTP/GET request passes parameters to the server in the HTTP URL with a number of key-value pairs (KVP) of input parameters, and HTTP/POST request sends an XML document to the server, that may also be KVP-encoded. A request to perform GetCapabilities should follow the structure as depicted in the Figure 3 and table below.

Figure 3: GetCapabilities request schema

Note, that although GetCapabilities request may contain all parameters from Table 1, just first three of them (service, request, and acceptVersions) are required by the IOOS Convention.

The following HTTP/GET and HTTP/POST request samples, when issued to the SOS server, will result in all available metadata for SOS v1.0.0 being returned. Although parameter names in a GET KVP request are case-insensitive, IOOS Convention recommends writing them in lower case just for ease-of-reading and consistency:

• HTTP/GET to both 52North and ncSOS implementations
  
  • http://SERVERNAME:PORT/SOS_WEBAPP_NAME/sos?service=SOS&request=GetCapabilities, or
  • http://SERVERNAME:PORT/SOS_WEBAPP_NAME/sos?service=SOS&request=GetCapabilities&AcceptVersions=1.0.0
    
    
• HTTP/GET to ncSOS implementation without parameters
  • http://SERVERNAME:PORT/SOS_WEBAPP_NAME/sos?
    
    
• HTTP/POST

<sos:GetCapabilities
xmlns="http://www.opengis.net/sos/1.0"
xmlns:ows="http://www.opengis.net/ows/1.1"
xmlns:ogc="http://www.opengis.net/ogc"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.opengis.net/sos/1.0 http://schemas.opengis.net/sos/1.0.0/sosGetCapabilities.xsd"
service="SOS" updateSequence="">
    <ows:AcceptVersions>
        <ows:Version>1.0.0</ows:Version>
    </ows:AcceptVersions>
    <ows:Sections>   
        <ows:Value>All</ows:Value>  
    </ows:Sections>
</sos:GetCapabilities>

GetCapabilities Response

The response to a GetCapabilities request is an XML encoded document that conforms to the SOS 1.0.0 Implementation Specification [OGC 06-009r6], and illustrates the characteristics of the SOS system by providing a comprehensive information about coordinate reference system (CRS), spatial or temporal filtering and other information about sensors, feature of interest, and response format. The OGC specification is constrained by the IOOS Convention that on one hand prescribes a certain way of use for some optional components, and on the other hand – facilitates the future acceptance of the SOS 2.0. At any rate, the IOOS Convention does not violate OGC specification’s requirements.

Figure 4: GetCapabilities response schema

The example below shows all five sections depicted in the figure above, and assumes that a GetCapabilities request with no specified subsections was issued, resulting in a response containing all SOS Capabilities metadata:

• ows:ServiceIdentification
• ows:ServiceProvider
• ows:OperationsMetadata
• sos:Filter_Capabilities
• sos:Contents

<sos:Capabilities
xmlns:sos="http://www.opengis.net/sos/1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ows="http://www.opengis.net/ows/1.1" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:gml="http://www.opengis.net/gml" xmlns:ogc="http://www.opengis.net/ogc" version="1.0.0" xsi:schemaLocation="http://www.opengis.net/sos/1.0 http://schemas.opengis.net/sos/1.0.0/sosAll.xsd">
  <ows:ServiceIdentification>...</ows:ServiceIdentification>
  <ows:ServiceProvider>...</ows:ServiceProvider>
  <ows:OperationsMetadata>...</ows:OperationsMetadata>
  <sos:Filter_Capabilities>…</sos:Filter_Capabilities>
  <sos:Contents>...</sos:Contents>
</sos:Capabilities>

The subsections are described in more details in the following chapters.

ServiceIdentification

This section contains metadata about this specific server, including the title, abstract, keywords, service type, version, fees, and access constraints if any for using this server. No IOOS-specific guidelines and conventions are applicable to this section; it is fully defined by the SOS 1.0.0 standard.

  <ows:ServiceIdentification>
    <ows:Title>TITLE</ows:Title>
    <ows:Abstract>ABSTRACT</ows:Abstract>
    <ows:Keywords>
      <ows:Keyword>KEYWORD 1</ows:Keyword>
      <ows:Keyword>KEYWORD 2</ows:Keyword>
    </ows:Keywords>
    <ows:ServiceType codeSpace="http://opengeospatial.net">OGC:SOS</ows:ServiceType>
    <ows:ServiceTypeVersion>1.0.0</ows:ServiceTypeVersion>
    <ows:Fees>NONE</ows:Fees>
    <ows:AccessConstraints>NONE</ows:AccessConstraints>
  </ows:ServiceIdentification>

ServiceProvider

This section contains metadata about the organization operating this server, including service provider name, site, address, contact information, etc. Similar to the previous section described above, this section does not require following any IOOS-specific conventions; it is fully defined by the SOS 1.0.0 standard.

  <ows:ServiceProvider>
    <ows:ProviderName>IOOS (OR ANY OTHER PROVIDER)</ows:ProviderName>
    <ows:ProviderSite xlink:href="http://www.ioos.noaa.gov/"/>
    <ows:ServiceContact>
      <ows:IndividualName>TBA</ows:IndividualName>
      <ows:PositionName>TBA</ows:PositionName>
      <ows:ContactInfo>
        <ows:Phone>
          <ows:Voice>1-301-427-2420</ows:Voice>
        </ows:Phone>
        <ows:Address>
          <ows:DeliveryPoint>1100 Wayne Ave., Suite 1225</ows:DeliveryPoint>
          <ows:City>Silver Spring</ows:City>
          <ows:AdministrativeArea>MD</ows:AdministrativeArea>
          <ows:PostalCode>20910</ows:PostalCode>
          <ows:Country>USA</ows:Country>
          <ows:ElectronicMailAddress>noaa.ioos.webmaster@noaa.gov</ows:ElectronicMailAddress>
        </ows:Address>
      </ows:ContactInfo>
    </ows:ServiceContact>
  </ows:ServiceProvider>

OperationsMetadata

This section contains metadata about the operations specified by this service and implemented by this server, including the URLs, parameters for operation requests. A corresponding section of the IOOS Milestone 1.0 GetCapabilities template is presented below; the template contains just the bare minimum of the required metadata that describes the server operations capability.

The URL for HTTP GET requests may either differ from the URL for POST requests or be the same. Note also, that OGC 06-121r9 “OGC Web Service Common Implementation Specification” requires GET URL to end up with a question mark (“?”), as opposed to the POST URL:

<ows:HTTP>
    <ows:Get xlink:href="SOS_SERVER_GET_URL?"/>
    <ows:Post xlink:href="SOS_SERVER_POST_URL"/>
</ows:HTTP>

In addition tothe SOS v1.0.0 Implementation Specification, the IOOS Convention requires an indication of the current versions for both template and software; this information is provided in the <ows:ExtendedCapabilities>/<gml:metaDataProperty xlink:title="ioosTemplateVersion">, and in the <ows:ExtendedCapabilities>/<gml:metaDataProperty xlink:title="softwareVersion"> elements respectively.

  <ows:OperationsMetadata>
    <ows:Operation name="GetCapabilities">
      <ows:DCP>
        <ows:HTTP>
          <ows:Get xlink:href="SOS_SERVER_GET_URL?"/>
          <ows:Post xlink:href="SOS_SERVER_POST_URL"/>
        </ows:HTTP>
      </ows:DCP>
      <ows:Parameter name="Sections">
        <ows:AllowedValues>
          <ows:Value>ServiceIdentification</ows:Value>
          <ows:Value>ServiceProvider</ows:Value>
          <ows:Value>OperationsMetadata</ows:Value>
          <ows:Value>Contents</ows:Value>
          <ows:Value>All</ows:Value>
        </ows:AllowedValues>
      </ows:Parameter>
    </ows:Operation>
    <ows:Operation name="GetObservation">
      <ows:DCP>
        <ows:HTTP>
          <ows:Get xlink:href="SOS_SERVER_GET_URL?"/>
          <ows:Post xlink:href="SOS_SERVER_POST_URL"/>
        </ows:HTTP>
      </ows:DCP>
      <ows:Parameter name="observedProperty">
        <ows:AllowedValues>
          <ows:Value>VALUE</ows:Value>
          <ows:Value>COMPOSITE_VALUE</ows:Value>
        </ows:AllowedValues>
      </ows:Parameter>
    </ows:Operation>
    <ows:Operation name="DescribeSensor">
      <ows:DCP>
        <ows:HTTP>
          <ows:Get xlink:href="SOS_SERVER_GET_URL?"/>
          <ows:Post xlink:href="SOS_SERVER_POST_URL"/>
        </ows:HTTP>
      </ows:DCP>
      <ows:Parameter name="outputFormat">
        <ows:AllowedValues>
          <ows:Value>text/xml;subtype="sensorML/1.0.1/profiles/ioos_sos/1.0"</ows:Value>
        </ows:AllowedValues>
      </ows:Parameter>
    </ows:Operation>
    <ows:Parameter name="service">
      <ows:AllowedValues>
        <ows:Value>SOS</ows:Value>
      </ows:AllowedValues>
    </ows:Parameter>
    <ows:Parameter name="version">
      <ows:AllowedValues>
        <ows:Value>1.0.0</ows:Value>
      </ows:AllowedValues>
    </ows:Parameter>
    <ows:ExtendedCapabilities>
      <gml:metaDataProperty xlink:title="ioosTemplateVersion"
        xlink:href="http://code.google.com/p/ioostech/source/browse/#svn%2Ftrunk%2Ftemplates%2FMilestone1.0">
        <gml:version>1.0</gml:version>
      </gml:metaDataProperty>
      <gml:metaDataProperty xlink:title="softwareVersion"
          xlink:href="http://someURI">
          <gml:version>0.9.4.5</gml:version>
      </gml:metaDataProperty>
    </ows:ExtendedCapabilities>    
  </ows:OperationsMetadata>

Contents

This section contains the list of all of the observation offerings available from the service, specifically the network offerings and offerings for all affiliated stations/platforms. Each of the <sos:ObservationOffering> elements describes a collection of related sensor system observations. However, in order to restrain the response document size and mitigate scalability problems, the IOOS Convention requires that sensor offerings must not be included in a platform offering description, i.e none of the <sos:ObservationOffering> elements may include a sensor procedure. In order to get a detailed description of the sensors installed on the platform, a DescribeSensor operation should be used.

The IOOS Convention impose certain general constraints on the Contents section:

• Advertising of the “network_all” group of platforms is required.
• Advertising of logical sub-groups of the “network_all” group (e.g. by provider, region, measurement type, etc.) is recommended.
• Advertising of the individual platforms is not recommended; instead, it is recommended to use a separate DescribeSensor document for that rather than list the individual platforms as offerings.

The definition of some SOS metadata elements that appear in the Contents section is also further constrained by IOOS Convention. Note that by no means that refinement steps over the boundaries of the OGC standards, i.e. all constrained elements still conform to the relevant specifications.

<sos:time>
  <gml:TimePeriod>
    <gml:beginPosition>2010-11-15T18:15:00Z</gml:beginPosition>
    <gml:endPosition> 2010-11-25T23:15:00Z</gml:endPosition>
  </gml:TimePeriod>
</sos:time>

<sos:time>
  <gml:TimePeriod>
    <gml:beginPosition>2010-11-15T18:15:00Z</gml:beginPosition>
    <gml:endPosition indeterminatePosition="now"</gml:endPosition>
  </gml:TimePeriod>
</sos:time>

The application of the IOOS Convention to the SOS 1.0.0 Implementation Standard is illustrated by a sample of the Content section of the IOOS Milestone 1.0 GetCapabilities template below; the template shows just the bare minimum of the required metadata, a real server may advertize more parameters and provide more details.

  <sos:Contents>
    <sos:ObservationOfferingList>
      <sos:ObservationOffering gml:id="network_all">
        <gml:description>All stations</gml:description>
        <gml:name>urn:ioos:network:AUTHORITY:all</gml:name>
        <gml:srsName>EPSG:4326</gml:srsName>
        <gml:boundedBy>
          <gml:Envelope srsName="http://www.opengis.net/def/crs/EPSG/0/4326">
            <gml:lowerCorner>-90 -180</gml:lowerCorner>
            <gml:upperCorner>90 180</gml:upperCorner>
          </gml:Envelope>
        </gml:boundedBy>
        <sos:time>
          <gml:TimePeriod>
            <gml:beginPosition>BEGINNING</gml:beginPosition>
            <gml:endPosition indeterminatePosition="now"/>
          </gml:TimePeriod>
        </sos:time>
        <sos:procedure xlink:href="urn:ioos:network:AUTHORITY:all"/>
        <sos:observedProperty xlink:href="http://mmisw.org/ont/cf/parameter/VALUE"/>
        <sos:observedProperty xlink:href="http://mmisw.org/ont/cf/parameter/COMPOSITE_VALUE"/>
        <sos:featureOfInterest xlink:href="FEATURE"/>
        <sos:responseFormat>text/xml;schema="om/1.0.0/profiles/ioos_sos/1.0"</sos:responseFormat>
        <sos:resultModel>om:ObservationCollection</sos:resultModel>
        <sos:responseMode>inline</sos:responseMode>
      </sos:ObservationOffering>
      <sos:ObservationOffering gml:id="network_favorites">
        <gml:description>All stations</gml:description>
        <gml:name>urn:ioos:network:AUTHORITY:favorites</gml:name>
        <gml:srsName>EPSG:4326</gml:srsName>
        <gml:boundedBy>
          <gml:Envelope srsName="http://www.opengis.net/def/crs/EPSG/0/4326">
            <gml:lowerCorner>30 -130</gml:lowerCorner>
            <gml:upperCorner>45 -110</gml:upperCorner>
          </gml:Envelope>
        </gml:boundedBy>
        <sos:time>
          <gml:TimePeriod>
            <gml:beginPosition>BEGINNING</gml:beginPosition>
            <gml:endPosition indeterminatePosition="now"/>
          </gml:TimePeriod>
        </sos:time>
       <sos:procedure xlink:href="urn:ioos:network:AUTHORITY:favorites"/>
        <sos:observedProperty xlink:href="http://mmisw.org/ont/cf/parameter/VALUE"/>
        <sos:observedProperty xlink:href="http://mmisw.org/ont/cf/parameter/COMPOSITE_VALUE"/>
        <sos:featureOfInterest xlink:href="FEATURE"/>
        <sos:responseFormat>text/xml;schema="om/1.0.0/profiles/ioos_sos/1.0"</sos:responseFormat>
        <sos:resultModel>om:ObservationCollection</sos:resultModel>
        <sos:responseMode>inline</sos:responseMode>
      </sos:ObservationOffering>
    </sos:ObservationOfferingList>
  </sos:Contents>

Even more details are depicted in the sample below, which presents a Contents part of the real AOOS test SOS server GetCapabilities documenmt (the sample is presented just for reference, as the response may change at any time); the sampled document advertizes more offerings, observed properties, response output format encodings, etc.

  <sos:Contents>
    <sos:ObservationOfferingList>
      <sos:ObservationOffering gml:id="urn_ioos_network_test_all">
        <gml:name>urn:ioos:network:test:all</gml:name>
        <gml:boundedBy>
          <gml:Envelope srsName="http://www.opengis.net/def/crs/EPSG/0/4326">
            <gml:lowerCorner>60.683 -151.398</gml:lowerCorner>
            <gml:upperCorner>70.4 -146.88</gml:upperCorner>
          </gml:Envelope>
        </gml:boundedBy>
        <sos:time>
          <gml:TimePeriod xsi:type="gml:TimePeriodType">
            <gml:beginPosition>2009-05-23T00:00:00.000Z</gml:beginPosition>
            <gml:endPosition>2012-08-23T08:00:00.000Z</gml:endPosition>
          </gml:TimePeriod>
        </sos:time>
        <sos:procedure xlink:href="urn:ioos:network:test:all"/>
        <sos:observedProperty xlink:href="http://mmisw.org/ont/cf/parameter/air_temperature"/>
        <sos:observedProperty xlink:href="http://mmisw.org/ont/cf/parameter/direction_of_sea_water_velocity"/>
        <sos:observedProperty xlink:href="http://mmisw.org/ont/cf/parameter/sea_water_practical_salinity"/>
        <sos:observedProperty xlink:href="http://mmisw.org/ont/cf/parameter/sea_water_speed"/>
        <sos:observedProperty xlink:href="http://mmisw.org/ont/cf/parameter/sea_water_temperature"/>
        <sos:observedProperty xlink:href="http://mmisw.org/ont/cf/parameter/wind_speed"/>
        <sos:featureOfInterest xlink:href="urn:ioos:station:test:blighreef"/>
        <sos:featureOfInterest xlink:href="urn:ioos:station:test:blighreef-10m-15m"/>
        <sos:featureOfInterest xlink:href="urn:ioos:station:test:blighreef-15m-20m"/>
        <sos:featureOfInterest xlink:href="urn:ioos:station:test:blighreef-5m-10m"/>
        <sos:featureOfInterest xlink:href="urn:ioos:station:test:nikiski-10m"/>
        <sos:featureOfInterest xlink:href="urn:ioos:station:test:nikiski-15m"/>
        <sos:featureOfInterest xlink:href="urn:ioos:station:test:nikiski-5m"/>
        <sos:featureOfInterest xlink:href="urn:ioos:station:test:prudhoe"/>
        <sos:responseFormat>application/zip</sos:responseFormat>
        <sos:responseFormat>text/xml;subtype="om/1.0.0"</sos:responseFormat>
        <sos:responseFormat>text/xml;subtype="om/1.0.0/profiles/ioos_sos/1.0"</sos:responseFormat>
        <sos:responseMode>inline</sos:responseMode>
        <sos:responseMode>resultTemplate</sos:responseMode>
      </sos:ObservationOffering>
      <sos:ObservationOffering gml:id="urn_ioos_network_test_all-air-temperature">
        <gml:name>urn:ioos:network:test:all-air-temperature</gml:name>
        <gml:boundedBy>
          <gml:Envelope srsName="http://www.opengis.net/def/crs/EPSG/0/4326">
            <gml:lowerCorner>60.84 -148.527</gml:lowerCorner>
            <gml:upperCorner>70.4 -146.88</gml:upperCorner>
          </gml:Envelope>
        </gml:boundedBy>
        <sos:time>
          <gml:TimePeriod xsi:type="gml:TimePeriodType">
            <gml:beginPosition>2009-05-23T00:00:00.000Z</gml:beginPosition>
            <gml:endPosition>2012-08-23T06:42:00.000Z</gml:endPosition>
          </gml:TimePeriod>
        </sos:time>
        <sos:procedure xlink:href="urn:ioos:network:test:all-air-temperature"/>
        <sos:observedProperty xlink:href="http://mmisw.org/ont/cf/parameter/air_temperature"/>
        <sos:observedProperty xlink:href="http://mmisw.org/ont/cf/parameter/direction_of_sea_water_velocity"/>
        <sos:observedProperty xlink:href="http://mmisw.org/ont/cf/parameter/sea_water_speed"/>
        <sos:observedProperty xlink:href="http://mmisw.org/ont/cf/parameter/sea_water_temperature"/>
        <sos:observedProperty xlink:href="http://mmisw.org/ont/cf/parameter/wind_speed"/>
        <sos:featureOfInterest xlink:href="urn:ioos:station:test:blighreef"/>
        <sos:featureOfInterest xlink:href="urn:ioos:station:test:blighreef-10m-15m"/>
        <sos:featureOfInterest xlink:href="urn:ioos:station:test:blighreef-15m-20m"/>
        <sos:featureOfInterest xlink:href="urn:ioos:station:test:blighreef-5m-10m"/>
        <sos:featureOfInterest xlink:href="urn:ioos:station:test:prudhoe"/>
        <sos:responseFormat>application/zip</sos:responseFormat>
        <sos:responseFormat>text/xml;subtype="om/1.0.0"</sos:responseFormat>
        <sos:responseFormat>text/xml;subtype="om/1.0.0/profiles/ioos_sos/1.0"</sos:responseFormat>
        <sos:responseMode>inline</sos:responseMode>
        <sos:responseMode>resultTemplate</sos:responseMode>
      </sos:ObservationOffering>
      <sos:ObservationOffering gml:id="urn_ioos_station_test_blighreef">
        <gml:name>urn:ioos:station:test:blighreef</gml:name>
        <gml:boundedBy>
          <gml:Envelope srsName="http://www.opengis.net/def/crs/EPSG/0/4326">
            <gml:lowerCorner>60.84 -146.88</gml:lowerCorner>
            <gml:upperCorner>60.84 -146.88</gml:upperCorner>
          </gml:Envelope>
        </gml:boundedBy>
        <sos:time>
          <gml:TimePeriod xsi:type="gml:TimePeriodType">
            <gml:beginPosition>2009-05-23T00:00:00.000Z</gml:beginPosition>
            <gml:endPosition>2012-08-23T06:30:00.000Z</gml:endPosition>
          </gml:TimePeriod>
        </sos:time>
        <sos:procedure xlink:href="urn:ioos:station:test:blighreef"/>
        <sos:observedProperty xlink:href="http://mmisw.org/ont/cf/parameter/air_temperature"/>
        <sos:observedProperty xlink:href="http://mmisw.org/ont/cf/parameter/direction_of_sea_water_velocity"/>
        <sos:observedProperty xlink:href="http://mmisw.org/ont/cf/parameter/sea_water_speed"/>
        <sos:observedProperty xlink:href="http://mmisw.org/ont/cf/parameter/wind_speed"/>
        <sos:featureOfInterest xlink:href="urn:ioos:station:test:blighreef"/>
        <sos:featureOfInterest xlink:href="urn:ioos:station:test:blighreef-10m-15m"/>
        <sos:featureOfInterest xlink:href="urn:ioos:station:test:blighreef-15m-20m"/>
        <sos:featureOfInterest xlink:href="urn:ioos:station:test:blighreef-5m-10m"/>
        <sos:responseFormat>application/zip</sos:responseFormat>
        <sos:responseFormat>text/xml;subtype="om/1.0.0"</sos:responseFormat>
        <sos:responseFormat>text/xml;subtype="om/1.0.0/profiles/ioos_sos/1.0"</sos:responseFormat>
        <sos:responseMode>inline</sos:responseMode>
        <sos:responseMode>resultTemplate</sos:responseMode>
      </sos:ObservationOffering>
      <sos:ObservationOffering gml:id="urn_ioos_station_test_nikiski">
        <gml:name>urn:ioos:station:test:nikiski</gml:name>
        <gml:boundedBy>
          <gml:Envelope srsName="http://www.opengis.net/def/crs/EPSG/0/4326">
            <gml:lowerCorner>60.683 -151.398</gml:lowerCorner>
            <gml:upperCorner>60.683 -151.398</gml:upperCorner>
          </gml:Envelope>
        </gml:boundedBy>
        <sos:time>
          <gml:TimePeriod xsi:type="gml:TimePeriodType">
            <gml:beginPosition>2012-08-23T06:00:00.000Z</gml:beginPosition>
            <gml:endPosition>2012-08-23T08:00:00.000Z</gml:endPosition>
          </gml:TimePeriod>
        </sos:time>
        <sos:procedure xlink:href="urn:ioos:station:test:nikiski"/>
        <sos:observedProperty xlink:href="http://mmisw.org/ont/cf/parameter/sea_water_practical_salinity"/>
        <sos:observedProperty xlink:href="http://mmisw.org/ont/cf/parameter/sea_water_temperature"/>
        <sos:featureOfInterest xlink:href="urn:ioos:station:test:nikiski-10m"/>
        <sos:featureOfInterest xlink:href="urn:ioos:station:test:nikiski-15m"/>
        <sos:featureOfInterest xlink:href="urn:ioos:station:test:nikiski-5m"/>
        <sos:responseFormat>application/zip</sos:responseFormat>
        <sos:responseFormat>text/xml;subtype="om/1.0.0"</sos:responseFormat>
        <sos:responseFormat>text/xml;subtype="om/1.0.0/profiles/ioos_sos/1.0"</sos:responseFormat>
        <sos:responseMode>inline</sos:responseMode>
        <sos:responseMode>resultTemplate</sos:responseMode>
      </sos:ObservationOffering>
      <sos:ObservationOffering gml:id="urn_ioos_station_test_prudhoe">
        <gml:name>urn:ioos:station:test:prudhoe</gml:name>
        <gml:boundedBy>
          <gml:Envelope srsName="http://www.opengis.net/def/crs/EPSG/0/4326">
            <gml:lowerCorner>70.4 -148.527</gml:lowerCorner>
            <gml:upperCorner>70.4 -148.527</gml:upperCorner>
          </gml:Envelope>
        </gml:boundedBy>
        <sos:time>
          <gml:TimePeriod xsi:type="gml:TimePeriodType">
            <gml:beginPosition>2012-08-23T06:00:00.000Z</gml:beginPosition>
            <gml:endPosition>2012-08-23T06:42:00.000Z</gml:endPosition>
          </gml:TimePeriod>
        </sos:time>
        <sos:procedure xlink:href="urn:ioos:station:test:prudhoe"/>
        <sos:observedProperty xlink:href="http://mmisw.org/ont/cf/parameter/air_temperature"/>
        <sos:observedProperty xlink:href="http://mmisw.org/ont/cf/parameter/sea_water_temperature"/>
        <sos:featureOfInterest xlink:href="urn:ioos:station:test:prudhoe"/>
        <sos:responseFormat>application/zip</sos:responseFormat>
        <sos:responseFormat>text/xml;subtype="om/1.0.0"</sos:responseFormat>
        <sos:responseFormat>text/xml;subtype="om/1.0.0/profiles/ioos_sos/1.0"</sos:responseFormat>
        <sos:responseMode>inline</sos:responseMode>
        <sos:responseMode>resultTemplate</sos:responseMode>
      </sos:ObservationOffering>
    </sos:ObservationOfferingList>
  </sos:Contents>

DescribeSensor

A DescribeSensor is a simple core SOS operation that returns an XML Document associated with one or more sensors, platforms or networks. It provides metadata about sensors and the observation collected by these sensors. All the information of sensor characteristics is encoded into the SensorML standard.

With some sophisticated sensors or sensor-reach platforms and networks, the metadata may be quite voluminous. Although GetCapabilities operation could provide a list of sensors and some sensor-related metadata, it is meant for delivery of only high-level information about the observable properties, locations, contact information, etc. On the contrary, DescribeSensor operation is designed to request detailed sensor metadata, and supports retrieval of the highest level of detail about the platforms and sensors associated with an SOS. The sensor characteristics can include lists and definitions of parameters supported by the sensor SOS 1.0.0 Implementation Specification [OGC 06-009r6].

The following sections illustrate DescribeSensor HTTP/GET and HTTP/POST requests, provides the list of the request parameters and description for the DescribeSensor operation response.

DescribeSensor Request

A DescribeSensor request may be sent to the server as HTTP/GET or HTTP/POST. While HTTP/POST request sends an XML document to the server, HTTP/GET request passes parameters to the server in the HTTP URL with a number of key-value pairs (KVP) of input parameters. A request to perform DescribeSensor operation should follow the structure that is described in this section.

The UML diagram of the DescribeSensor request is presented in Figure 5.

Figure 5: DescribeSensor request schema

The input parameters of the DescribeSensor request are explained in the following table:

The following examples illustrate HTTP/GET and HTTP/POST DescribeSensor requests. Although parameter names in a GET KVP request are case-insensitive, IOOS Convention recommends writing them in lower case just for ease-of-reading and consistency:

• HTTP/GET:

http://SERVERNAME:PORT/SOS_WEBAPP_NAME/sos?request=DescribeSensor&service=SOS&version=1.0.0&procedure=[anyURI]&outputformat=text/xml;subtype="sensorML/1.0.1/profiles/ioos_sos/1.0"

• HTTP/POST:

<sos:DescribeSensor version="1.0.0" service="SOS"
  xmlns="http://www.opengis.net/sos/1.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://www.opengis.net/sos/1.0  http://schemas.opengis.net/sos/1.0.0/sosDescribeSensor.xsd"
  outputFormat="text/xml;subtype=&quot;sensorML/1.0.1/profiles/ioos_sos/1.0&quot;">
  <procedure>urn:ioos:network:test:all</procedure>
</sos:DescribeSensor>

DescribeSensor Response

The response to a DescribeSensor request is a Sensor Model Language (SensorML) document that describes the sensor system. In some cases, a DescribeSensor response may be quite voluminous; for example, if description of the network has been requested, and the response returns the document that contains detailed information not just about the network itself, but all network platforms and all sensors installed on each platform. A UML diagram of such an all-inclusive DescribeSensor document is depicted in Figure 6 followed by the annotated outline of the document.

Figure 6: DescribeSensor response schema

<sml:SensorML>
    <sml:capabilities name="ioosServiceMetadata">
                Version of the IOOS Template used in this document  
    </sml:capabilities>
    <sml:member>
        <sml:System>
            <gml:description>
                      Collection of all station assets available via the RA’s network SOS service
            </gml:description>
            <gml:name>
                      urn:ioos:network:ra_name:all
            </gml:name>
            <gml:boundedBy>
                      Spatial bounds of the content described by this network
            </gml:boundedBy>
            <sml:identification>
                      networkID, shortName and longName
            </sml:identification>
            <sml:classification>
                      All classifiers that apply to this network offering
            </sml:classification>
            <sml:validTime>
                      Represents the date range of the validity of this document
            </sml:validTime>
            <sml:capabilities name="observationTimeRange">
                  TimeRange element describes the valid time range over which observations from a sensor or station exist
            </sml:capabilities>
            <sml:contact>
                      List all publisher and operator contacts that apply to this network
            </sml:contact>
            <sml:components>
                <sml:ComponentList>
                       List all platforms in the network offering
                    <sml:component name='platform_#01_name'>
                        <sml:System>
                            <sml:identification>
                                      The names of the platform #01 (stationID, shortName and longName)
                            <sml:capabilities name="observationTimeRange">
                               TimeRange element describes the valid time range over which observations from platform #01 exist
                            <sml:location>
                                      Platform #01 geographic location (lat & lon only, no z)
                            <sml:outputs>
                                       A list of the observed properties assotiated with the platform #01
                            <sml:components>
                                <sml:ComponentList>
                                       List of sensors in the platform #01
                                    <sml:component name='sensor_A_name'>
                                        <sml:System>
                                             <gml:description>
                                                        Description of sensor A
                                             </gml:description>
                                             <gml:name>
                                                        urn:ioos:sensor:platform_name:sensor_name
                                             </gml:name>
                                             <sml:identification>
                                                      Names of the sensor A (sationID, shortName and longName)
                                             </sml:identification>
                                             <sml:capabilities name="featureOfInterest">
                                               Feature of interest that sensor A belongs to
                                             </sml:capabilities>
                                             <sml:capabilities name="offerings">
                                               List of all offerings associated with the sensor A
                                             </sml:capabilities>
                                             <sml:capabilities name="stationProcedure">
                                               The ID of the platform (procedure), on which sensor A is installed
                                             </sml:capabilities>
                                             <sml:capabilities name="observationTimeRange">
                                               The valid time range over which observations from sensor A exist
                                             </sml:capabilities>
                                             <sml:inputs>
                                                      Observation phenomena associated with the sensor A
                                             </sml:inputs>
                                             <sml:outputs>
                                                       A list of the outputs assotiated with the sensor A
                                             </sml:outputs>
                                        </sml:System>
                                    </sml:component>
                                        […]
                                    <sml:component name='sensor_K_name'>
                                              Description of sensor K
                                        […]
                                    </sml:component>
                                    <sml:component name='sensor_T_name'>
                                              Description of sensor T
                                    </sml:component>
                                </sml:ComponentList>
                            </sml:components>
                        </sml:System>
                    </sml:component>
                        […]
                    <sml:component name='platform_#NN_name'>
                              Description of the platform #NN
                        […]
                    </sml:component>
                    <sml:component name='platform_#ZZ_name'>
                              Description of the platform #ZZ
                        […]
                    </sml:component>
                </sml:ComponentList>
            </sml:components>
        </sml:System>
    </sml:member>
</sml:SensorML>

In order to decrease the size of the DescribeSensor document, and limit the volume of the detailed information returned, IOOS recognizes 3 separate types of the DescribeSensor documents. For Milestone 1.0, the IOOS SOS is required to provide documents describing network and individual platform, while the description of individual sensor is optional.

Platform/Station

A mandatory DescribeSensor response for a specific platform/station shall return:

• information on the IOOS Template version
• platform description
• search keywords
• relevant contacts about this specific platform
• mandatory platform identifiers, such as
• platformID
• short name
• long name
• mandatory platform classifiers, such as
• platformType
• operatorSector
• publisher
• sponsor
• parentNetwork                        
• mandatory platform geographic location (always in EPSG::4326)
• time range for observations
• optional documentation (external human-readable resources about the platform)
• list of observed properties at platform including relevant sensor information

<!-- Template document for a generic (independant of feature type) Describe Sensor Station -->
<sml:SensorML
  xmlns:sml="http://www.opengis.net/sensorML/1.0.1"
  xmlns:gml="http://www.opengis.net/gml"
  xmlns:swe="http://www.opengis.net/swe/1.0.1"
  xmlns:xlink="http://www.w3.org/1999/xlink"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://www.opengis.net/sensorML/1.0.1 http://schemas.opengis.net/sensorML/1.0.1/sensorML.xsd"
  version="1.0.1">
  <sml:capabilities name="ioosServiceMetadata">
    <swe:SimpleDataRecord>
      <swe:field name="ioosTemplateVersion">
        <swe:Text definition="http://code.google.com/p/ioostech/source/browse/#svn%2Ftrunk%2Ftemplates%2FMilestone1.0">
          <swe:value>1.0</swe:value>
        </swe:Text>
      </swe:field>
    </swe:SimpleDataRecord>
  </sml:capabilities>
 <sml:member>
    <sml:System>
      <gml:description>Observations at urn:ioos:station:wmo:41001 buoy station, 150 NM East of Cape HATTERAS</gml:description>
      <gml:name>urn:ioos:station:wmo:41001</gml:name>
      <sml:identification>
        <sml:IdentifierList>
          <sml:identifier name="stationID">
            <sml:Term definition="http://mmisw.org/ont/ioos/definition/stationID">
              <sml:value>urn:ioos:station:wmo:41001</sml:value>
            </sml:Term>
          </sml:identifier>
          <sml:identifier name="shortName">
            <sml:Term definition="http://mmisw.org/ont/ioos/definition/shortName">
              <sml:value>WMO 41001 Buoy, Cape Hatteras</sml:value>
            </sml:Term>
          </sml:identifier>
          <sml:identifier name="longName">
            <sml:Term definition="http://mmisw.org/ont/ioos/definition/longName">
              <sml:value>urn:ioos:station:wmo:41001 buoy station, 150 NM East of Cape HATTERAS</sml:value>
            </sml:Term>
          </sml:identifier>
          <sml:identifier name="wmoID">
            <sml:Term definition="http://mmisw.org/ont/ioos/definition/wmoID">
              <sml:value>41001</sml:value>
            </sml:Term>
          </sml:identifier>
        </sml:IdentifierList>
      </sml:identification>
      <sml:classification>
        <sml:ClassifierList>
          <sml:classifier name="parentNetwork">
            <sml:Term definition="http://mmisw.org/ont/ioos/definition/parentNetwork">
              <sml:codeSpace xlink:href="http://mmisw.org/ont/ioos/organization"/>
              <sml:value>NANOOS</sml:value>
            </sml:Term>
          </sml:classifier>
          <sml:classifier name="platformType">
            <sml:Term definition="http://mmisw.org/ont/ioos/definition/platformType">
              <sml:codeSpace xlink:href="http://mmisw.org/ont/ioos/platform"/>
              <sml:value>buoy</sml:value>
            </sml:Term>
          </sml:classifier>
          <sml:classifier name="operatorSector">
            <sml:Term definition="http://mmisw.org/ont/ioos/definition/operatorSector">
              <sml:codeSpace xlink:href="http://mmisw.org/ont/ioos/sector"/>
              <sml:value>academic</sml:value>
            </sml:Term>
          </sml:classifier>          
          <sml:classifier name="publisher">
            <sml:Term definition="http://mmisw.org/ont/ioos/definition/publisher">
              <sml:codeSpace xlink:href="http://mmisw.org/ont/ioos/organization"/>
              <sml:value>NANOOS</sml:value>
            </sml:Term>
          </sml:classifier>
          <sml:classifier name="sponsor">
            <sml:Term definition="http://mmisw.org/ont/ioos/definition/sponsor">
              <sml:codeSpace xlink:href="http://mmisw.org/ont/ioos/organization"/>
              <sml:value>ACE</sml:value>
            </sml:Term>
          </sml:classifier>
        </sml:ClassifierList>
      </sml:classification>
      <sml:validTime>
          <gml:TimePeriod>
              <gml:beginPosition>2002-05-04T00:00:00Z</gml:beginPosition>
              <gml:endPosition indeterminatePosition="now"/>
          </gml:TimePeriod>    
      </sml:validTime>
      <sml:capabilities name="observationTimeRange">
        <swe:DataRecord>
          <swe:field name="observationTimeRange">
            <swe:TimeRange definition="http://mmisw.org/ont/ioos/swe_element_type/observationTimeRange">
              <swe:value>2008-04-28T08:00:00.000Z 2012-12-27T19:00:00.000Z</swe:value>
            </swe:TimeRange>
          </swe:field>
        </swe:DataRecord>
      </sml:capabilities>     
      <sml:capabilities name="networkProcedures">
        <swe:SimpleDataRecord>
          <swe:field name="network1">
            <swe:Text definition="http://mmsiw.org/ont/ioos/definition/networkID">
              <swe:value>urn:ioos:network:nanoos:all</swe:value>
            </swe:Text>
          </swe:field>
          <swe:field name="network2">
            <swe:Text definition="http://mmsiw.org/ont/ioos/definition/networkID">
              <swe:value>urn:ioos:network:nanoos:network1</swe:value>
            </swe:Text>
          </swe:field>
          <swe:field name="network3">
            <swe:Text definition="http://mmsiw.org/ont/ioos/definition/networkID">
              <swe:value>urn:ioos:network:nanoos:network2</swe:value>
            </swe:Text>
          </swe:field>
        </swe:SimpleDataRecord>
      </sml:capabilities>
      <sml:contact>
        <sml:ContactList>
          <sml:member xlink:role="http://mmisw.org/ont/ioos/definition/operator">
            <sml:ResponsibleParty>
              <sml:organizationName>PNW Buoys</sml:organizationName>
              <sml:contactInfo>
                <sml:address>
                  <sml:deliveryPoint>1007 Balch Blvd.</sml:deliveryPoint>
                  <sml:city>Fremont</sml:city>
                  <sml:administrativeArea>WA</sml:administrativeArea>
                  <sml:postalCode>98195</sml:postalCode>
                  <sml:country>USA</sml:country>
                  <sml:electronicMailAddress>contact@buoys.com</sml:electronicMailAddress>
                </sml:address>
                <sml:onlineResource xlink:href="http://pnw.buoyoperator.org"/>
              </sml:contactInfo>
            </sml:ResponsibleParty>
          </sml:member>
          <sml:member xlink:role="http://mmisw.org/ont/ioos/definition/publisher">
            <sml:ResponsibleParty>
              <sml:organizationName>NANOOS</sml:organizationName>
              <sml:contactInfo>
                <sml:address>
                  <sml:country>USA</sml:country>
                  <sml:electronicMailAddress>mayorga@apl.washington.edu</sml:electronicMailAddress>
                </sml:address>
                <sml:onlineResource xlink:href="http://nanoos.org"/>
              </sml:contactInfo>
            </sml:ResponsibleParty>
          </sml:member>
        </sml:ContactList>
      </sml:contact>
      <sml:documentation>
        <sml:DocumentList>
          <sml:member name="qc" xlink:arcrole="qualityControlDocument">
            <sml:Document>
              <gml:description>Handbook of Automated Data Quality Control Checks and Procedures, National Data Buoy Center, August 2009</gml:description>
              <sml:format>pdf</sml:format>
              <sml:onlineResource xlink:href="http://www.ndbc.noaa.gov/NDBCHandbookofAutomatedDataQualityControl2009.pdf"/>
            </sml:Document>
          </sml:member>
          <sml:member name="wp1" xlink:arcrole="urn:ogc:def:role:webPage">
            <sml:Document>
              <gml:description>Station web page from provider</gml:description>
              <sml:format>text/html</sml:format>
              <sml:onlineResource xlink:href="STATION_WEBPAGE"/>
            </sml:Document>
          </sml:member>
          <sml:member name="wp2" xlink:arcrole="urn:ogc:def:role:webPage">
            <sml:Document>
              <gml:description>Station web page from operator</gml:description>
              <sml:format>text/html</sml:format>
              <sml:onlineResource xlink:href="STATION_WEBPAGE"/>
            </sml:Document>            
          </sml:member>
        </sml:DocumentList>
      </sml:documentation>
      <sml:history>
        <sml:EventList>
          <sml:member name="deployment_start">
            <sml:Event>
              <sml:date>2010-01-12</sml:date>
              <gml:description>Deployment start event</gml:description>
              <sml:documentation xlink:href="http://sdftest.ndbc.noaa.gov/sos/server.php?service=SOS&amp;request=DescribeSensor&amp;version=1.0.0&amp;outputformat=text/xml;subtype=&quot;sensorML/1.0.1&quot;&amp;procedure=urn:ioos:station:wmo:41001:20100112"/>
            </sml:Event>
          </sml:member>
          <sml:member name="deployment_stop">
            <sml:Event>
              <sml:date>2011-02-06</sml:date>
              <gml:description>Deployment stop event</gml:description>
              <sml:documentation xlink:href="http://sdftest.ndbc.noaa.gov/sos/server.php?service=SOS&amp;request=DescribeSensor&amp;version=1.0.0&amp;outputformat=text/xml;subtype=&quot;sensorML/1.0.1&quot;&amp;procedure=urn:ioos:station:wmo:41001:20100112"/>
            </sml:Event>
          </sml:member>
          <sml:member name="deployment_start">
            <sml:Event>
              <sml:date>2011-02-07</sml:date>
              <gml:description>Deployment start event</gml:description>
              <sml:documentation xlink:href="http://sdftest.ndbc.noaa.gov/sos/server.php?service=SOS&amp;request=DescribeSensor&amp;version=1.0.0&amp;outputformat=text/xml;subtype=&quot;sensorML/1.0.1&quot;&amp;procedure=urn:ioos:station:wmo:41001:20110207"/>
            </sml:Event>
          </sml:member>
        </sml:EventList>
      </sml:history>
      <sml:location>
        <gml:Point srsName="http://www.opengis.net/def/crs/EPSG/0/4326">
        <gml:pos>34.7 -72.73</gml:pos>
        </gml:Point>
      </sml:location>
      <sml:components>
        <sml:ComponentList>
          <sml:component name="WatertempSensor1">
            <sml:System >
              <gml:description>Surface water temperature sensor on WMO platform 41001</gml:description>
              <sml:identification xlink:href="urn:ioos:sensor:wmo:41001:watertemp1"/>
              <sml:documentation xlink:href="http://sdftest.ndbc.noaa.gov/sos/server.php?service=SOS&amp;request=DescribeSensor&amp;version=1.0.0&amp;outputformat=text/xml;subtype=&quot;sensorML/1.0.1&quot;&amp;procedure=urn:ioos:sensor:wmo:41001:watertemp1"/>
              <sml:outputs>
                <sml:OutputList>
                  <sml:output name="Water Temperature">
                    <swe:Quantity definition="http://mmisw.org/ont/cf/parameter/sea_water_temperature">
                      <swe:uom code="degC" />
                    </swe:Quantity>
                  </sml:output>
                </sml:OutputList>
              </sml:outputs>
            </sml:System>
          </sml:component>
          <sml:component name="Sensor ct1">
            <sml:System gml:id="sensor-ct1">
              <gml:description/>
              <sml:identification xlink:href="urn:ioos:sensor:wmo:41001:ct1"/>
              <sml:documentation xlink:href="http://sdftest.ndbc.noaa.gov/sos/server.php?service=SOS&amp;request=DescribeSensor&amp;version=1.0.0&amp;outputformat=text/xml;subtype=&quot;sensorML/1.0.1&quot;&amp;procedure=urn:ioos:sensor:wmo:41001:ct1"/>
              <sml:outputs>
                <sml:OutputList>
                  <sml:output name="Water Temperature">
                    <swe:Quantity definition="http://mmisw.org/ont/cf/parameter/sea_water_temperature">
                      <swe:uom code="degC" />
                    </swe:Quantity>
                  </sml:output>
                  <sml:output name="Salinity">
                    <swe:Quantity definition="http://mmisw.org/ont/cf/parameter/sea_water_salinity">
                      <swe:uom code="PSU" />
                    </swe:Quantity>
                  </sml:output>
                </sml:OutputList>
              </sml:outputs>
            </sml:System>
          </sml:component>
          <sml:component name="Sensor baro1">
            <sml:System>
              <gml:description/>
              <sml:identification xlink:href="urn:ioos:sensor:wmo:41001:baro1"/>
              <sml:documentation xlink:href="http://sdftest.ndbc.noaa.gov/sos/server.php?service=SOS&amp;request=DescribeSensor&amp;version=1.0.0&amp;outputformat=text/xml;subtype=&quot;sensorML/1.0.1&quot;&amp;procedure=urn:ioos:sensor:wmo:41001:baro1"/>
              <sml:outputs>
                <sml:OutputList>
                  <sml:output name="Barometric Pressure">
                    <swe:Quantity definition="http://mmisw.org/ont/cf/parameter/air_pressure">
                      <swe:uom code="mb" />
                    </swe:Quantity>
                  </sml:output>
                </sml:OutputList>
              </sml:outputs>
            </sml:System>
          </sml:component>
          <sml:component name="Sensor airtemp1">
            <sml:System gml:id="sensor-airtemp1">
              <gml:description/>
              <sml:identification xlink:href="urn:ioos:sensor:wmo:41001:airtemp1"/>
              <sml:outputs>
                <sml:OutputList>
                  <sml:output name="Air Temperature">
                    <swe:Quantity definition="http://mmisw.org/ont/cf/parameter/air_temperature">
                      <swe:uom code="degC" />
                    </swe:Quantity>
                  </sml:output>
                </sml:OutputList>
              </sml:outputs>
            </sml:System>
          </sml:component>
        </sml:ComponentList>
      </sml:components>
    </sml:System>
  </sml:member>
</sml:SensorML>

The IOOS Convention provides more specific guidance to some SensorML elements’ implementation in the DescribeSensor template for platform/station; such elements are listed in the table below, and their specifics are explained as well:

<sml:identifier name="wmoID">
    <sml:Term definition=http://mmisw.org/ont/ioos/definition/wmoID>
        <sml:value>41001</sml:value>
    </sml:Term>
</sml:identifier>

<sml:address>
    <sml:deliveryPoint/>
    <sml:city/> 
    <sml:administrativeArea/> 
    <sml:postalCode/>
    <sml:country/> 
    <sml:electronicMailAddress/>
</sml:address> 

Network of platforms/stations

A mandatory DescribeSensor response for a network of platforms/stations shall return:

• information on the IOOS Template version
• network description
• search keywords
• network identifiers, such as
• networkID
• short name
• long name (optional)
• relevant contact information for this specific network
• list of platforms of the network with their identifiers
• list of offerings for the network
• time range for observations
• list of observed properties for the network

The template for a generic DescribeSensor document for network is shown below. The template is independent of feature types, and presents just enough metadata to determine what additional descriptions are needed. The specifics of some elements’ use in the network template are discussed in details later.

<sml:SensorML
    xmlns:sml="http://www.opengis.net/sensorML/1.0.1"
    xmlns:gml="http://www.opengis.net/gml"
    xmlns:swe="http://www.opengis.net/swe/1.0.1"
    xmlns:xlink="http://www.w3.org/1999/xlink"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.opengis.net/sensorML/1.0.1 http://schemas.opengis.net/sensorML/1.0.1/sensorML.xsd"
    version="1.0.1">
    <sml:capabilities name="ioosServiceMetadata">
        <swe:SimpleDataRecord>
            <swe:field name="ioosTemplateVersion">
                <swe:Text definition=”http://code.google.com/p/ioostech/source/browse/#svn%2Ftrunk%2Ftemplates%2FMilestone1.0”>
                    <swe:value>1.0</swe:value>
                </swe:Text>
            </swe:field>
        </swe:SimpleDataRecord>
    </sml:capabilities>
    <sml:member>
        <sml:System>
            <gml:description>Collection of all station assets available via the NANOOS SOS service</gml:description>
            <gml:name>urn:ioos:network:nanoos:all</gml:name>
            <gml:boundedBy>
                <gml:Envelope srsName="http://www.opengis.net/def/crs/EPSG/0/4326">
                    <gml:lowerCorner>32.7 -75.0</gml:lowerCorner>
                    <gml:upperCorner>34.7 -72.0</gml:upperCorner>
                </gml:Envelope>
            </gml:boundedBy>
            <sml:identification>
                <sml:IdentifierList>
                    <sml:identifier name="networkID">
                        <sml:Term definition="http://mmisw.org/ont/ioos/definition/networkID">
                            <sml:value>urn:ioos:network:nanoos:all</sml:value>
                        </sml:Term>
                    </sml:identifier>
                    <sml:identifier name="shortName">
                        <sml:Term definition="http://mmisw.org/ont/ioos/definition/shortName">
                            <sml:value>NANOOS SOS station assets collection</sml:value>
                        </sml:Term>
                    </sml:identifier>
                    <sml:identifier name="longName">
                        <sml:Term definition="http://mmisw.org/ont/ioos/definition/longName">
                            <sml:value>Collection of all station assets available via the NANOOS SOS service</sml:value>
                        </sml:Term>
                    </sml:identifier>
                </sml:IdentifierList>
            </sml:identification>
            <sml:classification>
                <sml:ClassifierList>
                    <sml:classifier name="publisher">
                        <sml:Term definition="http://mmisw.org/ont/ioos/definition/publisher">
                            <sml:codeSpace xlink:href="http://mmisw.org/ont/ioos/organization"/>
                            <sml:value>NANOOS</sml:value>
                        </sml:Term>
                    </sml:classifier>
                    <sml:classifier name="parentNetwork">
                        <sml:Term definition="http://mmisw.org/ont/ioos/definition/parentNetwork">
                            <sml:codeSpace xlink:href="http://mmisw.org/ont/ioos/organization"/>
                            <sml:value>NANOOS</sml:value>
                        </sml:Term>
                    </sml:classifier>
                </sml:ClassifierList>
            </sml:classification>
            <sml:capabilities name="observationTimeRange">
                <swe:DataRecord>
                    <swe:field name="observationTimeRange">
                        <swe:TimeRange definition="http://mmisw.org/ont/ioos/swe_element_type/observationTimeRange">
                            <swe:value>2008-04-28T08:00:00.000Z 2012-12-27T19:00:00.000Z</swe:value>
                        </swe:TimeRange>
                    </swe:field>
                </swe:DataRecord>
            </sml:capabilities>     
            <sml:contact>
                <sml:ContactList>
                    <sml:member xlink:role="http://mmisw.org/ont/ioos/definition/operator">
                        <sml:ResponsibleParty>
                            <sml:organizationName>PNW Buoys</sml:organizationName>
                            <sml:contactInfo>
                                <sml:address>
                                    <sml:deliveryPoint>1007 Balch Blvd.</sml:deliveryPoint>
                                    <sml:city>Fremont</sml:city>
                                    <sml:administrativeArea>WA</sml:administrativeArea>
                                    <sml:postalCode>98195</sml:postalCode>
                                    <sml:country>USA</sml:country>
                                    <sml:electronicMailAddress>contact@buoys.com</sml:electronicMailAddress>
                                </sml:address>
                                <sml:onlineResource xlink:href="http://pnw.buoyoperator.org"/>
                            </sml:contactInfo>
                        </sml:ResponsibleParty>
                    </sml:member>
                    <sml:member xlink:role="http://mmisw.org/ont/ioos/definition/publisher">
                        <sml:ResponsibleParty>
                            <sml:organizationName>NANOOS</sml:organizationName>
                            <sml:contactInfo>
                                <sml:address>
                                    <sml:country>USA</sml:country>
                                    <sml:electronicMailAddress>mayorga@apl.washington.edu</sml:electronicMailAddress>
                                </sml:address>
                                <sml:onlineResource xlink:href="http://nanoos.org"/>
                            </sml:contactInfo>
                        </sml:ResponsibleParty>
                    </sml:member>
                </sml:ContactList>
            </sml:contact>
            <sml:components>
                <sml:ComponentList>          
                    <sml:component name="wmo_41001">
                        <sml:System>
                            <sml:identification>
                                <sml:IdentifierList>
                                    <sml:identifier name="stationID">
                                        <sml:Term definition="http://mmisw.org/ont/ioos/definition/stationID">
                                            <sml:value>urn:ioos:station:wmo:41001</sml:value>
                                        </sml:Term>
                                    </sml:identifier>
                                    <sml:identifier name="shortName">
                                        <sml:Term definition="http://mmisw.org/ont/ioos/definition/shortName">
                                            <sml:value>WMO 41001 Buoy, Cape Hatteras</sml:value>
                                    <sml:identifier name="longName">
                                        <sml:Term definition="http://mmisw.org/ont/ioos/definition/longName">
                                            <sml:value>urn:ioos:station:wmo:41001 buoy station, 150 NM East of Cape Hatteras</sml:value>
                                        </sml:Term>
                                    </sml:identifier>
                                </sml:IdentifierList>
                            </sml:identification>
                            <sml:capabilities name="observationTimeRange">
                                <swe:DataRecord>
                                    <swe:field name="observationTimeRange">
                                        <swe:TimeRange definition="http://mmisw.org/ont/ioos/swe_element_type/observationTimeRange">
                                            <swe:value>2006-02-12T00:00:00.000Z 2013-04-21T00:00:00.000Z</swe:value>
                                        </swe:TimeRange>
                                    </swe:field>
                                </swe:DataRecord>
                            </sml:capabilities>
                            <sml:location>
                                <gml:Point srsName="http://www.opengis.net/def/crs/EPSG/0/4326">
                                    <gml:pos>34.7 -72.73</gml:pos>
                                </gml:Point>
                            </sml:location>
                            <sml:outputs>
                                <sml:OutputList>
                                    <sml:output name="Sea Water Temperature">
                                        <swe:Quantity definition="http://mmisw.org/ont/cf/parameter/sea_water_temperature"/>
                                    </sml:output>
                                    <sml:output name="Dissolved Oxygen">
                                        <swe:Quantity definition="http://mmisw.org/ont/cf/parameter/dissolved_oxygen"/>
                                    </sml:output>
                                </sml:OutputList>
                            </sml:outputs>
                        </sml:System>
                    </sml:component>
                </sml:ComponentList>
            </sml:components>
        </sml:System>
    </sml:member>
</sml:SensorML>

The IOOS Convention provides more detailed guidance to some SensorML elements’ implementation in the template; such elements are listed in the table below, and their specifics are explained as well:

<sml:classifier name="parentNetwork">
    <sml:Term definition="http://mmisw.org/ont/ioos/definition/parentNetwork">
        <sml:codeSpace xlink:href="http://mmisw.org/ont/ioos/organization"/>
        <sml:value>NANOOS    </sml:Term>
</sml:classifier>

<sml:address>
    <sml:deliveryPoint/>
    <sml:city/> 
    <sml:administrativeArea/> 
    <sml:postalCode/>
    <sml:country/> 
    <sml:electronicMailAddress/>
</sml:address>

Sensor

The IOOS SOS Milestone 1.0 does not require a provision of DescribeSensor documents for individual sensors. However, if an SOS server offers these documents nevertheless, the corresponding DescribeSensor response should return:

• information on the IOOS Template version
• sensor description
• search keywords
• mandatory sensor identifiers, such as
• sensorID
• short name
• long name (optional)
• platform identifier for the platform, on which the sensor is located
• time range for observations
• list of all offerings associated with the sensor
• list of all observed properties associated with the sensor

If the DescribeSensor document for individual sensor is provided, the IOOS Convention encourages to keep its content in line with the required network and station/platform documents. Recommended use of some SensorML elements in the DescribeSensor response for individual sensor is described in the table below:

GetObservation

A GetObservation operation queries SOS to retrieve observation data structured according to the Observation and Measurement specification. Upon receiving a GetObservation request, a SOS shall either satisfy the request or return an exception report. The GetObservation operations provides observations based on the setting of filters that includes timing, processes, phenomena, feature of interest, and other parameters of the O&M model.

GetObservation Request

A GetObservation request contains one or more elements that constrain the observations to be retrieved from a Sensor Observation Service. Each GetObservation query element has mandatory attributes of service and version. The mandatory version element attribute must correspond to the specific service interface version negotiated between the service and client during the service binding process. The required service attribute explicitly must be “SOS”.

The UML diagram of the GetObservation request is presented in Figure 7, and input parameters are elaborated in the following table.

Figure 7: GetObservation request schema

The OGC SOS v1.0.0 Implementation Standard defines a number of other parameters that must be supported by the server but are not required in a GetObservation request. Although the use of these parameters is optional, they may significantly refine the query result:

In addition to the standard set of parameters, some of the IOOS data providers have implemented various unique non-standard parameters. Although the use of such parameters may be advantageous, certain caution should be exercised because the support of these parameters is provider-specific; for example, some of the non-standard request parameters supported by CO-OPS are described in the table below:

The following examples illustrate HTTP/GET and HTTP/POST GetObservation requests. Note that in HTTP/GET (KVP) request, the parameter names are case insensitive. The following example shows equivalent terms for a parameter “outputFormat”: outputFormat, outputformat, OUTPUTFORMAT, or OUTPUTfORMAT. As a guideline, it is suggested that lowercase names be used for ease-of-reading and consistency. On the contrary, it is recommended to use the UpperCamelCase for the parameter values like GetCapabilities or DescribeSensor, as they are case sensitive:

• HTTP/GET:

http://SERVERNAME:PORT/SOS_WEBAPP_NAME/sos?service=SOS&version=1.0.0&request=GetObservation&offering=urn:ioos:network:test:all&observedProperty=http://mmisw.org/ont/cf/parameter/wind_speed&procedure=urn:ioos:station:test:blighreef&responseFormat= text/xml; subtype="om/1.0.0/profiles/ioos_sos/1.0"

• HTTP/POST:

<sos:GetObservation xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.opengis.net/sos/1.0 http://schemas.opengis.net/sos/1.0.0/sosAll.xsd"
    xmlns:sos="http://www.opengis.net/sos/1.0"
    xmlns:om="http://www.opengis.net/om/1.0"
    service="SOS" version="1.0.0" srsName="EPSG:4326">
    <sos:offering>urn:ioos:network:test:all</sos:offering>
    <sos:observedProperty>http://mmisw.org/ont/cf/parameter/wind_speed</sos:observedProperty>
    <sos:responseFormat> text/xml; subtype="om/1.0.0/profiles/ioos_sos/1.0"</sos:responseFormat>
    <sos:resultModel>om:Observation</sos:resultModel>
    <sos:responseMode>inline</sos:responseMode>
</sos:GetObservation>

GetObservation Response

A GetObservation response returns a collection of observations. Each observation is composed of metadata, description of the phenomena being returned (parameter names, units of measure, reference systems) and values.

IOOS has developed a series of templates for GetObservation response. In general, IOOS considers GetObservation response as consisted of common generic metadata part and result block. The former contains generic, independent of feature type, metadata that describes features and observations, whereas the result block is a SWE Data Record construct that contains the values defined in the first part of the response.

Since the common metadata parts of any GetObservation response are practically the same, IOOS has developed a single OM-GetObservation template for that part of the response. However, the result block is noticeably different depending on the feature type, and therefore IOOS has developed five individual SWE-GetObservation templates for various combinations of Milestone 1.0 feature types (i.e. TimeSeries and TimeSeriesProfile), single and multiple stations, and availability of information about data quality (QC):

• SWE-MultiStation-TimeSeries
• SWE-MultiStation-TimeSeries_QC
• SWE-SingleStation-SingleProperty-TimeSeries
• SWE-SingleStation-TimeSeriesProfile
• SWE-SingleStation-TimeSeriesProfile_QC

Only critical templates’ components are discussed hereinafter just in order to limit the size of the document; however, all necessary measures were taken to ensure that template description completeness has not suffered. At any rate, the templates are well commented, and can provide a lot of needed information themselves.

OM-GetObservation Template

The outline of the OM-GetObservation template is presented below:

<om:ObservationCollection>
    <gml:metaDataProperty xlink:title="disclaimer">
                            A human-readable disclaimer if considered useful
    </gml:metaDataProperty>
    <gml:metaDataProperty xlink:title="ioosTemplateVersion"
                            A version of the IOOS Template used in this document
    </gml:metaDataProperty>
    <om:member>
                            Contains all observation offerings for the same feature type (e.g. timeSeries)
        <om:Observation>
            <gml:description>
                            A human-readable description of the observation. Should include station(s) name and location
                            as well as sensor or procedure information if possible                             
            </gml:description>
            <om:samplingTime>
                            Descrition of the time range over which the reported observations from a sensor or station exist
            </om:samplingTime>
            <om:procedure>
                            List of all stations (sensor systems) for which observations are reported
            </om:procedure>
            <om:observedProperty>
                            List of the phenomena for which observations are reported
            </om:observedProperty>
            <om:featureOfInterest>
                    <gml:metaDataProperty>
                            Description of the CF Feature Type (discrete-sampling-geometry), e.g. timeSeries                    
                    </gml:metaDataProperty>
                    <gml:boundedBy>
                            Description of the geographic (lat/ lon) Bounding Box of the feature                   
                    </gml:boundedBy>
                    <gml:location>
                            List of geographical positions of the stations that fall inside the Bounding Box
                    </gml:location>
            </om:featureOfInterest>
            <om:result>
                            SWE document conforming to one of the Milestone 1.0 SWE-GetObservation templates
            <om:result>
        </om:Observation>
    </om:member>
            […]
    <om:member>
                            Contains all observation offerings for another feature type (e.g. timeSeriesProfile)
    </om:member>
</om:ObservationCollection>

<om:procedure>
  <om:Process>
    <gml:member xlink:href="urn:ioos:station:wmo:41001"/>
    <gml:member xlink:href="urn:ioos:station:wmo:41002"/>
  </om:Process>
</om:procedure>

<om:observedProperty>
  <swe:CompositePhenomenon dimension="4" gml:id="observedproperties1">
      <gml:name>Response Observed Properties</gml:name>
      <swe:component xlink:href="http://mmisw.org/ont/cf/parameter/air_temperature"/>
      <swe:component xlink:href="http://mmisw.org/ont/cf/parameter/wind_speed"/>
      <swe:component xlink:href="http://mmisw.org/ont/cf/parameter/wind_gust"/>
      <swe:component xlink:href="http://mmisw.org/ont/ioos/parameter/dissolved_oxygen"/>
  </swe:CompositePhenomenon>
</om:observedProperty>

<om:observedProperty>
    <swe:CompositePhenomenon dimension="1" gml:id="observedproperties1">
        <gml:name>Response Observed Properties</gml:name>
        <swe:component xlink:href="http://mmisw.org/ont/cf/parameter/air_temperature"/>
    </swe:CompositePhenomenon>
</om:observedProperty>

<om:featureOfInterest>
    <gml:FeatureCollection>
        <gml:metaDataProperty/>
        <gml:boundedBy/>
        <gml:location/>
    </gml:FeatureCollection>
</om:featureOfInterest>

<gml:metaDataProperty>
  <gml:name codeSpace="http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-conventions.html#discrete-sampling-geometries">
     timeSeries
  </gml:name>
</gml:metaDataProperty>

SWE-GetObservation Template

The OGC SWE Common Data Model Encoding Standard v2.0 allows data components to be used as a data container as well as a data descriptor, where container defines metadata of a data set and includes the actual property values (“inline” values), while data descriptor defines metadata of a data set but does not include the actual data values. However, the Standard prohibits mixing of both guises in a single data component entity. For example, a single DataArray cannot contain both inline values and block-encoded values. Therefore, the IOOS Convention requires a Result block to include a root DataRecord composed of two basic fields – “stations” and “observationData”. The field “stations” forms a “static” part of the GetObservation response Result block that encompasses all invariable data for all stations and sensors, whereas the field “observationData” draws up a “dynamic” part that encloses observation values varying from sensor to sensor. All data components in the static block must be used as data containers and encoded inline, while the data components in the dynamic block must be used only as data descriptors, and contain a DataArray with block-encoded values:

<swe2:DataRecord definition="http://mmisw.org/ont/ioos/swe_element_type/observationRecord">
    <swe2:field name="stations">
        <swe2:DataRecord definition="http://mmisw.org/ont/ioos/swe_element_type/stations">
             [ STATIC DATA ]
        </swe2:DataRecord>
    </swe2:field>
    <swe2:field name="observationData">
        <swe2:DataArray definition="http://mmisw.org/ont/ioos/swe_element_type/sensorObservationCollection">
             [ DYNAMIC DATA (SENSOR OBSERVATIONS) ]
        </swe2:DataArray>
    </swe2:field>
</swe2:DataRecord>

The IOOS Convention requires that each of the following elements in the Result block is provided with a corresponding “definition” attribute:

• <swe2:DataRecord>
• <swe2:DataArray>
• <swe2:DataChoice>
• <swe2:Text>
• <swe2:Vector>
• <swe2:Quantity>
• <swe2:QuantityRange>
• <swe2:Time>

The “definition” attribute identifies the observed property that the data component represents by using a name. The OGC SWE Common Data Model Encoding Standard v2.0 requires it to map to a controlled term defined in a web accessible dictionary, registry or ontology. The IOOS Convention defines the following vocabularies that have to be used in the “definition” attribute:

• OGC Definition Service – an OGC register of potentially observable property types and names that is controlled and maintained by the OGC Naming Authority;
• IOOS Vocabulary and Category Definitions – an MMI vocabulary used for clarifying the meaning of roles, classifiers and other general terms used throughout the SOS web services;
• IOOS SOS SWE Element Definitions Vocabulary – a narrower MMI vocabulary of definitions that reflect the IOOS Convention for use in standard SOS SWE elements.

The value of the “definition” attribute of the same type of element may vary depending on the observed property. The IOOS SWE Templates for Milestone 1.0 along with the MMI vocabularies provide a comprehensive guidance for a use of definitions in IOOS SOS GetObservations document; some examples are shown below:

<swe2:DataRecord   definition="http://mmisw.org/ont/ioos/swe_element_type/stations">
<swe2:DataRecord   id="stationID"   definition="http://mmisw.org/ont/ioos/swe_element_type/station">
<swe2:Text   definition="http://mmisw.org/ont/ioos/definition/stationID">
<swe2:Vector   definition=”http://www.opengis.net/def/property/OGC/0/PlatformLocation”>
<swe2:Quantity   definition=”http://mmisw.org/ont/cf/parameter/latitude”>
<swe2:Quantity   definition=”http://mmisw.org/ont/cf/parameter/height”>
<swe2:DataRecord   definition="http://mmisw.org/ont/ioos/swe_element_type/sensors">
<swe2:DataRecord   id="s"   definition="http://mmisw.org/ont/ioos/swe_element_type/sensor">
<swe2:Text   definition="http://mmisw.org/ont/ioos/definition/sensorID">
<swe2:DataArray   definition="http://mmisw.org/ont/ioos/swe_element_type/sensorObservationCollection">
<swe2:Time   definition="http://www.opengis.net/def/property/OGC/0/SamplingTime">
<swe2:Vector   definition="http://www.opengis.net/def/property/OGC/0/SensorOrientation">
<swe2:QuantityRange   axisID="Z"   definition="http://mmisw.org/ont/ioos/swe_element_type/profileBinEdges">
<swe2:Quantity   definition=”http://mmisw.org/ont/cf/parameter/height”>
<swe2:DataRecord   definition="http://mmisw.org/ont/ioos/swe_element_type/sensorObservations">
<swe2:DataChoice   definition="http://mmisw.org/ont/ioos/swe_element_type/sensors">
<swe2:DataArray   definition="http://mmisw.org/ont/ioos/swe_element_type/profileBins">
<swe2:DataArray   definition="http://mmisw.org/ont/ioos/swe_element_type/profileHeights">

To ensure the proper linkage between the static and dynamic data, the IOOS Convention requires that each sensor’s ID in the static portion of the result block is linked to sensor observation values (i.e., dynamic data) via an abbreviated sensor URN. That abbreviated URN is composed of the authority, label and component parts of a full sensor’s ID (see the IOOS Conventions for Observing Asset Identifiers) separated with underscores instead of the colons, e.g. sensorID urn:ioos:sensor:wmo:41001:sensor1 gets transformed into wmo_41001_sensor1. These abbreviated sensor URNs are used as the sensor’s DataRecord ID in the static block and DataChoice item name in the dynamic block. Consequently they also appears in the dynamic <swe:values> encoding, and may thus be used as a marker for the metadata of a given row of the data block.

In a similar manner, an abbreviated station ID is composed of the authority and label parts of a full station ID, i.e. the stationID urn:ioos:sensor:wmo:41001 transforms into wmo_41001. The abbreviated station IDs have to be used as the station’s DataRecord ID and correspondent field names.

Static Data Block

The static information for all stations and sensors in GetObservation response is encompassed within the field “stations” of the root DataRecord element. Each DataRecord’s field may recursively enclose an unlimited number of DataRecords, which makes the static data block a pretty complex structure of nested DataRecords in case of multiple stations and/or sensors, as shown in Figure 8.

Figure 8: GetObservation static data block outline

In general, IOOS Convention does not prescribe how data should be allocated to the static and dynamic parts, i.e. almost any element may be considered as static or dynamic. However, the static part must include stationID, platformLocation, and sensors description fields for each station:

<swe2:field name="stations">
  <swe2:DataRecord definition="http://mmisw.org/ont/ioos/definition/stations">
    <swe2:field name="wmo_41001">
      <swe2:DataRecord id="wmo_41001" definition="http://mmisw.org/ont/ioos/definition/station">
        <swe2:field name="stationID">
                    An identifier for the platform in a form of URN that conforms to the IOOS Conventions for Observing Asset Identifiers .
        </swe2:field>
        <swe2:field name="platformLocation">
                    The three-dimensional description of the platform’s location, expressed in latitude, longitude and altitude (height).
                    It may also be described in a dynamic part, if varies from observation to observation.
        </swe2:field>
        <swe2:field name="sensors">
          <swe2:DataRecord definition="http://mmisw.org/ont/ioos/definition/sensors">
            <swe2:field name="wmo_41001_sensor1">
              <swe2:DataRecord id="wmo_41001_sensor1" definition="http://mmisw.org/ont/ioos/definition/sensor">
                <swe2:field name="sensorID">
                    An identifier for the sensor in a form of URN that conforms to the IOOS Conventions for Observing Asset Identifiers.
                    It may either use a meaningful name (e.g. "sbe16") or be just a simple, constant string followed by an integer counter such as "sensor1", "sensor2", "salt1", etc.
                </swe2:field>
                <swe2:field name="height">
                    The vertical position of the non-profiling sensor relative to the platformLocation.
                    It may also be described in a dynamic part, if varies among observations.
                </swe2:field>
                <swe2:field name="sensorOrientation">
                    Optional vector parameter, recommended for a profiling sensor such as an ADCP.
                    Indicates the values of sensor’s yaw, pitch, and roll angles.
                    The angles can also be described in a dynamic part, if they vary among observations.
                </swe2:field>
                <swe2:field name="sensorLocation">
                    Describes a profiling sensor position relative to the CRS instead of the platform local frame.
                </swe2:field>
                <swe2:field name="profileBins">
                    Specifies vertical positions of the center and edges for each bin of the binned profile.
                </swe2:field>
                <swe2:field name="profileHeights">
                    Specifies fixed vertical observation positions for a non-binned profile.
                </swe2:field>
              </swe2:DataRecord>
            </swe2:field>
          </swe2:DataRecord>
        </swe2:field>
      </swe2:DataRecord>
    </swe2:field>
  </swe2:DataRecord>
</swe2:field>

The IOOS Convention requires that stationID or sensorID is described in the <swe2:Text> element rather than in <swe2:Category>. The value of the <swe2:Text> must be a full station URN as defined in the IOOS Conventions for Observing Asset Identifiers, as shown in the examples below:

<swe2:field name="stationID">
    <swe2:Text definition="http://mmisw.org/ont/ioos/definition/stationID">
        <swe2:value>urn:ioos:station:wmo:41001</swe2:value>
    </swe2:Text>
</swe2:field>

<swe2:field name="sensorID">
    <swe2:Text definition="http://mmisw.org/ont/ioos/definition/sensorID">
        <swe2:value>urn:ioos:sensor:wmo:41001:sensor1</swe2:value>
    </swe2:Text>
</swe2:field>

The IOOS Convention requires that description of each sensor’s position encompasses three components:

1. description of a Platform Location specified within a global Reference Frame;
2. description of the Local Frame assigned to the platform; and
3. description of the sensor position relative to the platform’s Local Frame.

Depending on the platform type, IOOS Convention specifies two global Reference Frames:

• for floating buoys, the referenceFrame is a 3D Compound CRS that combines EPSG::4326 for the platform horizontal coordinates with EPSG::5829 vertical CRS for the platform’s vertical coordinate (referenceFrame=”http://www.opengis.net/def/crs-compound?1=http://www.opengis.net/def/crs/EPSG/0/4326&2=http://www.opengis.net/def/crs/EPSG/0/5829);
• for a tide gauge or a platform at a fixed location relative to the Geoid (MSL), a single 3D CRS EPSG::4979 has to be used. (referenceFrame=”http://www.opengis.net/def/crs/EPSG/0/4979”).

The following fragment of the IOOS Milestone 1.0 Template illustrates the platform’s location description:

<swe2:field name="platformLocation">
  <swe2:Vector definition="http://www.opengis.net/def/property/OGC/0/PlatformLocation"
    referenceFrame="http://www.opengis.net/def/crs-compound?1=http://www.opengis.net/def/crs/EPSG/0/4326&2=http://www.opengis.net/def/crs/EPSG/0/5829"
    localFrame="#wmo_41001_frame">
      <swe2:coordinate name="latitude">
        <swe2:Quantity definition="http://mmisw.org/ont/cf/parameter/latitude" axisID="Lat">
          <swe2:uom code="deg"/>
          <swe2:value>32.382</swe2:value>
        </swe2:Quantity>
      </swe2:coordinate>
      <swe2:coordinate name="longitude">
        <swe2:Quantity definition="http://mmisw.org/ont/cf/parameter/longitude" axisID="Lon">
          <swe2:uom code="deg"/>
          <swe2:value>-75.415</swe2:value>
        </swe2:Quantity>
      </swe2:coordinate>
      <swe2:coordinate name="height">
        <swe2:Quantity definition="http://mmisw.org/ont/cf/parameter/height" axisID="Z">
          <swe2:uom code="m"/>
          <swe2:value>0.5</swe2:value>
        </swe2:Quantity>
      </swe2:coordinate>
  </swe2:Vector>
</swe2:field>

In regard to the position of the sensors located at the platform, the IOOS Convention only requires that sensor height relative to the platform’s localFrame is specified for a non-profiling sensor. Regardless of platform’s sensors allocation in reference to the water surface, the IOOS Convention stipulates that position description should follow the EPSG:5829, i.e.

• sensor’s position should always be reported as height (vertical upward); and
• sensor’s position below the water surface should be reported as height with negative value.

The following fragment of the IOOS Milestone 1.0 Template illustrates just that simplified approach to sensors’ location description; if more information about sensor orientation and relative position is available, then it must be recorded in accordance with the SWE Common v2.0 specification:

<swe2:field name="height">
    <swe2:Quantity definition="http://mmisw.org/ont/cf/parameter/height"
        axisID="Z"
        referenceFrame="#wmo_41001_frame">
        <swe2:uom code="m" />
        <swe2:value>5</swe2:value>
    </swe2:Quantity>
</swe2:field>

Common QA/QC information

It has been a long-standing IOOS’ goal to implement the principles of Quality Assurance of Real Time Ocean Data (QARTOD) in the IOOS SOS, and the IOOS Convention has taken a first step in that direction by providing a guidance (based on the best practices of the IOOS data providers like NDBC) of reporting QA/QC information in the Milestone 1.0 templates. However, since the QARTOD has yet to develop the authoritative QA/QC procedures for all IOOS observed properties and feature types, the IOOS Convention provisions are not mandatory at the moment, and Milestone 1.0 templates should be considered as sort of “best practices” recommendations, mostly based on the NDBC’s system of pre-defined QA/QC flags (tockens).

The static data block in GetObservations document may include any common QA/QC information on the station or sensor that is invariable among the observations:  

<swe2:field name="stationID">
  <swe2:Text definition="http://mmisw.org/ont/ioos/definition/stationID">

    <swe2:quality>
                  Any valid static quality information about this station can be placed here.
    </swe2:quality>

    <swe2:value>urn:ioos:station:wmo:41001</swe2:value>
  </swe2:Text>
</swe2:field>

<swe2:field name="sensorID">
  <swe2:Text definition="http://mmisw.org/ont/ioos/definition/sensorID">

    <swe2:quality>
                  Any valid static quality information about this sensor can be placed here.
    </swe2:quality>

    <swe2:value>urn:ioos:station:wmo:41001:sensor2</swe2:value>
  </swe2:Text>
</swe2:field>

Profiling sensor specifics

For profiling sensor, just the indication of the sensor’s upward or downward shift relative to the platform position is not sufficient, and the IOOS Convention provides for more precise description of sensor’s position and orientation, including description of bins and depths for binned profile sensors. Although the Convention does not require a full description of a sensor’s orientation, the Convention strongly encourages the indication of this information for all vertical profiling sensors (e.g. ADCP).

The IOOS Convention specifies a position of a profiling sensor in reference to a CRS rather than to the platform itself, just because the relative sensor’s position in the platform’s localFrame is likely to vary from observation to observation, whereas the absolute coordinates (i.e. latitude, longitude, and height) may be approximated as static. The sensor’s localFrame is referenced to the CRS similar to the the platform’s localFrame:

<swe2:field name="sensorLocation">    
  swe2:Vector definition=http://www.opengis.net/def/property/OGC/0/SensorLocation
  referenceFrame="http://www.opengis.net/def/crs-compound?1=http://www.opengis.net/def/crs/EPSG/0/4326&2=http://www.opengis.net/def/crs/EPSG/0/5829"
  localFrame="#wmo_41001_sensor1_profile_frame">
    <swe2:coordinate name="latitude">
      <swe2:Quantity definition="http://mmisw.org/ont/cf/parameter/latitude" axisID="Lat">
        <swe2:uom code="deg" />
        <swe2:value>32.382</swe2:value>
      </swe2:Quantity>
    </swe2:coordinate>
    <swe2:coordinate name="longitude">
      <swe2:Quantity definition="http://mmisw.org/ont/cf/parameter/longitude" axisID="Lon">
        <swe2:uom code="deg" />
        <swe2:value>-75.415</swe2:value>
      </swe2:Quantity>
    </swe2:coordinate>
    <swe2:coordinate name="height">
      <swe2:Quantity definition="http://mmisw.org/ont/cf/parameter/height" axisID="Z">
        <swe2:uom code="m" />
        <swe2:value>0.0</swe2:value>
      </swe2:Quantity>
    </swe2:coordinate>
  </swe2:Vector>
</swe2:field>

The sensor’s orientation is reported in terms of the pitch, roll, and yaw angles using the CF Conventions standard names: platform_pitch_angle, platform_roll_angle, and platform_orientation for yaw angle; the Figure 9 depicts a relation of the directional vectors and orientation angles.

Figure 9: Directions, Yaw, Pitch and Roll Angles (copied from Wikipedia)

The following fragment of the IOOS Milestone 1.0 GetObservation Template for timeSeriesProfile provides more detailed guidance for the sensor orientation description:

<swe2:field name="sensorOrientation">
  <swe2:Vector definition="http://www.opengis.net/def/property/OGC/0/SensorOrientation"
    referenceFrame="http://www.opengis.net/def/crs/OGC/0/ENU">
    <swe2:coordinate name="platform_orientation">
      <swe2:Quantity definition="http://mmisw.org/ont/cf/parameter/platform_orientation"
        axisID="Z">
        <swe2:uom code="deg" />
        <swe2:value>0</swe2:value>
      </swe2:Quantity>
    </swe2:coordinate>
    <swe2:coordinate name="platform_pitch_angle">
      <swe2:Quantity definition="http://mmisw.org/ont/cf/parameter/platform_pitch_angle"
        axisID="X">
        <swe2:uom code="deg" />
        <swe2:value>90</swe2:value>
      </swe2:Quantity>
    </swe2:coordinate>
    <swe2:coordinate name="platform_roll_angle">
      <swe2:Quantity definition="http://mmisw.org/ont/cf/parameter/platform_roll_angle"
        axisID="Y">
        <swe2:uom code="deg" />
        <swe2:value>0</swe2:value>
      </swe2:Quantity>
    </swe2:coordinate>
  </swe2:Vector>
</swe2:field>

If sensor position or orientation is not stable in time, and differs with each individual observation, it has to be described in the dynamic data block of the GetObservation document instead of the static data block. In such case, the orientation parameter values must be block-encoded along with other observations data.

For binned profiling sensors, the IOOS Convention specifies bins and depths through the description of the vertical positions of each bin center with corresponding top and bottom edges. Despite the fact that the binned profile description is located in the static data block, the bins’ and depths’ values must not be encoded inline but shall be encoded as a data array (i.e. block-encoded) instead. To allow for ragged arrays of data from upward looking ADCP sensors, the dimension of the array shall correspond to the number of binned observations for this sensor reported in the dynamic data section:

<swe2:field name="profileBins">
    <swe2:DataArray definition="http://mmisw.org/ont/ioos/swe_element_type/profileBins">
        <swe2:description>Array of synchronous observation locations in a profile</swe2:description>
        <swe2:elementCount>
            <swe2:Count>
                <swe2:value>5</swe2:value>
            </swe2:Count>
        </swe2:elementCount>
        <swe2:elementType name="profileBinDescription">
            <swe2:DataRecord>
                <swe2:field name="binCenter">
                    <swe2:Quantity axisID="Z"
                        definition="http://mmisw.org/ont/cf/parameter/height"
                        referenceFrame="#wmo_41001_sensor1_frame">
                        <swe2:uom code="m" />
                    </swe2:Quantity>
                </swe2:field>
                <swe2:field name="binEdges">
                    <swe2:QuantityRange axisID="Z"
                        definition="http://mmisw.org/ont/ioos/swe_element_type/profileBinEdges"
                        referenceFrame="#wmo_41001_sensor1_frame">
                        <swe2:uom code="m" />
                    </swe2:QuantityRange>
                </swe2:field>
            </swe2:DataRecord>
        </swe2:elementType>
        <swe2:encoding>
            <swe2:TextEncoding
                decimalSeparator="."
                tokenSeparator=","
                blockSeparator="&#10;" />
        </swe2:encoding>
        <swe2:values>
            -10.0,-5.0 -15.0
            -20.0,-15.0 -25.0
            -30.0,-25.0 -35.0
            -40.0,-35.0 -45.0
            -50.0,-45.0 -55.0
        </swe2:values>
    </swe2:DataArray>
</swe2:field>

For non-binned profiling sensors, the IOOS Convention requires a description of the fixed vertical observation positions instead of bins. Similar to the description of binned sensors, it is done in a form of data array with the dimension that shall correspond to the number of observations for this sensor reported in the dynamic data section:

<swe2:field name="profileHeights">
    <swe2:DataArray definition="http://mmisw.org/ont/ioos/definition/profileHeights">
        <swe2:elementCount>
            <swe2:Count>
                <swe2:value>3</swe2:value>
            </swe2:Count>
        </swe2:elementCount>
        <swe2:elementType name="profileDefinition">
            <swe2:DataRecord>
                <swe2:field name="height">
                    <swe2:Quantity axisID="Z"
                        definition="http://mmisw.org/ont/cf/parameter/height"
                        referenceFrame="#wmo_41001_sensor2_profile_frame">
                        <swe2:uom code="m" />
                    </swe2:Quantity>
                </swe2:field>
            </swe2:DataRecord>
        </swe2:elementType>
        <swe2:encoding>
            <swe2:TextEncoding
                decimalSeparator="."
                tokenSeparator=","
                blockSeparator="&#10;" />
        </swe2:encoding>
        <swe2:values>
            -5.0
            -10.0
            -20.0
        </swe2:values>
    </swe2:DataArray>
</swe2:field>

Dynamic Data Block (Sensor Observations)

The dynamic data block contains all measurements made by sensors and any other dynamic data (e.g. location for mobile sensors) from each sensor requested in GetObservation operation. In conformity with the OGC SWE Common Data Model Encoding Standard v2.0, the dynamic block must not contain any inline encoded data.

The simplified outline of the dynamic data block is presented below. The outline contains all the required elements with a brief description; the detailed description of the critical elements follows:

<swe2:field name="observationData">
    <swe2: DataArray definition="http://mmisw.org/ont/ioos/definition/sensorObservationCollection">
        <swe2:elementCount>
                        Defines the number of array components, i.e. the number of records in <swe2:values> below.
        </swe2:elementCount>
        <swe2:elementType name="observations">
            <swe2:DataRecord definition="http://mmisw.org/ont/ioos/definition/sensorObservations">
                          The root dynamic data record that contains all dynamic observation descriptors for each sensor.
                <swe2:field name="time">
                          The samplingTime, which defines the instants of time when observations were taken.
                </swe2:field>
                <swe2:field name="sensor">
                          Defines the dynamic data for all reported sensors via DataChoice element.
                    <swe2:DataChoice definition="http://mmisw.org/ont/ioos/definition/sensors">
                        <swe2:item name="wmo_41001_sensor1">
                                         Defines observedProperties for the “sensor1” located at the station “wmo_41001”
                            <swe2:DataRecord definition="http://mmisw.org/ont/ioos/definition/sensor">
                                <swe2:field name="air_temperature"/>
                                <swe2:field name="wind_speed"/>
                                <swe2:field name="wind_to_direction"/>
                            </swe2:DataRecord>
                        </swe2:item>
                        <swe2:item name="wmo_41001_sensor2">
                                         Defines observedProperties for the “adcpProfile_sensor2” located at the station “wmo_41001”
                            <swe2:DataRecord definition="http://mmisw.org/ont/ioos/definition/sensor">
                                <swe2:field name="adcpProfile">
                                         Contains nested DataArray for profile dynamic data to encode observations
                                         at multiple heights in one record
                                    <swe2:DataArray definition="http://mmisw.org/ont/ioos/definition/profile">
                                        <swe2:description>Array of synchronous observations in a Profile</swe2:description>
                                    </swe2:DataArray definition="http://mmisw.org/ont/ioos/definition/profile">
                                <swe2:field name="adcpProfile">
                            </swe2:DataRecord>
                        </swe2:item>
                        <swe2:item name="wmo_41002_sensor1">
                                         Defines observedProperties for the “sensor1” located at the station “wmo_41002”
                            <swe2:DataRecord definition="http://mmisw.org/ont/ioos/definition/sensor">
                                <swe2:field name="air_temperature"/>
                            </swe2:DataRecord>
                        </swe2:item>
                        <swe2:item name="wmo_41002_sensor2">
                                         Defines observedProperties for the “sensor2” located at the station “wmo_41002”
                            <swe2:DataRecord definition="http://mmisw.org/ont/ioos/definition/sensor">
                                <swe2:field name="sea_water_temperature"/>
                            </swe2:DataRecord>
                        </swe2:item>
                        <swe2:item name="wmo_41003_sensor1">
                                         Defines observedProperties for the “sensor1” located at the station “wmo_41003”
                            <swe2:DataRecord definition="http://mmisw.org/ont/ioos/definition/sensor">
                                <swe2:field name="air_temperature"/>
                            </swe2:DataRecord>
                        </swe2:item>
                    </swe2:DataChoice>
                </swe2:field>
            </swe2:DataRecord>
        <swe2:encoding>
                          Defines used SWE Common encodings, including data value separators
        </swe2:encoding>

        <swe2:values>
                          Encompasses data values from all sensors for all sampling time instances.
        </swe2:values>
    <swe2: DataArray>
<swe2:field>

The time field of the observations’ DataRecord is listed outside of DataChoice construct just because sampling time is related to all sensors; however, if sampling time is defined differently for some sensors it should be reported inside the respective DataChoice <swe2:item> element. The sampling time must be encoded as an ISO8601 UTC (Z) TimeInstant string:

<swe2:field name="time">
  <swe2:Time definition="http://www.opengis.net/def/property/OGC/0/SamplingTime">
    <swe2:uom xlink:href="http://www.opengis.net/def/uom/ISO-8601/0/Gregorian" />
  </swe2:Time>
<swe2:field>

An implementation of missing or out-of-range values is completely arbitrary; however, the implementation must follow the SWECommon standard requirements. In general, a <swe2:Quantity> may contain any number of <swe:nilValue> elements for any nilValue reason, for example:

<swe2:Quantity definition="http://mmisw.org/ont/cf/parameter/air_temperature">
    ...
    <swe2:nilValues>
        <swe2:NilValues>
            <swe2:nilValue reason="http://www.opengis.net/def/nil/OGC/0/BelowDetectionRange">-9999</swe2:nilValue>
            <swe2:nilValue reason="http://www.opengis.net/def/nil/OGC/0/AboveDetectionRange">9999</swe2:nilValue>
            <swe2:nilValue reason="http://www.opengis.net/def/nil/OGC/0/OutOfService">-1</swe2:nilValue>
            <swe2:nilValue reason="http://www.opengis.net/def/nil/OGC/0/missing">8888</swe2:nilValue>
        </swe2:NilValues>
    </swe2:nilValues>
    ...
</swe2:Quantity>

As each sensor may perform various set of observations, the IOOS Convention requires that DataChoice structure is used to select a sensor and the set of observation fields to be reported in each record for that sensor in the <swe2:values> element of the DataArray. To ensure the proper linkage to the static data block, the item names must correspond to the sensor names in the static sensors’ DataRecord. Each DataChoice <swe2:item> element describes the dynamic sensor features such as observedProperty, UoM, etc. in a separate DataRecord:

<swe2:field name=”sensor”>
    <swe2:DataChoice definition="http://mmisw.org/ont/ioos/definition/sensors">
        <swe2:item name="wmo_41001_sensor1">
            <swe2:DataRecord definition="http://mmisw.org/ont/ioos/definition/sensor">
                <swe2:field name="air_temperature">
                    <swe2:Quantity definition="http://mmisw.org/ont/cf/parameter/air_temperature">
                        <swe2:uom code="Celsius" />
                    </swe2:Quantity>
                </swe2:field>
                <swe2:field name="wind_speed">
                    <swe2:Quantity definition="http://mmisw.org/ont/cf/parameter/wind_speed">
                        <swe2:uom code="m/s" />
                    </swe2:Quantity>
                </swe2:field>
                <swe2:field name="wind_to_direction">
                    <swe2:Quantity definition="http://mmisw.org/ont/cf/parameter/wind_to_direction">
                        <swe2:uom code="degrees" />
                    </swe2:Quantity>
                </swe2:field>
            </swe2:DataRecord>
        </swe2:item>
        <swe2:item name="wmo_41001_sensor2">
            <swe2:DataRecord definition="http://mmisw.org/ont/ioos/definition/sensor">
                <swe2:field name="sea_water_temperature">
                    <swe2:Quantity definition="http://mmisw.org/ont/cf/parameter/sea_water_temperature">
                        <swe2:uom code="Celsius" />
                    </swe2:Quantity>
                </swe2:field>
                <swe2:field name="dissolved_oxygen">
                    <swe2:Quantity definition="http://mmisw.org/ont/ioos/parameter/dissolved_oxygen">
                        <swe2:uom code="mg/L" />
                    </swe2:Quantity>
                </swe2:field>
            </swe2:DataRecord>
        </swe2:item>
        <swe2:item name="wmo_41002_sensor1">
            <swe2:DataRecord definition="http://mmisw.org/ont/ioos/definition/sensor">
                <swe2:field name="air_temperature">
                    <swe2:Quantity definition="http://mmisw.org/ont/cf/parameter/air_temperature">
                        <swe2:uom code="Celsius" />
                    </swe2:Quantity>
                </swe2:field>
            </swe2:DataRecord>
        </swe2:item>
        <swe2:item name="wmo_41002_sensor2">
            <swe2:DataRecord definition="http://mmisw.org/ont/ioos/definition/sensor">
                <swe2:field name="sea_water_temperature">
                    <swe2:Quantity definition="http://mmisw.org/ont/cf/parameter/sea_water_temperature">
                        <swe2:uom code="Celsius" />
                    </swe2:Quantity>
                </swe2:field>
            </swe2:DataRecord>
        </swe2:item>
        <swe2:item name="wmo_41003_sensor1">
            <swe2:DataRecord definition="http://mmisw.org/ont/ioos/definition/sensor">
                <swe2:field name="air_temperature">
                    <swe2:Quantity definition="http://mmisw.org/ont/cf/parameter/air_temperature">
                        <swe2:uom code="Celsius" />
                    </swe2:Quantity>
                </swe2:field>
            </swe2:DataRecord>
        </swe2:item>
    </swe2:DataChoice>
</swe2:field>

The <swe2:encoding> element defines all kinds of separators that are used for records and values in the <swe2:values> block. To facilitate the development of the SOS client applications, the IOOS Convention requires that the <swe2:encoding> element has always be included into GetObservation response, and strongly recommends to use the standard CSV separators, such as “.” for decimal separation, “,” for tockens, and LF (Line Feed) – for blocks separation. At that, the special ASCII symbols used in the capacity of separators must be encoded with the corresponding standard HTML Escape Sequences; for example, LF (Line Feed) separator must be replaced with “\ ”:

<swe2:encoding>
    <swe2:TextEncoding
        decimalSeparator="."
        tokenSeparator=","
        blockSeparator="&#10;" />
</swe2:encoding>

The <swe2:values> block must report the observedProperty values in the exact order they were defined in the previous sections of the dynamic data block. The number of records must match the value of <swe2:elementCount>; each record must contain the observation sampling time, name of the sensor, and the observed values as defined in the DataChoice <swe2:item> element associated with that sensor.

The IOOS Convention requires that, in contrast to the <swe2:TextEncoding> element above, the special characters used as separators stay unencoded in the <swe2:values> block, e.g. Line Feed must not be converted into” ” but must be used as-is instead. The IOOS Convention also requires that the sensor names unambiguously correspond to the names used in the DataChoice <swe2:item> elements:

<swe2:values>
            2009-05-23T00:00:00Z,wmo_41001_sensor1,15.4,2.0,280
            2009-05-23T01:00:00Z,wmo_41001_sensor1,15.8,1.8,121
            2009-05-23T02:00:00Z,wmo_41001_sensor1,15.6,1.0,142
            2009-05-23T00:00:00Z,wmo_41001_sensor2,5.6,8.0
            2009-05-23T01:00:00Z,wmo_41001_sensor2,5.8,8.2
            2009-05-23T02:00:00Z,wmo_41001_sensor2,5.7,8.5
            2009-05-23T00:00:00Z,wmo_41002_sensor1,16.2
            2009-05-23T01:00:00Z,wmo_41002_sensor1,16.4
            2009-05-23T02:00:00Z,wmo_41002_sensor1,16.5
            2009-05-23T00:00:00Z,wmo_41002_sensor2,6.1
            2009-05-23T01:00:00Z,wmo_41002_sensor2,6.3
            2009-05-23T02:00:00Z,wmo_41002_sensor2,6.5
            2009-05-23T01:00:00Z,wmo_41003_sensor1,15.8
</swe2:values>

Observation-specific QA/QC information

The dynamic data block of GetObservation response may contain observation specific QA/QC information, encoded in the same DataArray with other observation values.

The QA/QC flags pertaining to all observed properties for a certain sensor may be described in <swe2:elementCount> element of the DataArray definition that precedes a description of observations <swe2:elementType>:

<swe2:DataArray definition="http://mmisw.org/ont/ioos/definition/sensorObservationCollection">
    <swe2:elementCount>
        <swe2:Count>
            <swe2:quality>
                <swe2:Category>
                    <swe2:constraint>
                        <swe2:AllowedTokens>
                            <swe2:value>a</swe2:value>
                            <swe2:value>b</swe2:value>
                            <swe2:value>c</swe2:value>
                        </swe2:AllowedTokens>
                    </swe2:constraint>
                </swe2:Category>
            </swe2:quality>
            <swe2:value>13</swe2:value>
        </swe2:Count>
    </swe2:elementCount>
    <swe2:elementType name="observations">
      […]
    </swe2:elementType>
      […]
</swe2:DataArray>

The QA/QC flags pertaining to a specific observed property may be described in a similar manner in the corresponding part of the dynamic data block of the GetObservation response. Just like the observed property values, the QA/QC flag definitions must only contain data descriptors, and the flag values must be block-encoded.

In order to define a composite flag that may have several components with various values, multiple <swe2:quality> elements have to be used inside a corresponding <swe2:Quantity> element instead of a single multi-dimensional DataArray as the SWE Common data model prohibits the use of embedded DataArray inside of <swe2:Quantity>. The fragment of the Milestone 1.0 template below illustrates that concept for a 2-component DQA flag; for simplicity, the second DQA component just references the values defined in the description of the first component: 

<swe2:DataArray definition="http://mmisw.org/ont/ioos/definition/sensorObservationCollection">
    […]
    <swe2:elementType name="observations">
        […]
        <swe2:DataRecord definition="http://mmisw.org/ont/ioos/definition/sensorObservations">
            <swe2:field name="sensor">
                <swe2:DataChoice definition="http://mmisw.org/ont/ioos/definition/sensors">
                    <swe2:item name="wmo_41001_sensor1">
                        <swe2:DataRecord definition="http://mmisw.org/ont/ioos/definition/sensor">
                            <swe2:field name="air_temperature">
                                <swe2:Quantity definition="http://mmisw.org/ont/cf/parameter/air_temperature">

                                    <swe2:quality>
                                        <swe2:Category definition="http://sdftest.ndbc.noaa.gov/sos/qcflags.shtml">
                                            <swe2:label>EQC Flag</swe2:label>
                                            <swe2:codeSpace xlink:href="http://sdftest.ndbc.noaa.gov/sos/qcflags.shtml"/>
                                            <swe2:constraint>
                                                <swe2:AllowedTokens id="ndbcEqcFlags">
                                                    <swe2:value>T</swe2:value>
                                                    <swe2:value>M</swe2:value>
                                                    <swe2:value>W</swe2:value>
                                                    <swe2:value>D</swe2:value>
                                                    <swe2:value>S</swe2:value>
                                                    <swe2:value>V</swe2:value>
                                                    <swe2:value>L</swe2:value>
                                                    <swe2:value>H</swe2:value>
                                                    <swe2:value>R</swe2:value>
                                                </swe2:AllowedTokens>
                                            </swe2:constraint>
                                        </swe2:Category>
                                    </swe2:quality>

                                    <swe2:quality>
                                        <swe2:Category definition="http://sdftest.ndbc.noaa.gov/sos/qcflags.shtml">
                                            <swe2:label>DQA Flag 1</swe2:label>
                                            <swe2:codeSpace xlink:href="http://sdftest.ndbc.noaa.gov/sos/qcflags.shtml"/>
                                            <swe2:constraint>
                                                <swe2:AllowedTokens id="ndbcDqaFlags">
                                                    <swe2:value>a</swe2:value>
                                                    <swe2:value>b</swe2:value>
                                                    <swe2:value>d</swe2:value>
                                                    <swe2:value>f</swe2:value>
                                                    <swe2:value>g</swe2:value>
                                                    <swe2:value>i</swe2:value>
                                                    <swe2:value>j</swe2:value>
                                                    <swe2:value>k</swe2:value>
                                                    <swe2:value>m</swe2:value>
                                                    <swe2:value>n</swe2:value>
                                                    <swe2:value>p</swe2:value>
                                                    <swe2:value>q</swe2:value>
                                                    <swe2:value>r</swe2:value>
                                                    <swe2:value>s</swe2:value>
                                                    <swe2:value>t</swe2:value>
                                                    <swe2:value>v</swe2:value>
                                                    <swe2:value>w</swe2:value>
                                                    <swe2:value>x</swe2:value>
                                                    <swe2:value>y</swe2:value>
                                                    <swe2:value>z</swe2:value>
                                                </swe2:AllowedTokens>
                                            </swe2:constraint>
                                        </swe2:Category>
                                    </swe2:quality>

                                    <swe2:quality>
                                        <swe2:Category definition="http://sdftest.ndbc.noaa.gov/sos/qcflags.shtml">
                                            <swe2:label>DQA Flag 2</swe2:label>
                                            <swe2:codeSpace xlink:href="http://sdftest.ndbc.noaa.gov/sos/qcflags.shtml"/>
                                            <swe2:constraint xlink:href="#ndbcDqaFlags"/>
                                        </swe2:Category>
                                    </swe2:quality>
                                    <swe2:uom code="Celsius" />
                                </swe2:Quantity>
                            </swe2:field>
                        </swe2:DataRecord>
                    </swe2:item>
                    […]
                </swe2:DataChoice>
            </swe2:field>
        </swe2:DataRecord>
    </swe2:elementType>

    <swe2:values>
        2009-05-23T00:00:00Z,a,wmo_41001_sensor1,15.4,T,a,r,2.0,280
        2009-05-23T01:00:00Z,b,wmo_41001_sensor1,15.8,M,j,j,1.8,121
        2009-05-23T02:00:00Z,c,wmo_41001_sensor1,15.6,M,,,1.0,142
        2009-05-23T00:00:00Z,a,wmo_41001_sensor2,5.6,8.0
        2009-05-23T01:00:00Z,b,wmo_41001_sensor2,5.8,8.2
        2009-05-23T02:00:00Z,c,wmo_41001_sensor2,5.7,8.5
        2009-05-23T00:00:00Z,a,wmo_41002_sensor1,16.2
        2009-05-23T01:00:00Z,b,wmo_41002_sensor1,16.4
        2009-05-23T02:00:00Z,c,wmo_41002_sensor1,16.5
        2009-05-23T00:00:00Z,a,wmo_41002_sensor2,6.1
        2009-05-23T01:00:00Z,b,wmo_41002_sensor2,6.3
        2009-05-23T02:00:00Z,c,wmo_41002_sensor2,6.5
        2009-05-23T01:00:00Z,a,wmo_41003_sensor1,15.8
    </swe2:values>
</swe2:DataArray>

Profiling sensor observation-specific report

The dynamic data block for profiling sensor has several important specifics that are stipulated by the ability of the sensor to perform a number of simultaneous observations at multiple points of the vertical axis. In order to provide for encoding of multiple simultaneous observations in one record, the IOOS Convention requires the use of a nested DataArray for each profiling sensor description in a DataChoice structure.

The IOOS Convention requires that the dimension of that inner DataArray must never be specified inline in the corresponding <swe2:elementCount>; instead, it must be repeated in each of the <swe2:values> block-encoded records to allow indication of the number of heights being encoded in this record.

The IOOS Convention also requires another <swe2:Count> element in a profileIndex or binIndex field that preceeds each set of observation values to indicate which height/bin is being reported (binIndex and profileIndex must correspond respectively to profileBins or profileHeights in the static data block).

Similar to the non-profiling sensors, the sensor names used in the DataChoice structure must correspond to the sensor names in the static data block; the same names must then be repeated in the <swe2:values> block:

<swe2:DataChoice definition="http://mmisw.org/ont/ioos/definition/sensors">
    <swe2:item name="wmo_41001_sensor1">
        <swe2:DataRecord definition="http://mmisw.org/ont/ioos/definition/sensor">

            <swe2:field name="adcpProfile">
                <swe2:DataArray definition="http://mmisw.org/ont/ioos/definition/profile">
                    <swe2:description>Array of synchronous observations in a Profile</swe2:description>
                    <swe2:elementCount>
                        <swe2:Count />
                    </swe2:elementCount>
                    <swe2:elementType name="profileObservation">
                        <swe2:DataRecord definition="http://mmisw.org/ont/ioos/definition/profileObservation">

                            <swe2:field name="profileIndex">
                                <swe2:Count definition="http://mmisw.org/ont/ioos/definition/profileIndex">
                                    <swe2:constraint>
                                        <swe2:AllowedValues>
                                            <swe2:interval>0 4</swe2:interval>
                                        </swe2:AllowedValues>
                                    </swe2:constraint>
                                </swe2:Count>
                            </swe2:field>

                            <swe2:field name="direction_of_sea_water_velocity">
                                <swe2:Quantity definition="http://mmisw.org/ont/cf/parameter/direction_of_sea_water_velocity">
                                    <swe2:uom code="deg" />
                                </swe2:Quantity>
                            </swe2:field>

                            <swe2:field name="sea_water_speed">
                                <swe2:Quantity definition="http://mmisw.org/ont/cf/parameter/sea_water_speed">
                                    <swe2:uom code="cm/s" />
                                </swe2:Quantity>
                            </swe2:field>

                        </swe2:DataRecord>
                    </swe2:elementType>
                </swe2:DataArray>
            </swe2:field>
        </swe2:DataRecord>
    </swe2:item>

    <swe2:item name="wmo_41001_sensor2">
        <swe2:DataRecord>
            <swe2:field name="thermisterProfile">
                <swe2:DataArray definition="http://mmisw.org/ont/ioos/definition/profile">
                    <swe2:elementCount>
                        <swe2:Count />
                    </swe2:elementCount>
                    <swe2:elementType name="profileObservation">
                        <swe2:DataRecord definition="http://mmisw.org/ont/ioos/definition/profileObservation">

                            <swe2:field name="binIndex">
                                <swe2:Count definition="http://mmisw.org/ont/ioos/definition/profileIndex">
                                    <swe2:constraint>
                                        <swe2:AllowedValues>
                                            <swe2:interval>0 2</swe2:interval>
                                        </swe2:AllowedValues>
                                    </swe2:constraint>
                                </swe2:Count>
                            </swe2:field>

                            <swe2:field name="sea_water_temperature">
                                <swe2:Quantity definition="http://mmisw.org/ont/cf/parameter/sea_water_temperature">
                                    <swe2:uom code="Cel" />
                                </swe2:Quantity>
                            </swe2:field>

                        </swe2:DataRecord>
                    </swe2:elementType>
                </swe2:DataArray>
            </swe2:field>
        </swe2:DataRecord>
    </swe2:item>

</swe2:DataChoice>