Deprecation Notice - This guidance was deprecated by IOOS on 2020-01-10 and is superceded by the IOOS Metadata Profile 1.2. Please read the Deprecation Notice below for more information. Original Summary - Template for a SWE Data Record's static and dynamic fields for a single station with a single sensor
Edit me

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.

<?xml version="1.0" encoding="UTF-8"?>
<!-- This template is an example of a SWE Data Record composed of static and dynamic fields for -->
<!-- a single station with a single sensor. It is a degenerate case of the multi station, multi -->
<!-- sensor template.-->
<!--  -->
<!-- Most any element may be static or dynamic, but the static fields must be encoded inline, while -->
<!-- The dyamic elements must be block encoded in the data array. -->
<!--  -->
<!-- Description of data -->
<!-- SWE DataRecord containing 1 Station: -->
<!-- Station 1 has 1 sensors -->
<!-- This is an example of a degenerate case which requires a dummy item in the data choice since -->
<!-- data choice must have 2 or more items. -->

  <!-- STATIC DATA -->
  <!-- This field "stations" contains static data for all stations and sensors in the response -->
  <!-- Static data is linked to dynamic data (sensor observation values) via an abbreviated, -->
  <!-- underscored sensor URN. For example, urn:ioos:sensor:wmo:41001:sensor1 becomes -->
  <!-- wmo_41001_sensor1 -->
  <!-- This abbreviated URN is used as the sensor's DataRecord id in the static block and the -->
  <!-- DataChoice item name in the dynamic block. Consequently it also appears in the dynamic -->
  <!-- swe:values encoding. And may thus be used as a look up for the metadata of a given row -->
  <!-- of the data block -->
  <!-- All fields in the static block must include inline values. -->
  <!-- All fields in the dynamic block must not include inline values. -->
  <swe2:field name="stations">
    <!-- IoosTech Convention: -->
    <!-- The data record containing the static data for each station shall be defined -->
    <swe2:DataRecord definition="">
      <!-- Static data for the first station, urn:ioos:station:wmo:41001 -->
      <!-- Required elements include for each station: stationID, platformLocation, sensors -->
      <swe2:field name="wmo_41001">
        <!-- IoosTech Convention: -->
        <!-- The data record containing the static data for a station shall be defined -->
        <swe2:DataRecord id="wmo_41001"
          <swe2:field name="stationID">
            <!-- IoosTech Convention: -->
            <!-- The text element containing the station id shall be defined -->
            <swe2:Text definition="">
          <!-- The platformLocation may be defined here, statically, or specified in the dynamic -->
          <!-- section. In either case, all coordinates must be specified inline or block encoded. -->
          <!-- They encoding can not be split to save bandwidth in the response. -->
          <swe2:field name="platformLocation">
            <!-- Field: platformLocation; -->
            <!-- The location of the platform relative to WGS 84 (Horizontal) and Instantaneous Water Level (Vertical). -->
            <!-- Each sensor will specify a height relative to the platform location. If complete orientation and -->
            <!-- relative position are available for a sensor, SWE 2.0 clearly defines how to record it. Generally, -->
            <!-- for IOOS buoy instruments we believe just specifying the height is the appropriate solution. -->
            <swe2:Vector definition=""
              <!-- Vector: -->
              <!-- The coordinate vector defining the station location in the specified reference frame. -->
              <!--  -->
              <!-- For floating, surface buoys a new compound coordinate reference system has been developed -->
              <!-- which combines the WGS84 for horizontal (GPS) latitude and longitude CRS with a vertical CRS -->
              <!-- which uses height in above the Instantanious Water Level as a datum. -->
              <!--  -->
              <!-- For a tide gauge or a station at a fixed location relative to the Geoid (MSL), the CRS should be: -->
              <!-- EPSG::4979 referenceFrame="" -->
              <!--  -->
              <!-- Each stations localFrame must be unique.  -->
              <swe2:coordinate name="latitude">
                <swe2:Quantity definition="" axisID="Lat">
                  <swe2:uom code="deg" />
              <swe2:coordinate name="longitude">
                <swe2:Quantity definition="" axisID="Lon">
                  <swe2:uom code="deg" />
              <swe2:coordinate name="height">
                <swe2:Quantity definition="" axisID="Z">
                  <swe2:uom code="m" />
                  <!-- Zero height is at water level in the IOOS Buoy CRS. All sensors locations should be a height -->
                  <!-- (vertical upward) relative to this reference frame -->

          <!-- Static data for all sensors on this station -->
          <swe2:field name="sensors">
            <!-- IoosTech Convention: -->
            <!-- The data record containing the static data for each sensor shall be defined -->
            <swe2:DataRecord definition="">
              <swe2:field name="wmo_41001_sensor1">
                <!-- IoosTech Convention: -->
                <!-- The data record containing the static data for a sensor shall be defined -->
                <!-- Reminder: the DataRecord id of a sensor in the static block matches the DataChoice item -->
                <!-- name in the dynamic block -->
                <swe2:DataRecord id="wmo_41001_sensor1"
                  <swe2:field name="sensorID">
                    <!-- Field: sensorID -->
                    <!-- The sensorID urn may use a meaningful "component" name (eg, "sbe16"); or, -->
                    <!-- if not available, a simple, constant string followed by an integer counter -->
                    <!-- such as "sensor1", "sensor2", "salt1", etc. -->
                    <!-- IoosTech Convention: -->
                    <!-- The text element containing the sensor id shall be defined -->
                    <swe2:Text definition="">
                  <!-- Height is generally a static field so we demonstrate its use here. It can be -->
                  <!-- defined statically or dynamically. -->
                  <swe2:field name="height">
                    <!-- The location of the sensor relative to the platform  -->
                    <!-- We don't currently have enough information about orientation and relative position -->
                    <!-- of sensors on a platform to define a sensor reference frame, but it is certainly -->
                    <!-- possible to do if and when that is needed. -->
                    <swe2:Quantity definition=""
                      <swe2:uom code="m" />

  <!-- All measurements made by sensors and any other dynamic data (e.g. location for mobile sensors) -->
  <!-- are encoded in a DataArray. Again, sensor field name in the static DataRecord above corresponds to -->
  <!-- DataChoice item name in the dynamic DataArray -->
  <swe2:field name="observationData">
    <!-- IoosTech Convention: -->
    <!-- The field containing the dynamic data from each sensor shall contain a DataArray defined as such-->
    <swe2:DataArray definition="">
      <!-- Count of records in swe:values -->
      <!-- Definition of fields in the DataArray -->
      <swe2:elementType name="observations">
        <!-- IoosTech Convention: -->
        <!-- The data record containing the dynamic observation descriptors for each sensor shall be defined -->
        <swe2:DataRecord definition="">
          <!-- Time is included for all sensor so it is listed first and is outside of DataChoice. -->
          <!-- If time is defined differently for some sensors it could be moved inside the data -->
          <!-- but this is uncommon. -->
          <swe2:field name="time">
            <swe2:Time definition="">
              <swe2:uom xlink:href="" />

          <!-- Since different observations are made by each sensor, DataChoice is used to select -->
          <!-- a sensor and the set of observation fields for each record from that sensor in the -->
          <!-- block encoded values of the data array. -->
          <swe2:field name="sensor">
            <!-- IoosTech Convention: -->
            <!-- The data array shall contain one field with a DataChoice defined as sensor records -->
            <swe2:DataChoice definition="">
              <!-- DataChoice for wmo 41001's sensor1 -->
              <!-- Dynamic sensor observations are linked to static data using the DataChoice -->
              <!-- item name: wmo_41001_sensor1 -->
              <swe2:item name="wmo_41001_sensor1">
                <!-- IoosTech Convention: -->
                <!-- The data record containing the dynamic observation descriptors for a sensor shall be defined -->
                <swe2:DataRecord definition="">
                  <!-- wmo_41001_sensor1's observed properties -->
                  <swe2:field name="air_temperature">
                    <swe2:Quantity definition="">
                      <swe2:uom code="Celsius" />

                  <swe2:field name="wind_speed">
                    <swe2:Quantity definition="">
                      <swe2:uom code="m/s" />

                  <swe2:field name="wind_to_direction">
                    <swe2:Quantity definition="">
                      <swe2:uom code="degrees" />

              <swe2:item name="dummy_item"/>
              <!-- Since DataChoice must contain 2 or more items add a dummy item which is never -->
              <!-- Used in the actual encoding block. We view this as a mistake in the SWE specification -->


        <!-- SWE encoding and data values -->
        <!-- IoosTech Convention: -->
        <!-- swe:encoding *must* be always specified exactly as described below, -->
        <!-- to avoid the need to have fully general parsers that interpret -->
        <!-- swe:TextEncoding. That is, parsers may hard-code this particular -->
        <!-- swe:TextEncoding specification. -->
        <!--  -->
        <!-- About DataChoice from SWE Common 2.0: -->
        <!-- 9.2.5	Rules for DataChoice -->
        <!-- A тАЬDataChoiceтАЭ is encoded with the text method by providing the name of the selected item -->
        <!-- before the item values themselves. The name used shall correspond to the тАЬnameтАЭ attribute -->
        <!-- of the тАЬitemтАЭ property element that describes the structure of the selected item. -->
        <!--  -->
        <!-- IoosTech Convention: -->
        <!-- The name encoded for by data choice must match both the static sensor field name -->
        <!-- as well as the name attribute of the data choice item in the dynamic data. -->
        <!--  -->
        <!-- This data stream interleaves different types of messages separated by the block separator -->
        <!-- character. The element type is a тАЬDataChoiceтАЭ which means that each block is composed of -->
        <!-- the item name, followed by values of the item. This example also demonstrates that items -->
        <!-- of a choice can be of different types and length. -->
          blockSeparator="&#10;" />
Tags: formatting