DRAFT
3/18/2016
Web Service Description Document (WSDD)
US Integrated Ocean Observing System
Sensor Observation Service
(IOOS SOS)
DRAFT
v0.9
DRAFT
3/18/2016
Web Service Description Document
Approval Signatures
Name
Organization
Signature
ii
Date Signed
DRAFT
3/18/2016
Revision History
Date
Version
Description
Name
2013-06-24
0.01
Initial draft structure
A. Birger
2013-09-05
0.8
First working draft version for group discussion
A. Birger
2013-11-05
0.9
Various additions and modifications based on
Shane StClair’s feedback
A. Birger, S. StClair
2013-11-06
0.91
Maintenance release: some minor errors and
omissions fixed.
A. Birger, S. StClair
iii
DRAFT
3/18/2016
Table of Contents
1
2
SCOPE........................................................................................................................................ 6
APPLICABLE DOCUMENTS .......................................................................................................... 6
2.1
2.2
3
DEFINITIONS .............................................................................................................................. 8
3.1
3.2
4
Government Standards .............................................................................................................................. 6
Non-Government Standards ...................................................................................................................... 6
Terms and Definitions ................................................................................................................................ 8
Acronyms ................................................................................................................................................... 9
WEB SERVICE PROPERTIES AND CAPABILITIES............................................................................12
4.1
SERVICE PROFILE ...................................................................................................................................... 12
4.1.1
Service Providers .............................................................................................................................. 12
4.1.1.1 Point of Contact ........................................................................................................................... 12
4.1.2
Service Consumer(s)......................................................................................................................... 13
4.1.3
Service Functionality ........................................................................................................................ 13
4.1.4
Security ............................................................................................................................................ 13
4.1.4.1 Roles ............................................................................................................................................. 13
4.1.4.2 Access Control Mechanisms ........................................................................................................ 14
4.1.4.3 Security Policies ........................................................................................................................... 14
4.1.5
Quality of Service (QoS) ................................................................................................................... 14
4.1.6
WSDL Documents............................................................................................................................. 14
4.2
SERVICE INTERFACES................................................................................................................................ 14
4.2.1
Conformance to Standards and Conventions .................................................................................. 15
4.2.1.1 OGC SOS Implementation Standards ........................................................................................... 15
4.2.1.2 NetCDF Climate and Forecast Metadata Convention .................................................................. 16
4.2.1.3 IOOS Convention and SOS Templates .......................................................................................... 16
4.2.1.4 Coordinate System Axis Order ..................................................................................................... 16
4.2.1.5 Namespaces ................................................................................................................................. 16
4.2.1.6 Notation ....................................................................................................................................... 17
4.2.2
Operations........................................................................................................................................ 17
4.2.2.1 GetCapabilities ............................................................................................................................. 19
4.2.2.1.1 GetCapabilities Request ......................................................................................................... 19
4.2.2.1.2 GetCapabilities Response ...................................................................................................... 21
4.2.2.1.2.1 ServiceIdentification ....................................................................................................... 23
4.2.2.1.2.2 ServiceProvider ............................................................................................................... 23
4.2.2.1.2.3 OperationsMetadata....................................................................................................... 24
4.2.2.1.2.4 Filter_Capabilities ........................................................................................................... 28
4.2.2.1.2.5 Contents .......................................................................................................................... 31
4.2.2.2 DescribeSensor............................................................................................................................. 37
4.2.2.2.1 DescribeSensor Request ........................................................................................................ 37
4.2.2.2.2 DescribeSensor Response ...................................................................................................... 38
4.2.2.2.2.1 Network of platforms/stations ....................................................................................... 41
4.2.2.2.2.2 Platform/Station ............................................................................................................. 46
4.2.2.2.2.3 Sensor.............................................................................................................................. 54
4.2.2.3 GetObservation ............................................................................................................................ 55
4.2.2.3.1 GetObservation Request ........................................................................................................ 56
iv
DRAFT
3/18/2016
4.2.2.3.2 GetObservation Response ..................................................................................................... 59
4.2.2.3.2.1 OM-GetObservation Template ....................................................................................... 59
4.2.2.3.2.2 SWE-GetObservation Template ...................................................................................... 65
4.2.2.3.2.2.1 Static Data Block ...................................................................................................... 67
4.2.2.3.2.2.1.1 Common QA/QC information ........................................................................... 71
4.2.2.3.2.2.1.2 Profiling sensor specifics ................................................................................... 71
4.2.2.3.2.2.2 Dynamic Data (Sensor Observations) Block ............................................................. 75
4.2.2.3.2.2.2.1 Observation-specific QA/QC information ......................................................... 80
4.2.2.3.2.2.2.2 Profiling sensor observation-specific report..................................................... 82
4.3
SERVICE IMPLEMENTATION ..................................................................................................................... 84
4.3.1
SOS End Points ................................................................................................................................. 84
4.3.1.1 SOS 52 North End Point ............................................................................................................... 84
4.3.1.1.1 Associated Interface .............................................................................................................. 84
4.3.1.1.2 Communication Protocol ....................................................................................................... 84
4.3.1.1.3 Messaging Protocol................................................................................................................ 84
4.3.1.1.4 Network Address.................................................................................................................... 84
4.3.1.1.5 End Point-Specific Qualities of Service .................................................................................. 84
4.3.1.2 ncSOS End Point ........................................................................................................................... 84
4.3.1.2.1 Associated Interface .............................................................................................................. 84
4.3.1.2.2 Communication Protocol ....................................................................................................... 85
4.3.1.2.3 Messaging Protocol................................................................................................................ 85
4.3.1.2.4 Network Address.................................................................................................................... 85
4.3.1.2.5 End Point-Specific Qualities of Service .................................................................................. 85
5
APPENDIXES .............................................................................................................................85
5.1
SWE Common Templates Milestone 1.0 ................................................................................................. 85
5.1.1
TimeSeries records for single station with a single sensor .............................................................. 85
5.1.2
TimeSeries records for multiple stations ......................................................................................... 89
5.1.3
TimeSeries records for multiple stations with multiple sensors including quality elements
for some quantities .......................................................................................................................................... 98
5.1.4
TimeSeriesProfile records for a single station ............................................................................... 109
5.1.5
TimeSeriesProfile records for multiple station with multiple sensors including quality
elements for some quantities ........................................................................................................................ 117
v
DRAFT
3/18/2016
1 SCOPE
2 APPLICABLE DOCUMENTS
2.1 Government Standards
[1]
FAA-STD-065, Preparation of Web Service Description Documents, 26 February 2010.
http://www.faa.gov/air_traffic/nas/system_standards/
[2]
2.2 Non-Government Standards
[3]
OpenGIS Filter Encoding 2.0 Encoding Standard Version 2.0.0, Open Geospatial Consortium,
International Organization for Standards (ISO) 19143:2010, November 2010.
http://www.opengeospatial.org/standards/filter
[4]
OpenGIS Geography Markup Language (GML) Encoding Standard Version 3.2.1, Open Geospatial
Consortium (OGC), August 2007.
http://www.opengeospatial.org/standards/gml
[5]
OpenGIS Sensor Observation Service (SOS) Implementation Standard Version 1.0.0, Open
Geospatial Consortium, October 2007, OGC 06-009r6.
http://www.opengeospatial.org/standards/sos
[6]
OpenGIS Sensor Observation Service (SOS) Implementation Standard Version 2.0, Open Geospatial
Consortium, April 2012, OGC 12-006.
http://www.opengeospatial.org/standards/sos
[7]
OpenGIS Network Common Data Form (NetCDF) Core Encoding Standard Version 1.0, Open
Geospatial Consortium, April 2011.
http://www.opengeospatial.org/standards/netcdf
[8]
OpenGIS Web Services Common Standard Version 2.0, Open Geospatial Consortium, April 2010.
http://www.opengeospatial.org/standards/common
[9]
Web Services Description Language (WSDL) Version 1.1, W3C Note, March 2001
http://www.w3.org/TR/wsdl
[10]
NetCDF Climate and Forecast (CF) Metadata Conventions Version 1.6, December 2011,
http://cf-pcmdi.llnl.gov/documents
[11]
CF Conventions Standard Name Table, Version 25, July 2013,
http://cf-pcmdi.llnl.gov/documents/cf-standard-names/standard-name-table/25/cf-standard-
6
DRAFT
3/18/2016
name-table.html
[12]
ANSI/INCITS 359-2004 Information Technology - Role Based Access Control International
Committee for Information Technology Standards, February 2004
http://www.cs.purdue.edu/homes/ninghui/readings/AccessControl/ANSI+INCITS+359-2004.pdf
[13]
The Transport Layer Security (TLS) Protocol Version 1.2, Network Working Group, August 2008
http://tools.ietf.org/html/rfc5246
[14]
The Secure Hypertext Transfer Protocol, Network Working Group, August 1999
http://tools.ietf.org/html/rfc2660
[15]
NetCDF Feature Type Templates, National Oceanographic Data Center (NODC)
http://www.nodc.noaa.gov/data/formats/netcdf/#templatesexamples
OpenGIS Sensor Model Language (SensorML) Implementation Specification Version 1.0.0, Open
Geospatial Consortium (OGC), July 2007
http://www.opengeospatial.org/standards/sensorml
OpenGIS SWE Common Data Model Encoding Standard Version 2.0.0, Open Geospatial
Consortium (OGC), January 2011
http://www.opengeospatial.org/standards/swecommon
OpenGIS Geography Markup Language (GML) Encoding Standard Version 3.1, Open Geospatial
Consortium (OGC), February 2004.
http://www.opengeospatial.org/standards/gml
7
DRAFT
3/18/2016
3 DEFINITIONS
3.1 Terms and Definitions
Broker
Consumers
Enterprise
Architecture
Find-Bind-Execute
Paradigm
Message
Publish
Queue
Queue Manager
Retained Messages
Selector
Service
Service Discovery
Service Oriented
Architecture (SOA)
Service Registration
Service Registry
Takes published messages and puts them on the queues for the
subscribers. Adds a layer of indirection so that subscribers do not know
publishers and publishers do not know subscribers. Publishers and
subscribers only know the common broker.
In this document, “Consumers” refer to any systems that need to obtain
weather data from SOS and connect via a web service interface.
The architecture of the enterprise wide systems.
Consumer finds information from the registry; binds between consumer
and provider; and executes the SOA request.
A data item to be passed between programs through a Message Queue
(MQ) containing MQ headers and data.
To send data to the Broker on a particular subject or topic.
A safe storage location for messages.
A process that manages the access to the queues.
Messages that have not yet sent out or received and are staying in
between the publisher and subscriber.
A message filtering paradigm.
The IT realization of some self-contained business functionality.
An implementation –independent reusable operational function that may
be discovered as self-describing interfaces, and invoked using open
standard protocols across networks.
The processes through which a service consumer may search for and find
services, (generally done by providing criteria to search for against a
corpus of service metadata which service providers have provided to
describe their services).
A paradigm for organizing and utilizing distributed capabilities of services
to clients that may be under the control of different ownership domains.
SOA provides a uniform means to offer, discover, interact with and use
capabilities to produce desired effects consistent with measurable
preconditions and expectations
The registering process for the agreed service.
An enabling infrastructure service that uses a formal registration process
to store, catalog, and manage metadata relevant to the services. A
registry supports the search, identification, and understanding of
resources, as well as query capabilities.
8
DRAFT
3/18/2016
Stateful Dialogs
Subscribe
Taxonomy
Topic
Observation
Procedure
Observed Property
Feature of Interest
Offering
Dialogs that have “state” information between participating server and
consumer agents to invoke requests and responses.
To request data via the Broker from a publisher on a particular subject or
topic.
A collection of controlled vocabulary terms organized into a hierarchical
structure or categorization. Each term in taxonomy is in one or more
parent-child relationships to other terms in the taxonomy.
A grouping of data of similar type.
A value measured at given time instant (e.g. value: 0.2, time: 08-11-2012
12:12), and represented according to the O&M standard data model.
A process that indicates who provide the observations. For SOS this is
generally the sensor, but may also be a generic process that leads to some
observations and is represented as SensorML standard data model.
A physical phenomenon that is observed (e.g. phenomenon: water
temperature), and is represented with a Uniform Resource Identifier (URI)
composed by colon separated text according to the
<om:observedProperty> element of the O&M standard.
A feature that relates to the observations, and represented according to
the <om:featureOfInterest> element of the O&M standard. For in-situ
observation, the feature of interest is the instrument (sensor) location,
while for remote observation it is the location of the target.
A collection of sensors used to conveniently group them up (e.g.
network:all, network:all-temperature, sensor:watertemp, etc.) and is
represented as <sos:ObservationOffering> element of the SOS standard.
3.2 Acronyms
9
DRAFT
3/18/2016
GML
Geography Markup Language
HTTPS
Hypertext Transfer Protocol Secure
NetCDF
Network Common Data Format
NOAA
National Oceanic and Atmospheric Administration
NWS
National Weather Service
OASIS
Organization for the Advancement of Structured Information Standards
OGC
Open Geospatial Consortium
OMO
One-Minute Observation
PSL
Product Subscription List
QoS
Quality of Service
RBAC
Role-Based Access Control
SOA
Service-Oriented Architecture
SOAP
Simple Object Access Protocol
TLS
Transport Layer Security
UML
Unified Modeling Language
URL
Uniform Resource Locator
WAN
Wide Access Network
10
DRAFT
3/18/2016
WARP
Weather and Radar Processor
WCS
Web Coverage Service
WFS
Web Feature Service
WSDD
Web Service Description Document
WSDL
Web Service Description Language
WSN
Web Services Notification
WSRD
Web Service Requirements Document
XML
eXtensible Markup Language
11
DRAFT
3/18/2016
4 WEB SERVICE PROPERTIES AND CAPABILITIES
The following sections describe the details that allow an IOOS consumer to discover and access data via the
IOOS SOS web service. This information includes a brief profile of the service, a description of the service
interfaces, and the implementation points of the service.
4.1 SERVICE PROFILE
Full Name
IOOS SOS Milestone 1.0
Namespace:
TBD
Description:
Service that provides non-gridded in-situ observation data to IOOS
consumers.
Version:
1.0
Service Category:
GEOSS Resource Category:
[analysisVisualization]
Lifecycle Stage:
Deployment
Level of Criticality:
Essential
4.1.1 Service Providers
Name:
NDBC
CO-OPS
11 IOOS Regional Associations
Description:
The US IOOS Program Office leads the multi-region effort, in collaboration
with federal and non-federal partners, to develop and deploy the IOOS
SOS in an effort to transform ocean observation data distribution by
delivering improved access to such data.
Web Page:
4.1.1.1
Point of Contact
Full Name:
Organization
Job Title/Description:
Telephone:
E-mail:
Address:
12
DRAFT
3/18/2016
4.1.2 Service Consumer(s)
Organization:
Program
Any interested government agency, or private company, or members of
general public
N/A
Web Page
Service Level Agreement:
Agreement Location:
N/A
TBD
TBD
4.1.3 Service Functionality
The business functionality of the service is to provide access to non-gridded in-situ observations collected by
NOAA federal data providers (NDBC and CO-OPS), and 11 non-federal regional partner associations. To
accomplish this, the service provides two interfaces for access to a non-gridded data: one for RDBMS data
store, and another - for data stored in netCDF files.
Implementation of the service interfaces is based upon standards developed by the OGC SOS specification,
providing flexible querying of IOOS data. Other specifications which are leveraged by the implementation
include the OGC’s Observation and Measurement (O&M) Model; Geography Markup Language (GML) and
Sensor Web Enablement Common (SWECommon) for its XML encodings; and Sensor Markup Language
(SensorML) for sensor descriptions.
Flexible querying includes the ability to filter data by spatial or temporal properties. Data can be filtered
spatially for a rectangular domain or individual platform coordinates. Temporally, the SOS interface allows
for retrieval of data before or after a specific date/time as well as over a period of time.
Data returned by the IOOS SOS must be encoded in XML; in addition, data may be encoded in many other
formats like CSV, TSV, JSON, etc. The XML schema conforms to GML Application Schema conventions, using
the emerging Sensor Web Enablement Common Data Model (SWECommon) standard.
The resulting “real world effect” of the service is to ensure simple and easy uniform way for timely delivery
of the ocean observations information to various data consumers.
4.1.4 Security
Generally, IOOS SOS Web server (frontend) does not implement authentication and authorization as it
exercises a free public Web access through the Internet. The security protection of the data storage
backend is completely at the discretion of each data provider.
Despite the public character of the IOOS SOS, the primary security mechanisms can be deployed if required.
The UserID/Password credentials may be used for authentication whereas authorization may be ensured by
deploying of the role-based access control (RBAC) technology. In case these security mechanisms are
implemented, HTTPS needs to be utilized to protect the authentication credentials, since they are presented
in plain text in the IOOS SOS request.
4.1.4.1
Roles
TBD
13
DRAFT
3/18/2016
4.1.4.2
Access Control Mechanisms
Authentication and authorization are the most common mechanisms for web services security development
practice. A common mechanism (used in the R&D prototyping effort) relies on X.509 Public Key
Infrastructure certificates. It is provided as an example in the table below.
Mechanism
Authentication
Standard
Web Services Security: UsernameToken Profile 1.0, OASIS Standard 200401,
March 2004. [11]
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile1.0.pdf
Authorization
ANSI/INCITS 359-2004 Information Technology - Role Based Access Control
International Committee for Information Technology Standards: 03-Feb-2004.
[12]
http://www.cs.purdue.edu/homes/ninghui/readings/AccessControl/ANSI+INCITS+3592004.pdf
Internet X.509
Public Key
Infrastructure
Certificate
4.1.4.3
http://www.ietf.org/rfc/rfc2459.txt
Security Policies
No common security policies are currently defined for IOOS SOS implementations.
4.1.5 Quality of Service (QoS)
For the Milestone 1.0, no QoS parameters are defined for the IOOS SOS. However, it is possible that the QoS
will be defined in the future versions of the IOOS SOS.
4.1.6 WSDL Documents
A Web Service Description Language (WSDL) document defines a service as a collection of network
endpoints operating on messages. The WSDL description specifies the address, allowable communication
mechanisms, interface, and message types of a Web service. In short, a WSDL description provides all the
information a client needs to use a Web service.
For the Milestone 1.0, no WSDL documents have been developed for the IOOS SOS. However, it is possible
that WSDL descriptions will be produced for the future versions of the IOOS SOS.
4.2 SERVICE INTERFACES
The service interface is a collection of types, messages, operations, and interface 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
14
DRAFT
3/18/2016
SWE specifications may be implemented in the future Milestones, at the present IOOS have used the
following:

Sensor Observation Service (SOS) 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.
4.2.1 Conformance to Standards and Conventions
4.2.1.1 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.
Core Model Diagram for Observations and Measurements (O&M)
15
DRAFT
3/18/2016
The subsequent sections provide more detail on the service interfaces, including information on data types,
messages, operations, and interface descriptions.
4.2.1.2 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.
4.2.1.3 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
(http://code.google.com/p/ioostech/source/browse/#svn%2Ftrunk%2Ftemplates%2FMilestone1.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 Convention contains additional constraints, definitions,
requirements and “best practice” sort of recommendations that SOS 1.0.0 lacks; for future transition, the
Convention uses SOS 2.0 requirements and definitions wherever they have been considered applicable if
they 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.
4.2.1.4 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 preceed longitude. The vertical coordinate must always be listed after the horizontal ones,
and explicitly follow the definition of the vertical CRS.
4.2.1.5 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"
16
DRAFT
3/18/2016

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 (because the O&M 1.0 schema already defines GML 3.1.1 as the version
used).
4.2.1.6 Notation
The OGC Implementation Standards with IOOS Convention define the following use of the upper and lower
cases in SOS XML documents, including operation requests:




service name must always be in UPPERCASE (i.e. “SOS”);
operation names must always be in UpperCamelCase (e.g. GetCapabilities);
names of operations like GetCapabilities or DescribeSensor must be in the UpperCamelCase
all 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:xoos:the_station).
4.2.2 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)
o
GetCapabilities
17
DRAFT
3/18/2016

o
DescribeSensor
o
GetObservation
Extended and Transactional Profiles operations (optional, out of scope of the Milestone 1.0)
o
RegisterSensor
o
InsertObservation
o
GetResult
o
GetFeatureOfInterest
o
GetFeatureOfInterestTime
o
DescribeFeatureOfInterest
o
DescribeObservationType
o
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 below.
SOS
Server
Service
Consumer
GetCapabilitiesRequest
Retrieval of metadata describing supported
operations and offerings, which is typically
performed at consumer start up.
GetCapabilitiesResponse
DescribeSensorRequest
Retrieval of metadata about a specific station
or sensor, which can be repeated whenever
consumer needs updated information.
Retrieval of a set of SWE-encoded
observations based on sensor, spatial, and/or
temporal specifications.
DescribeSensorResponse
GetObservationRequest
GetObservationResponse
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 server instances based on 52⁰ North and ncSOS solutions,
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
18
DRAFT
3/18/2016
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.
Some of the subsequent sections also contain parts of responses received from an AOOS Test SOS server.
That server implementation is considered as reference for the purpose of the IOOS SOS Milestone 1.0
implementation, and as such, its responses contain the same mandatory components as as the Templates.
However, keep in mind that the documents produced by the AOOS Test SOS Server may also include some
components that are optional from the Milestone 1.0 standpoint.
4.2.2.1 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.
4.2.2.1.1 GetCapabilities Request
GetCapabilities 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 GetCapabilities should
follow the structure as described in the Figure and Table below.
19
DRAFT
3/18/2016
Input parameters of the GetCapabilities request are explained in the following table:
Input Name
Cardinality
service
request
version
1…1
1…1
0…1 for 52N
1…1 for ncSOS
acceptVersions
1…1 for 52N
0…1 for ncSOS
sections
0…1
acceptFormats
0…1
Description
Service name (fixed value “SOS”)
Operation name
A non-standard parameter indicating the SOS version.
For unknown reason is required for ncSOS with the value “1.0.0”.
Not used in the 52North implementation.
A list of specification versions accepted by client, with preferred versions listed
first.
Not implemented in the ncSOS server.
Required for 52North SOS with the value “1.0.0”; if omitted, the server returns by
default the SOS v2.0 GetCapabilities document.
When specified, identifies the sections of the GetCapabilities response to be
returned to the client. One or more values in a comma-separated list may be
specified. If omitted, all sections are returned. Valid values are:
- ServiceIdentification
- ServiceProvider
- OperationsMetadata
- Filter_Capabilities
- Contents
- All
A list of zero or more response formats desired by client, with preferred formats
listed first. Currently, IOOS Convention supports just one output format:
– text/xml;subtype="sensorML/1.0.1/profiles/ioos_sos/1.0"
–
Note, that although the GetCapabilities operation may support all parameters, just three of them (service,
request, and version/acceptVersions) are required by the IOOS Convention.
20
DRAFT
3/18/2016
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:

HTTP/GET to 52North implementation
http://SERVERNAME:PORT/SOS_WEBAPP_NAME/sos?SERVICE=SOS&REQUEST=GetCapabilities
or
http://SERVERNAME:PORT/SOS_WEBAPP_NAME/sos?service=SOS&request=GetCapabilities&Accept
Versions=1.0.0

HTTP/GET to ncSOS implementation
http://SERVERNAME:PORT/SOS_WEBAPP_NAME/sos?service=SOS&request=GetCapabilities&ver
sion=1.0.0
Note, that for the GET request to an ncSOS version of the IOOS SOS, the parameter “version=1.0.0”
is required as opposed to a 52North implementation. If that parameter is missing, the ncSOS will
return an exception report instead of the GetCapability document. In fact, the enforcement of the
“version” instead of “acceptVersions” has been done in violation of the OGC Web Services Common
Specification, and as such will be most likely fixed in the future ncSOS releases.
The current release of the ncSOS will also accept the request with all parameters missing, i.e. the
truncated request
http://SERVERNAME:PORT/SOS_WEBAPP_NAME/sos
will return the combined GetCapabilities document for both SOS v1.0.0 and v2.0. That ncSOS
behavior is not in line with the SOS standard, and is not guaranteed in future releases; therefore,
the full version of GET request is strongly recommended.

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>
4.2.2.1.2 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 the whole information about coordinate reference system (CRS), spatial or temporal filtering and
21
DRAFT
3/18/2016
other information about sensors, feature of interest, and response format. The OGC specification is
constrained by specific IOOS conventions that on one hand prescribe a certain way of use for some optional
components, and on the other hand – facilitate the future acceptance of the SOS 2.0. At any rate, the IOOS
conventions do not violate OGC specification’s requirements.
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
The sections are described in more details later.
22
DRAFT
3/18/2016
<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>
4.2.2.1.2.1 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>
4.2.2.1.2.2 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.
23
DRAFT
3/18/2016
<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>
4.2.2.1.2.3 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 IOOS Convention requires an indication of the current template version; this information is provided in
the <ows:ExtendedCapabilities>/<gml:metaDataProperty xlink:title="ioosTemplateVersion"> element.
In addition to the template version, the IOOS Convention recommends to provide an indication of the
current software version in the <ows:ExtendedCapabilities>/<gml:metaDataProperty
xlink:title="softwareVersion"> element.
<ows:OperationsMetadata>
<ows:Operation name="GetCapabilities">
<ows:DCP>
<ows:HTTP>
<ows:Get xlink:href="SOS_SERVER"/>
<ows:Post xlink:href="SOS_SERVER"/>
</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>
24
DRAFT
3/18/2016
<ows:HTTP>
<ows:Get xlink:href="SOS_SERVER"/>
<ows:Post xlink:href="SOS_SERVER"/>
</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"/>
<ows:Post xlink:href="SOS_SERVER"/>
</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>
The sample below is a real OperationsMetadata part of the AOOS test SOS server GetCapabilities response.
The sample is presented just for reference, and may change at any time. The sampled document is much
more detailed than the template above as it reports the metadata for both mandatory and optional
operations that server is capable of, and list all allowed values for the request parameters, response output
format encodings, etc.
<ows:OperationsMetadata>
<ows:Operation name="DescribeSensor">
<ows:DCP>
<ows:HTTP>
<ows:Get xlink:href="http://ioossos.axiomalaska.com/52n-sos-ioos/sos/kvp?">
<ows:Constraint name="encoding">
25
DRAFT
3/18/2016
<ows:AllowedValues>
<ows:Value>kvp</ows:Value>
</ows:AllowedValues>
</ows:Constraint>
</ows:Get>
<ows:Post xlink:href="http://ioossos.axiomalaska.com/52n-sos-ioos/sos/soap">
<ows:Constraint name="encoding">
<ows:AllowedValues>
<ows:Value>soap</ows:Value>
</ows:AllowedValues>
</ows:Constraint>
</ows:Post>
<ows:Post xlink:href="http://ioossos.axiomalaska.com/52n-sos-ioos/sos/pox">
<ows:Constraint name="encoding">
<ows:AllowedValues>
<ows:Value>pox</ows:Value>
</ows:AllowedValues>
</ows:Constraint>
</ows:Post>
</ows:HTTP>
</ows:DCP>
<ows:Parameter name="outputFormat">
<ows:AllowedValues>
<ows:Value>http://www.opengis.net/sensorML/1.0.1</ows:Value>
<ows:Value>text/xml;subtype="sensorML/1.0.1"</ows:Value>
<ows:Value>text/xml;subtype="sensorML/1.0.1/profiles/ioos_sos/1.0"</ows:Value>
</ows:AllowedValues>
</ows:Parameter>
</ows:Operation>
<ows:Operation name="GetCapabilities">
<ows:DCP>
<ows:HTTP>
<ows:Get xlink:href="http://ioossos.axiomalaska.com/52n-sos-ioos/sos/kvp?">
<ows:Constraint name="encoding">
<ows:AllowedValues>
<ows:Value>kvp</ows:Value>
</ows:AllowedValues>
</ows:Constraint>
</ows:Get>
<ows:Post xlink:href="http://ioossos.axiomalaska.com/52n-sos-ioos/sos/soap">
<ows:Constraint name="encoding">
<ows:AllowedValues>
<ows:Value>soap</ows:Value>
</ows:AllowedValues>
</ows:Constraint>
</ows:Post>
<ows:Post xlink:href="http://ioossos.axiomalaska.com/52n-sos-ioos/sos/pox">
<ows:Constraint name="encoding">
<ows:AllowedValues>
<ows:Value>pox</ows:Value>
</ows:AllowedValues>
</ows:Constraint>
</ows:Post>
</ows:HTTP>
</ows:DCP>
<ows:Parameter name="Sections">
<ows:AllowedValues>
<ows:Value>All</ows:Value>
<ows:Value>Contents</ows:Value>
<ows:Value>Filter_Capabilities</ows:Value>
<ows:Value>OperationsMetadata</ows:Value>
26
DRAFT
3/18/2016
<ows:Value>ServiceIdentification</ows:Value>
<ows:Value>ServiceProvider</ows:Value>
</ows:AllowedValues>
</ows:Parameter>
</ows:Operation>
<ows:Operation name="GetFeatureOfInterest">
<ows:DCP>
<ows:HTTP>
<ows:Post xlink:href="http://ioossos.axiomalaska.com/52n-sos-ioos/sos/soap">
<ows:Constraint name="encoding">
<ows:AllowedValues>
<ows:Value>soap</ows:Value>
</ows:AllowedValues>
</ows:Constraint>
</ows:Post>
<ows:Post xlink:href="http://ioossos.axiomalaska.com/52n-sos-ioos/sos/pox">
<ows:Constraint name="encoding">
<ows:AllowedValues>
<ows:Value>pox</ows:Value>
</ows:AllowedValues>
</ows:Constraint>
</ows:Post>
</ows:HTTP>
</ows:DCP>
</ows:Operation>
<ows:Operation name="GetObservation">
<ows:DCP>
<ows:HTTP>
<ows:Get xlink:href="http://ioossos.axiomalaska.com/52n-sos-ioos/sos/kvp?">
<ows:Constraint name="encoding">
<ows:AllowedValues>
<ows:Value>kvp</ows:Value>
</ows:AllowedValues>
</ows:Constraint>
</ows:Get>
<ows:Post xlink:href="http://ioossos.axiomalaska.com/52n-sos-ioos/sos/soap">
<ows:Constraint name="encoding">
<ows:AllowedValues>
<ows:Value>soap</ows:Value>
</ows:AllowedValues>
</ows:Constraint>
</ows:Post>
<ows:Post xlink:href="http://ioossos.axiomalaska.com/52n-sos-ioos/sos/pox">
<ows:Constraint name="encoding">
<ows:AllowedValues>
<ows:Value>pox</ows:Value>
</ows:AllowedValues>
</ows:Constraint>
</ows:Post>
</ows:HTTP>
</ows:DCP>
</ows:Operation>
<ows:Operation name="GetObservationById">
<ows:DCP>
<ows:HTTP>
<ows:Post xlink:href="http://ioossos.axiomalaska.com/52n-sos-ioos/sos/soap">
<ows:Constraint name="encoding">
<ows:AllowedValues>
<ows:Value>soap</ows:Value>
</ows:AllowedValues>
</ows:Constraint>
27
DRAFT
3/18/2016
</ows:Post>
<ows:Post xlink:href="http://ioossos.axiomalaska.com/52n-sos-ioos/sos/pox">
<ows:Constraint name="encoding">
<ows:AllowedValues>
<ows:Value>pox</ows:Value>
</ows:AllowedValues>
</ows:Constraint>
</ows:Post>
</ows:HTTP>
</ows:DCP>
</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:Value>2.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>
</ows:ExtendedCapabilities>
</ows:OperationsMetadata>
4.2.2.1.2.4 Filter_Capabilities
This section contains metadata about the sub-setting activities (spatial, temporal, scalar, etc.) that are
supported by an SOS server. Since filtering has been out of scope of the Milestone 1.0, the IOOS Convention
does not require this section in a GetCapabilities response, and IOOS SOS Milestone 1.0 GetCapabilities
template does not prescribe any specific way of implementation; therefore, if SOS developers decide to
implement filtering capabilities nevertheless, they should just follow the SOS 1.0.0 Implementation
Standard.
Just for reference, below is the fragment of the AOOS test SOS server’s GetCapabilities response, which
illustrates the Filter_Capabilities encoding in the GetCapabilities document.
<sos:Filter_Capabilities>
<ogc:Spatial_Capabilities>
<ogc:GeometryOperands>
<ogc:GeometryOperand>gml:Envelope</ogc:GeometryOperand>
<ogc:GeometryOperand>gml:LineString</ogc:GeometryOperand>
<ogc:GeometryOperand>gml:Point</ogc:GeometryOperand>
<ogc:GeometryOperand>gml:Polygon</ogc:GeometryOperand>
</ogc:GeometryOperands>
<ogc:SpatialOperators>
<ogc:SpatialOperator name="Overlaps">
<ogc:GeometryOperands>
<ogc:GeometryOperand>gml:LineString</ogc:GeometryOperand>
<ogc:GeometryOperand>gml:Point</ogc:GeometryOperand>
<ogc:GeometryOperand>gml:Polygon</ogc:GeometryOperand>
</ogc:GeometryOperands>
</ogc:SpatialOperator>
28
DRAFT
3/18/2016
<ogc:SpatialOperator name="Intersects">
<ogc:GeometryOperands>
<ogc:GeometryOperand>gml:LineString</ogc:GeometryOperand>
<ogc:GeometryOperand>gml:Point</ogc:GeometryOperand>
<ogc:GeometryOperand>gml:Polygon</ogc:GeometryOperand>
</ogc:GeometryOperands>
</ogc:SpatialOperator>
<ogc:SpatialOperator name="Contains">
<ogc:GeometryOperands>
<ogc:GeometryOperand>gml:LineString</ogc:GeometryOperand>
<ogc:GeometryOperand>gml:Point</ogc:GeometryOperand>
<ogc:GeometryOperand>gml:Polygon</ogc:GeometryOperand>
</ogc:GeometryOperands>
</ogc:SpatialOperator>
<ogc:SpatialOperator name="BBOX">
<ogc:GeometryOperands>
<ogc:GeometryOperand>gml:Envelope</ogc:GeometryOperand>
</ogc:GeometryOperands>
</ogc:SpatialOperator>
</ogc:SpatialOperators>
</ogc:Spatial_Capabilities>
<ogc:Temporal_Capabilities>
<ogc:TemporalOperands>
<ogc:TemporalOperand>gml:TimeInstant</ogc:TemporalOperand>
<ogc:TemporalOperand>gml:TimePeriod</ogc:TemporalOperand>
</ogc:TemporalOperands>
<ogc:TemporalOperators>
<ogc:TemporalOperator name="TM_Before">
<ogc:TemporalOperands>
<ogc:TemporalOperand>gml:TimeInstant</ogc:TemporalOperand>
<ogc:TemporalOperand>gml:TimePeriod</ogc:TemporalOperand>
</ogc:TemporalOperands>
</ogc:TemporalOperator>
<ogc:TemporalOperator name="TM_After">
<ogc:TemporalOperands>
<ogc:TemporalOperand>gml:TimeInstant</ogc:TemporalOperand>
<ogc:TemporalOperand>gml:TimePeriod</ogc:TemporalOperand>
</ogc:TemporalOperands>
</ogc:TemporalOperator>
<ogc:TemporalOperator name="TM_Begins">
<ogc:TemporalOperands>
<ogc:TemporalOperand>gml:TimeInstant</ogc:TemporalOperand>
<ogc:TemporalOperand>gml:TimePeriod</ogc:TemporalOperand>
</ogc:TemporalOperands>
</ogc:TemporalOperator>
<ogc:TemporalOperator name="TM_Ends">
<ogc:TemporalOperands>
<ogc:TemporalOperand>gml:TimeInstant</ogc:TemporalOperand>
<ogc:TemporalOperand>gml:TimePeriod</ogc:TemporalOperand>
</ogc:TemporalOperands>
</ogc:TemporalOperator>
<ogc:TemporalOperator name="TM_EndedBy">
<ogc:TemporalOperands>
<ogc:TemporalOperand>gml:TimeInstant</ogc:TemporalOperand>
<ogc:TemporalOperand>gml:TimePeriod</ogc:TemporalOperand>
</ogc:TemporalOperands>
</ogc:TemporalOperator>
<ogc:TemporalOperator name="TM_BegunBy">
<ogc:TemporalOperands>
<ogc:TemporalOperand>gml:TimeInstant</ogc:TemporalOperand>
<ogc:TemporalOperand>gml:TimePeriod</ogc:TemporalOperand>
29
DRAFT
3/18/2016
</ogc:TemporalOperands>
</ogc:TemporalOperator>
<ogc:TemporalOperator name="TM_During">
<ogc:TemporalOperands>
<ogc:TemporalOperand>gml:TimeInstant</ogc:TemporalOperand>
<ogc:TemporalOperand>gml:TimePeriod</ogc:TemporalOperand>
</ogc:TemporalOperands>
</ogc:TemporalOperator>
<ogc:TemporalOperator name="TM_Equals">
<ogc:TemporalOperands>
<ogc:TemporalOperand>gml:TimeInstant</ogc:TemporalOperand>
<ogc:TemporalOperand>gml:TimePeriod</ogc:TemporalOperand>
</ogc:TemporalOperands>
</ogc:TemporalOperator>
<ogc:TemporalOperator name="TM_Contains">
<ogc:TemporalOperands>
<ogc:TemporalOperand>gml:TimeInstant</ogc:TemporalOperand>
<ogc:TemporalOperand>gml:TimePeriod</ogc:TemporalOperand>
</ogc:TemporalOperands>
</ogc:TemporalOperator>
<ogc:TemporalOperator name="TM_Overlaps">
<ogc:TemporalOperands>
<ogc:TemporalOperand>gml:TimeInstant</ogc:TemporalOperand>
<ogc:TemporalOperand>gml:TimePeriod</ogc:TemporalOperand>
</ogc:TemporalOperands>
</ogc:TemporalOperator>
<ogc:TemporalOperator name="TM_Meets">
<ogc:TemporalOperands>
<ogc:TemporalOperand>gml:TimeInstant</ogc:TemporalOperand>
<ogc:TemporalOperand>gml:TimePeriod</ogc:TemporalOperand>
</ogc:TemporalOperands>
</ogc:TemporalOperator>
<ogc:TemporalOperator name="TM_MetBy">
<ogc:TemporalOperands>
<ogc:TemporalOperand>gml:TimeInstant</ogc:TemporalOperand>
<ogc:TemporalOperand>gml:TimePeriod</ogc:TemporalOperand>
</ogc:TemporalOperands>
</ogc:TemporalOperator>
<ogc:TemporalOperator name="TM_OverlappedBy">
<ogc:TemporalOperands>
<ogc:TemporalOperand>gml:TimeInstant</ogc:TemporalOperand>
<ogc:TemporalOperand>gml:TimePeriod</ogc:TemporalOperand>
</ogc:TemporalOperands>
</ogc:TemporalOperator>
</ogc:TemporalOperators>
</ogc:Temporal_Capabilities>
<ogc:Scalar_Capabilities>
<ogc:ComparisonOperators>
<ogc:ComparisonOperator>EqualTo</ogc:ComparisonOperator>
<ogc:ComparisonOperator>NotEqualTo</ogc:ComparisonOperator>
<ogc:ComparisonOperator>LessThan</ogc:ComparisonOperator>
<ogc:ComparisonOperator>GreaterThan</ogc:ComparisonOperator>
<ogc:ComparisonOperator>LessThanEqualTo</ogc:ComparisonOperator>
<ogc:ComparisonOperator>GreaterThanEqualTo</ogc:ComparisonOperator>
<ogc:ComparisonOperator>Like</ogc:ComparisonOperator>
<ogc:ComparisonOperator>Between</ogc:ComparisonOperator>
</ogc:ComparisonOperators>
</ogc:Scalar_Capabilities>
<ogc:Id_Capabilities>
<ogc:FID/>
<ogc:EID/>
30
DRAFT
3/18/2016
</ogc:Id_Capabilities>
</sos:Filter_Capabilities>
4.2.2.1.2.5 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 definition of some metadata elements that appear in the Contents section is further constrained by
IOOS Convention. The recommended way of use of these elements along with related IOOS Convention’s
requirements and constraints are explained in details below. Other metadata elements that are not subjects
of the IOOS Convention, and should be implemented strictly in accord with the relevant OGC
Implementation Standards, are not discussed in this document.
IOOS Convention’s GetCapabilities General Constraints
The IOOS conventions impose certain general constraints on the Content section:

Advertizing of the NetworkALL group of platforms is required.

Advertizing of logical sub-groups of the Network-ALL group (e.g. by provider, region, measurement
type, etc.) is recommended.

Advertizing 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.
IOOS Convention’s Requirements and Metadata Elements affected
The IOOS Convention provides additional qualification to the descriptions of some of the key metadata
elements that are in use in the Content section. Note that by no means that refinement steps over the
boundaries that are set by the OGC standards, i.e. all elements still conform to the relevant specifications.
Input Name
gml:id
Cardinality
1…1
Description
Each observation offering must have a unique ID. It is recommended that “gml:id”
values should start with 'station-' for platforms and 'network-' for networks of
platforms, and be augmented with the label from the station identifier as defined in
IOOS Conventions for Observing Asset Identifiers.
Example: station-21401
gml:name
1…1
The IOOS Convention currently requires the “gml:name” value to be a URN that
conforms to the IOOS Conventions for Observing Asset Identifiers.
Example: urn:ioos:station:wmo:21401
gml:description
0…1
It is recommended that any human-readable name or description of the network or
station assigned by a data provider should be parked in this element.
Example: 250NM Southeast of Iturup Island.
gml:srsName
0…1
This element defines a Coordinate Reference System (CRS) used for observation
offering.
If the element is provided, the value must be the European Petroleum Survey Group
(EPSG) CRS 4326 (WGS84).
If no <gml:srsName> is provided, the CRS must be specified in the “srsName” attribute
31
DRAFT
3/18/2016
of the <gml:boundedBy/gml:Envelope> element; this way was recommended as a
preferred method for CRS specification.
Example: EPSG::4326”
srsName
0…1
This attribute define a CRS as a part of the <gml:boundedBy/gml:Envelope> element
for a single bounding box.
If no “srsName” attribute is provided, the CRS must be specified in the <gml:srsName>
element. However, the IOOS Convention recommends to use the “srsName” attribute
instead of the <gml:srsName> element.
If the attribute is provided, the value must be in a form of OGC-defined URL for the
European Petroleum Survey Group (EPSG) CRS 4326 (WGS84).
Example: srsName=http://www.opengis.net/def/crs/EPSG/0/4326
sos:time
1…1
Advertizes the overall temporal boundaries for the observationOffering data
availability.
Time period <beginPosition> and <endPosition> limiters allow a use of fixed values in
ISO 8601 format (2009-05-23T00:00:00.000Z)as well as evaluated
“indeterminatePosition” attribute with the value ‘now’ if the end time has not yet
been.
Examples:
<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:TimePeriod>
</sos:time>
Note: The overall start and end times do not indicate whether data gaps exist. If an
offering comprises multiple sensors, each with different start or end times (for
example, a new sensor was added at a later date), the start and end times indicate the
overall period during which at least some data are available.
sos:procedure
1…1
This element contains the official IOOS identifier for the platform or network in a form
of URN that conforms to the IOOS Conventions for Observing Asset Identifiers.
Only one procedure element for a single offering is currently allowed (it is done for
future compatibility – although SOS 1.0.0 does not limit that number, the SOS 2.0 only
allows a single procedure per offering).
Examples:
<sos:procedure xlink:href="urn:ioos:network:AUTHORITY:all"/>
<sos:procedure xlink:href=" urn:ioos:station:wmo:21401"/>
sos:observedProperty
1…*
This element advertizes one or more quantities observed by a specific offering.
The IOOS convention only requires support of all fully qualified
<sos:observedProperty> elements that are advertized in the GetCapabilities
document(support of unqualified elements is optional).
The element’s value must be a URL corresponding to a Climate and Forecast (CF)
Standard Name of the record in one of the the IOOS Vocabularies that are currently
hosted by the Marine Metadata Interoperability (MMI) project.
It is also required to advertize a vector variable (i.e wind, current, or wave) by
reference to it as a composite phenomenon that is defined in the IOOS Parameter
Vocabulary (e.g.: http://mmisw.org/ont/ioos/parameter/wave).
32
DRAFT
3/18/2016
The value of the advertized observedProperty identifier must be used in
GetObservation requests to obtain the actual data.
Example:
observedProperty xlink:href=http://mmisw.org/ont/cf/parameter/VALUE
observedProperty xlink:href="http://mmisw.org/ont/cf/parameter/COMPOSITE_VALUE"
sos:responseMode
0…*
This element indicates what modes of response are supported for this offering. The
following values are allowed:




inline
out-of-band
attached
resultTemplate
TBD: The value of external to the observation element (out-of-band) is recommended,
if for any reason (sensistivity, legacy formats, etc.) it is desirable to return in
GetObservation response a reference (URL) to the data instead of data itself. The
reference may also point to the file with the instruction on how to get the real data offline.
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>
33
DRAFT
3/18/2016
</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>
More details are provided in a sample below, which presents a Contents part of the AOOS test SOS server
GetCapabilities response. The sample is presented just for reference, and may change at any time. The
sampled document is much more detailed than the template above as it 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"/>
34
DRAFT
3/18/2016
<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>
35
DRAFT
3/18/2016
<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"/>
36
DRAFT
3/18/2016
<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>
4.2.2.2 DescribeSensor
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 observables supported by the
sensor [OGC 06-009r6].
The following sections illustrate DescribeSensor HTTP/GET and HTTP/POST requests, provides the list of the
request’s parameters and description for the DescribeSensor operation response.
4.2.2.2.1 DescribeSensor Request
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 as described in this section.
The UML diagram of the DescribeSensor request is presented in the figure below.
The input parameters of the DescribeSensor request are explained in the following table:
Input Name
service
version
Cardinality
1…1
1…1
Description
Service name (always SOS)
Service version (always 1.0.0 for Milestone 1.0)
37
DRAFT
3/18/2016
request
outputFormat
1…1
1…1
procedure
1…1
Operation name (always DescribeSensor)
The desired output format of the DescribeSensor operation;
for Milestone 1.0 must always be considered as
text/xml;subtype="sensorML/1.0.1/profiles/ioos_sos/1.0".
Defines the sensor, platform or network for which the description is to be returned.
The type is “anyURI”, and it must match the value of the “xlink:href=” attribute in
an <sos:procedure> element advertized in GetCapabilities response .
Examples:

Network
urn:ioos:network:test:all

Station/Platform
urn:ioos:station:test:station_name

Sensor
urn:ioos:sensor:test:station_name:sensor_name
The following examples illustrate HTTP/GET and HTTP/POST DescribeSensor 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?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>
4.2.2.2.2 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. An outline of such an all-inclusive DescribeSensor document is presented below.
38
DRAFT
3/18/2016
39
DRAFT
3/18/2016
<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">
40
DRAFT
3/18/2016
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.
4.2.2.2.2.1 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
41
DRAFT
3/18/2016
o
networkID
o
short name
o
long name (optional)

relevant contact information for this specific network

list of platforms of the network

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">
42
DRAFT
3/18/2016
<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>
43
DRAFT
3/18/2016
</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:
44
DRAFT
3/18/2016
Input Name
sml:capabilities
Cardinality
Description
1…1
Provides information of the IOOS template version.
1…1
The element that bounds the description of the network of platforms that is
specified in the “procedure” element of the DescribeSensor request. Sensor ML
document contains only one <member> element because only one
“procedure” parameter is allowed in SOS DescribeSensor request. Member
system description generally includes the following sections:

Name & Description

Temporal & Spatial Bounds

Identifiers

Classifiers

Contacts

Components (platforms/stations that belong to the network)
Depicts spatial bounds of the network segment that is described in the
document. All platforms that are located within the bounded segment must be
listed in the <sml:components> section of the document.
name="ioosServiceMetadata"
sml:member
Note: For
the elements
hereinafter in
this table,
the cardinality
is for each
<sml:member>
gml:boundedBy
1…1
sml:identification
1…1
In this template provides identity and alias information for the network itself
(in <sml:member/System> section), and for all component platforms (in
<sml:component/System> sections).
The networkID, shortName and longName are required for the network, and
for the platform, stationID, shortName and longName are mandatory.
The other appropriate identification information is optional but its
presentation is strongly encouraged.
A WMO ID is an optional identifier for now but it is recommended to specify it
for each platform when it is available.
sml:classification
1…1
In this template specifies classification values that describe the content of the
network offering with terms defined in external vocabularies. The reference to
at least one parent network with IOOS codespace and RA Acronym value is
required, e.g.:
<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:capabilities
1…1
Describes the valid time range over which observations from a whole network
or a component platform exist, as opposed to the <sml:validTyme>.
0…1
Lists all relevant contacts for the network. The mandatory contacts are
Publisher and Operator but any other relevant contact may be described here.
name="observationTimeRange"
sml:contact
It is strongly recommended to represent any reference to external resource
using an “xlink:href” attribute in the following manner:
<sml:contact xlink:href="http://sdf.ndbc.noaa.gov"/>, or
<sml:onlineResource xlink:href="http://pnw.buoyoperator.org"/>
IOOS Convention requires only <sml:country> and <sml:electronicMailAddress>
for the contact address. However, it is strongly recommended to provide as
detailed contact information as possible, e.g.
<sml:address>
<sml:deliveryPoint/>>
<sml:city/>
<sml:administrativeArea/>
<sml:postalCode/>
<sml:country/>
<sml:electronicMailAddress/>
</sml:address>
45
DRAFT
3/18/2016
sml:components
1…1
Lists all platforms in the network offering that are located within the spatial
segment defined in the <gml:boundedBy> element.
sml:component
1…*
Describes each individual platform from the list. The following elements and
associated attributes are required for each platform:
 <sml:identification>
to indicate stationID, shortName and longName for the specific platform;
if available, a WMO ID may be indicate as well;
 <sml:capabilities name="observationTimeRange">
to indicate observation time range;
 <sml:location/gml:Point>
to specify the 2D geographic location of the fixed platform(always in
EPSG::4326 CRS);
 <sml:outputs>
to specify the quantities observed by the platform
4.2.2.2.2.2 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

o
platformID
o
short name
o
long name
mandatory platform classifiers, such as
o
platformType
46
DRAFT
3/18/2016
o
operatorSector
o
publisher
o
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>
47
DRAFT
3/18/2016
<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>
48
DRAFT
3/18/2016
<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"/>
49
DRAFT
3/18/2016
</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;out
putformat=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;out
putformat=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;out
putformat=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;out
putformat=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">
50
DRAFT
3/18/2016
<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;out
putformat=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;out
putformat=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>
51
DRAFT
3/18/2016
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:
Input Name
sml:capabilities
Cardinality
Description
1…1
Provides information of the IOOS template version.
1…1
The element that bounds the description of the platform specified in the
“procedure” element of the DescribeSensor request. Sensor ML document
contains only one <member> element because SOS DescribeSensor request only
allows single “procedure”. Member system description must include the
following sections:

Platform Name & Description

Platform Identifiers

Platform Classifiers

Temporal Bounds for observations

List of the networks the platform belongs to

Contacts

Components (all sensors located on the platform)
name="ioosServiceMetadata"
sml:member
Note: For
the elements
hereinafter in
this table,
the cardinality
is for each
<sml:member>
sml:identification
1…1
In this template provides identity and alias information for the platform (in
<sml:member/System> section), and for all component sensors (in
<sml:component/System> sections).
For the platform, the stationID, shortName and longName are required;
however, only sensorID is mandatory for component sensors. In both cases,
other appropriate identification information is encouraged.
A WMO ID is an optional identifier for now but is strongly recommended for
each platform when it is available. The wmoID should be specified as a separate
identifier even if the main stationID URN uses the WMO authority:
<sml:identifier name="wmoID">
<sml:Term definition="http://mmisw.org/ont/ioos/definition/wmoID">
<sml:value>41001</sml:value>
</sml:Term>
</sml:identifier>
sml:classification
1…1
In this template specifies classification values that describe the content of the
network offering with terms defined in external vocabularies. The following
classifiers are mandatory for all platforms:





sml:validTime
0…1
parentNetwork (e.g. “NANOOS”)
(Note that at least one parent network must reference an IOOS
codespace and list the RA Acronym)
platformType (e.g. “buoy”)
operatorSector (e.g. “academic”)
publisher (e.g. “NANOOS”)
sponsor (e.g. “ACE”)
The <sml:validTime> is used only to specify a time period, in which this specific
DescribeSensor document is valid. The validity period usually goes from the
platform deployment date to today (indicated by 'now' in the example above) or
the end of the life of the platform.
The validity period may be different, however, if any of the sensors installed on
the platform had limited functionality due to some incident, got replaced or
removed. When such incident occurs, a new DescribeSensor document shall be
created with a validity period going from the date of that incident to the date of
the next one (or "now" if there were no more incidents), while the old
document shall be archived with a validity period ending at the date of the
52
DRAFT
3/18/2016
incident.
sml:capabilities
1…1
Describes the valid time range over which observations from a whole network or
a component platform exist.
1…1
A mandatory list of all the networks to which this platform/station belongs. In a
similar manner, the DescribeSensor document for sensor indicates the parent
station.
0…1
Lists all relevant contacts for the platform specified. The mandatory contacts are
Publisher and Operator but any other relevant contact may be described here.
name="observationTimeRange"
sml:capabilities
name="networkProcedures"
sml:contact
It is strongly recommended to represent any reference to external resource
using an “xlink:href” attribute in the following manner:
<sml:contact xlink:href="http://sdf.ndbc.noaa.gov"/>, or
<sml:onlineResource xlink:href="http://pnw.buoyoperator.org"/>
IOOS Convention requires only <sml:country> and <sml:electronicMailAddress>
for the contact address. However, it is strongly recommended to provide as
detailed contact information as possible, e.g. for the address:
<sml:address>
<sml:deliveryPoint/>>
<sml:city/>
<sml:administrativeArea/>
<sml:postalCode/>
<sml:country/>
<sml:electronicMailAddress/>
</sml:address>
sml:documentation
0…1
Specifes the external resources for human consumption about this platform and
the observation data it produces.
sml:history
0…1
Lists events and status changes of the platform such as deployment and
recovery.
sml:location
1…1
Specifes the geographic location of the platform in EPSG::4326 (lat, lon)
sml:components
1…1
Lists all sensors installed on the described platform.
sml:component
1…*
Describes each individual sensor from the component list. The sensor name
should be a human readable label.
The following 2 elements are mandatory for each sensor:
 <sml:identification>
to indicate sensorID for the specific sensor;
 <sml:outputs>
to specify the list of all quantities observed by the sensor.
The other 2 elements are optional but strongly recommended for each sensor:
 <sml:description>
to briefly describe the sensor in a human-readable form;
 <sml:documentation>
to specify the external resources for human consumption about this sensor
and the observation data it produces.
53
DRAFT
3/18/2016
4.2.2.2.2.3 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
o
sensorID
o
short name
o
long name

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:
Input Name
sml:capabilities
Cardinality
Description
1…1
Provides information of the IOOS template version.
1…1
The element that bounds the description of the sensor specified in the
“procedure” element of the DescribeSensor request. Sensor ML document
contains only one <member> element because SOS DescribeSensor request only
allows single “procedure”. Member system description must include the
following sections:

Sensor Name & Description

Sensor Identifiers

Sensor Capabilities

Observed properties associated with the sensor
In this template provides identity and alias information for the sensor. The
name="ioosServiceMetadata"
sml:member
Note: For
the elements
hereinafter in
this table,
the cardinality
is for each
<sml:member>
sml:identification
1…1
54
DRAFT
3/18/2016
sensorID and shortName are required; however, other appropriate
identification information may also be presented.
sml:validTime
0…1
The <sml:validTime> is used only to specify a time period, in which this specific
DescribeSensor document is valid. The validity period usually goes from the
sensor deployment date to today (indicated by 'now' in the example above),
unless the sensor had an incident that resulted in a limited functionality or
complete replacement. When such incident occurs, a new DescribeSensor
document shall be created with a validity period going from the date of that
incident to the date of the next one (or "now" if there were no more incidents),
while the old document shall be archived with a validity period ending at the
date of the incident.
sml:capabilities
1…1
Describes geo-object, which is a subject to the measured values and is measured
by sensor, i.e. the platform, which the sensor is installed on.
1…1
A list of all offerings associated with the sensor.
1…1
A parent station, which the sensor installed on; in this context, it is similar to the
“featureOfInterest”.
1…1
Describes the valid time range over which observations from the sensor exist, as
opposed to the <sml:validTime>.
sml:inputs
1…*
Describes the generic observed property, i.e. physical phenomena that are
measured by the sensor, e.g. Wind, Current, etc.
sml:outputs
1…*
Describes the specific results of the measurement of the input physical
phenomena, e.g. Wind speed, Wind direction, etc.
name="featuresOfInterest"
sml:capabilities
name="offerings"
sml:capabilities
name="stationProcedure"
sml:capabilities
name="observationTimeRange"
4.2.2.3 GetObservation
The 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.
55
DRAFT
3/18/2016
4.2.2.3.1 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 DescribeSensor request is presented in the figure below.
The required input parameters of the GetObservation request are explained in the following table:
Input Name
Cardinality
service
version
request
1…1
1…1
1…1
offering
1…1
observedProperty
1…*
Description
Service name (always SOS)
Service version
Operation name
Specifies the offering URN advertised in the GetCapabilities document.
GetObservation request to IOOS-compliant SOS server shall include ONLY one
offering, but may include multiple procedures instead (see below).
Specifies the phenomenon for which observations are requested as a URL of a
corresponding vocabulary record, e.g.
http://mmisw.org/ont/cf/parameter/air_temperature
56
DRAFT
3/18/2016
responseFormat
1…1
The desired output format of the GetObservation operation; must always be
considered as one of the supported output formats listed in <sos:responseFormat>
element in GetCapabilities document.
The OGC SOS v1.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:
procedure
0…*
eventTime
0…1
featureOfInterest
0…*
resultModel
0…*
srsName
0…1
result
0…1
responseMode
0…1
Specifies the sensor system(s) for which observations are requested; defines a filter
for the procedure property of the observations. The type is “anyURI”, and it must
match the value of the “xlink:href=” attribute in an <sos:procedure> element
advertized in GetCapabilities response .
Examples:

Network
urn:ioos:network:test:all

Station/Platform
urn:ioos:station:test:station_name

Sensor
urn:ioos:sensor:test:station_name:sensor_name
Specifies the time period(s) for which observations are requested.
The time should conform to ISO format: YYYY-MM-DDTHH:mm:ss±HH. Time
instance is given as one time value. Periods of time (start and end) are separated by
"/". For example: 2009-06-26T10:00:00+01/2009-06-26T11:00:00+01.
Although SOS v1.0 specification allows requests with no temporal boundaries, the
SOS v1.0 fails to properly describe the server response to such request. For that
specific case, the IOOS Convention requires SOS server to follow the SOS v2.0
specification, and return all records matching a user’s request. However, as a result
limit may be employed by the SOS server, a ResponseExceedsSizeLimit exception
code will be returned instead if that limit is exceeded.
Specifies the feature for which observations are requested. This should be
presented in a form of comma-separated URIs advertised in the GetCapabilities
document or a bounding box for requested data, i.e.
featureOfInterest=BBOX:min_lon,min_lat,max_lon,max_lat
Specifies the name of the root element of a GetObservation response. The IOOS
Convention requires resultModel to be “om:ObservationCollection”.
Attribute that defines the spatial reference system that should be used for any
geometry that is returned in the response.
If present, it must be one of the advertised CRS values specified in <gml:srsName>
element or “srsName” attribute of the <gml:boundedBy/gml:Envelope> element in
the GetCapabilities document.
If omitted, it's assumed that the CRS is WGS 84 identified as
urn:ogc:def:crs:EPSG::4326
Instructs the SOS to only return observations where the result matches the
expression or value. For example, CO-OPS supports a long list of constraints such as
IGLD (urn:ioos:def:datum:noaa::IGLD), MHHW (urn:ioos:def:datum:noaa::MHHW),
NAVD (urn:ogc:def:datum:epsg::5103), and so forth.
Specifies whether results are requested in-line, out-of-band, as an attachment or
resultTemplate.
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:
57
DRAFT
3/18/2016
unit
0…1
timeZone
0…1
epoch
0…1
dataType
0…1
Specifies units for requested water level predictions, harmonic constituents or
datums data. Valid values are

Meters

Feet
If no unit is specified, the data in meters is retrieved.
Specifies a time zone for requested harmonic constituents data only. Valid values
are

GMT

LST
If no time zone is specified, the data in GMT is retrieved.
Specifies the epoch for requested datums data only. Valid values are

Current

Superseded
If no epoch is specified, the accepted data (Current) is retrieved.
Specifies the data type for requested water level data or tide predictions. Valid
values are

PreliminarySixMinute

PreliminaryOneMinute

VerifiedSixMinute

VerifiedHourlyHeight

VerifiedHighLow

VerifiedDailyMean

SixMinuteTidePredictions

HourlyTidePredictions

HighLowTidePredictions
If no data type is specified, preliminary six minute data type is retrieved for water
level, six minute data type is retrieved for tide predictions.
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:ne
twork:test:all&observedProperty=http://mmisw.org/Font/cf/parameter/wind_speed&procedure=urn:ioos”station:test:blighreef&
responseFormat=text/xml;subtype="om/1.0.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/Font/cf/parameter/wind_speed</sos:observedProperty>
<sos:responseFormat>text/xml; subtype=’om/1.0.0’</sos:responseFormat>
<sos:resultModel>om:Observation</sos:resultModel>
<sos:responseMode>inline</sos:responseMode>
</sos:GetObservation>
58
DRAFT
3/18/2016
4.2.2.3.2 GetObservation Response
GetObservation 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 SWEGetObservation 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
All these templates may be found at ioostech Wiki whereas only critical templates’ components are
discussed hereinafter just in order to limit the size of the document; however, all nesessary 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.
4.2.2.3.2.1 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"
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>
59
DRAFT
3/18/2016
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>
60
DRAFT
3/18/2016
OM-GetObservation template in more details:
<om:ObservationCollection
xmlns:om="http://www.opengis.net/om/1.0"
xmlns:gml="http://www.opengis.net/gml"
xmlns:swe="http://www.opengis.net/swe/1.0.1"
xmlns:swe2="http://www.opengis.net/swe/2.0"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.opengis.net/om/1.0 http://schemas.opengis.net/om/1.0.0/om.xsd">
<gml:metaDataProperty xlink:title="disclaimer">
<gml:GenericMetaData>
<gml:description>DISCLAIMER</gml:description>
</gml:GenericMetaData>
</gml:metaDataProperty>
<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>
<om:member>
<om:Observation>
<gml:description>
Observations at point station urn:ioos:station:wmo:41001, 150 NM East of Cape
HATTERAS. Observations at point station urn:ioos:station:wmo:41002, S HATTERAS
- 250 NM East of Charleston, SC
</gml:description>
<om:samplingTime>
<gml:TimePeriod>
<gml:beginPosition>2009-05-23T00:00:00Z</gml:beginPosition>
<gml:endPosition>2009-05-23T02:00:00Z</gml:endPosition>
</gml:TimePeriod>
</om:samplingTime>
<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="5"
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_direction" />
<swe:component xlink:href="http://mmisw.org/ont/cf/parameter/sea_water_temperature" />
<swe:component xlink:href="http://mmisw.org/ont/ioos/parameter/dissolved_oxygen" />
</swe:CompositePhenomenon>
</om:observedProperty>
<om:featureOfInterest>
<gml:FeatureCollection>
<gml:metaDataProperty>
<gml:name codeSpace="http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-conventions.html#discretesampling-geometries">timeSeries</gml:name>
</gml:metaDataProperty>
<gml:boundedBy>
<gml:Envelope srsName="http://www.opengis.net/def/crs/EPSG/0/4326">
<gml:lowerCorner>32.38 -75.42</gml:lowerCorner>
<gml:upperCorner>34.7 -72.73</gml:upperCorner>
61
DRAFT
3/18/2016
</gml:Envelope>
</gml:boundedBy>
<gml:location>
<gml:MultiPoint
srsName="http://www.opengis.net/def/crs/EPSG/0/4326">
<gml:pointMembers>
<gml:Point>
<gml:name>urn:ioos:station:wmo:41001</gml:name>
<gml:pos>34.7 -72.73</gml:pos>
</gml:Point>
<gml:Point>
<gml:name>urn:ioos:station:wmo:41002</gml:name>
<gml:pos>32.382 -75.415</gml:pos>
</gml:Point>
</gml:pointMembers>
</gml:MultiPoint>
</gml:location>
</gml:FeatureCollection>
</om:featureOfInterest>
<om:result>
<!-- This block contains a SWE DataRecord conforming to the
-->
<!-- appropriate SWE-GetObservation template in Milestone 1.0.
-->
</om:result>
</om:Observation>
</om:member>
<om:member>
<!-- A different feature type may be returned in this member observation -->
</om:member>
</om:ObservationCollection>
Input Name
gml:metaDataProperty
Cardinality
0…1
Provides a human-readable disclaimer (if required) bounded by
<gml:description>.
1…1
Provides information of the IOOS template version.
1…*
A GetObservation response shall contain at least one member observation
that reports offerings. All stations corresponding to the same CF feature type
(discrete-sampling-geometries) shall be reported in a single <om:member >
block. Conversely, if the GetObservation request contains more than one
feature type, then each feature type shall be reported in a separate member
observation block.
Member system description generally includes the following sections:

Observation description

Temporal bounds for observations

List of stations reporting observations

List of the observed phenomena

Spatial bounds and other feature-type metadata

Observation result block
Single result block may contain values from multiple stations and multiple
sensors of the same feature type.
A recommended fairly free-form human-readable text that describes
observations, including station(s) name and location as well as sensor or
procedure information.
xlink:title="disclaimer"
gml:metaDataProperty
Description
xlink:title="ioosTemplateVersion"
om:member
Note: For
the elements
hereinafter in
this table,
the cardinality
is for each
<om:member>
gml:description
0…1
om:samplingTime
1…1
The samplingTime bounds the time when the result applies to the feature-ofinterest, encoded as a TimeInstant or TimePeriod ISO8601 string or using the
indeterminatePosition attribute (e.g. 'now'). Currently only UTC (Z) is
62
DRAFT
3/18/2016
supported. This time usually required for geospatial analysis of the result.
om:procedure
1…1
This element contains the official IOOS identifiers for the platforms in a form
of URN that conforms to the IOOS Conventions for Observing Asset
Identifiers.
The IOOS Convention requires that multiple platforms/stations are listed as
members of a single process, e.g.:
<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
1…1
A description of the phenomena that are being estimated through
observation, e.g. "wave", "temperature", "wind", etc.
The IOOS Convention requires that
 This element has a value of a URL corresponding to a Climate and
Forecast (CF) Standard Name of the record in one of the IOOS
Vocabularies that are currently hosted by the Marine Metadata
Interoperability (MMI) project.
 Both vector (namely winds, currents and waves), and scalar variables are
described as composite phenomena using
<swe:CompositePhenomenon> element, even when the response
returns a single observed property. The supported true composite
(vector) phenomena are defined in the IOOS Parameter Vocabulary
(e.g.: http://mmisw.org/ont/ioos/parameter/wave).
 Each <swe:CompositePhenomenon> must have a document-wide
unique <gml:id> attribute (it is recommended to use just a simple
integer counter next to a fixed string).
 Each <swe:CompositePhenomenon> must have a child element
<gml:name> with a value of any human-readable text string.
 Each <swe:CompositePhenomenon> must always be expanded to the
list of the constituent scalar properties.
 The exact collection of individual scalar properties that is used by a
service provider to form a certain composite phenomenon shall be a
subset of the properties defined in the IOOS Parameter Vocabulary for
that composite phenomenon.
EXAMPLE 1 (multiple scalar properties):
<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>
EXAMPLE 2 (single scalar property):
<om:observedProperty>
<swe:CompositePhenomenon dimension="1"
gml:id="observedproperties1">
<gml:name>Response Observed Properties</gml:name>
63
DRAFT
3/18/2016
<swe:component
xlink:href="http://mmisw.org/ont/cf/parameter/wind_speed"/>
</swe:CompositePhenomenon>
</om:observedProperty>
om:featureOfInterest
1…1
Encompasses all spatial and feature-type response metadata assotiated with
the CF Feature Type (e.g., timeSeries, timeSeriesProfile, etc).
IOOS Convention requires that the GetObservation response keeps the SWE
elements the same between all FeatureTypes within <gml:FeatureCollection>:
<om:featureOfInterest>
<gml:FeatureCollection>
<gml:metaDataProperty/>
<gml:boundedBy/>
<gml:location/>
</gml:FeatureCollection>
</om:featureOfInterest>
gml:metaDataProperty
1…1
Contains the name and codeSpace values for the CF Feature Type:
<gml:metaDataProperty>
<gml:name codeSpace="http://cf-pcmdi.llnl.gov/documents/cfconventions/1.6/cf-conventions.html#discrete-samplinggeometries">timeSeries</gml:name>
</gml:metaDataProperty>
gml:boundedBy
1…1
Defines a geographic (lat/lon) Bounding Box of the featureOfInterest.
gml:location
1…1
Describes the individual platform/station geographical location information
(2D only, always in EPSG::4326). Despite having been “deprecated” (i.e., "not
recommended to use") by OGC since GML 3.1.0, the IOOS Convention
requires <gml:location> as the least complex and all-sufficient structure
among many options of reporting station position. For uniformity, the IOOS
Conventions imposes certain constraints on the geospatial metadata
representation:
 both single- and multi-station response must report locations using the
same <gml:MultiPoint> structure, i.e.
- for single station:
<gml:location>
<gml:MultiPoint
srsName="http://www.opengis.net/def/crs/EPSG/0/4326">
<gml:pointMembers>
<gml:Point>
<gml:name>urn:ioos:station:wmo:41001</gml:name>
<gml:pos>34.7 -72.73</gml:pos>
</gml:Point>
</gml:pointMembers>
</gml:MultiPoint>
</gml:location>
- for multiple stations:
<gml:location>
<gml:MultiPoint
srsName="http://www.opengis.net/def/crs/EPSG/0/4326">
<gml:pointMembers>
<gml:Point>
<gml:name>urn:ioos:station:wmo:41001</gml:name>
<gml:pos>34.7 -72.73</gml:pos>
</gml:Point>
64
DRAFT
3/18/2016
<gml:Point>
<gml:name>urn:ioos:station:wmo:41004</gml:name>
<gml:pos>32.5 -79.09</gml:pos>
</gml:Point>
<gml:Point>
<gml:name>urn:ioos:station:wmo:41008</gml:name>
<gml:pos>31.4 -80.87</gml:pos>
</gml:Point>
</gml:pointMembers>
</gml:MultiPoint>
</gml:location>
om:result
1…1
 <gml:name> element shall be used to associate the stationID with the
station coordinates in both multi- and single-station responses.
This block contains a SWE Data Record for a specific feature type conforming
to the corresponding SWE-GetObservation template in Milestone 1.0.
4.2.2.3.2.2 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:
65
DRAFT
3/18/2016
<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">
66
DRAFT
3/18/2016
<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) connected with
underscores instead of the colons, e.g. sensorID urn:ioos:sensor:wmo:41001:sensor1 transformes into
wmo_41001_sensor1. These abbreviated sensor URNs are used as the sensor's DataRecord ID in the static
block and the DataChoice item name in the dynamic block. Consequently they 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.
In a similar manner, an abbreviated station ID is composed of the authority and label parts of a full station
ID, i.e. the station ID 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.
4.2.2.3.2.2.1 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 below:
67
DRAFT
3/18/2016
<swe2:DataRecord>
<swe2:field name="stations">
<swe2:DataRecord>
<swe2:field name="wmo_489">
<swe2:DataRecord id="wmo_489"
[ STATION 1 DATA ]
<swe2:field name="sensors">
<swe2:DataRecord>
<swe2:field name="wmo_489_sensor1">
<swe2:DataRecord id="wmo_489_sensor1"
[ STATION 1/SENSOR 1 DATA ]
</swe2:DataRecord id="wmo_489_sensor1"
</swe2:field name="wmo_489_sensor1">
SENSOR 1
ALL SENSORS
FOR STATION 1
[…]
<swe2:field name="wmo_489_sensorX">
<swe2:DataRecord id="wmo_489_sensorX"
[ STATION 1/SENSOR X DATA ]
</swe2:DataRecord id="wmo_489_sensorX"
</swe2:field name="wmo_489_sensorX">
</swe2:DataRecord>
</swe2:field name="sensors">
</swe2:DataRecord id="wmo_489"
</swe2:field name="wmo_489">
STATION 1
SENSOR X
[…]
<swe2:field name="wmo_523">
<swe2:DataRecord id="wmo_523"
[ STATION N DATA ]
<swe2:field name="sensors">
<swe2:DataRecord>
<swe2:field name="wmo_523_sensor1">
<swe2:DataRecord id="wmo_523_sensor1"
[ STATION N/SENSOR 1 DATA ]
</swe2:DataRecord id="wmo_523_sensor1"
</swe2:field name="wmo_523_sensor1">
SENSOR 1
ALL SENSORS
FOR STATION N
[…]
<swe2:field name="wmo_523_sensorY">
<swe2:DataRecord id="wmo_523_sensorY"
[ STATION N/SENSOR Y DATA ]
</swe2:DataRecord id="wmo_523_sensorY"
</swe2:field name="wmo_523_sensorY">
</swe2:DataRecord>
</swe2:field name="sensors">
</swe2:DataRecord id="wmo_523"
</swe2:field name="wmo_523">
</swe2:DataRecord>
</swe2:field>
</swe2:DataRecord>
STATION N
SENSOR Y
Although the IOOS Convention does not prescribe in general 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
68
DRAFT
3/18/2016
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>
69
DRAFT
3/18/2016
<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 platformLocation includes three-dimensional definition of the platform geo-spatial position. The
platform’s position has to be described as a vector that specifies a platform referenceFrame, and associates
it with the platform’s unique localFrame for sensors’ positioning.
The referenceFrame is defined by the pair of the platform’s coordinates (latitude and longitude), and the
platform height relative to some datum level. For the referenceFrame definition, the IOOS Convention has
developed a new compound CRS that combines the EPSG::4326 (WGS84) for horizontal coordinates, and a
vertical CRS for the platform’s vertical position, which uses height as a datum.
The Convention requires that for floating surface buoys, this compound CRS includes the EPSG::5829
vertical CRS, which uses height above the Instantanious Water Level as a datum. For a tide gauge or a
platform at a fixed location relative to the Geoid (MSL), the vertical CRS must be EPSG::4979
(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/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. 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:
70
DRAFT
3/18/2016
<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>
4.2.2.3.2.2.1.1 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>
4.2.2.3.2.2.1.2 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).
71
DRAFT
3/18/2016
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 local frame 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 local frame is referenced to the CRS in the same manner as the station’s
one:
<swe2:field name="sensorLocation">
<swe2:Vector
definition=http://www.opengis.net/def/property/OGC/0/SensorLocation referenceFrame="http://www.opengis.net/def/crscompound?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 has to be reported in terms of the yaw, pitch and roll angles using the CF
Conventions standard name parameters: platform_orientation (i.e. yaw angle), platform_pitch_angle, and
platform_roll_angle. Just for reference, the figure below depicts a relation of those angles:
The following fragment of the IOOS Milestone 1.0 GetObservations 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"
72
DRAFT
3/18/2016
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 GetObservations document instead of the static data block. In
such case, the orientation parameter values must be block-encoded along with other observations data
(details of the block-encoded data representation in GetObservations document are provided in section
4.2.2.3.2.2.2).
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 (details of the blockencoded data representation in GetObservations document are provided in section 4.2.2.3.2.2.2). 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">
73
DRAFT
3/18/2016
<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>
Similar to the description of binned sensors, the IOOS Convention requires a description of the fixed vertical
observation positions 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:
74
DRAFT
3/18/2016
<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>
4.2.2.3.2.2.2 Dynamic Data (Sensor Observations) Block
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:
75
DRAFT
3/18/2016
<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>
76
DRAFT
3/18/2016
</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 as far as sampling
time is related to all sensors; however, if sampling time is defined differently for some sensors it should be
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>
As each sensor may perform various set of observations, and thus has to be reported in a separate manner,
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 from 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; the same names are then repeated in the sensor records in
the <swe2:values> block.
Although specifying the missing or out of range values is completely optional, it shall follow the
SWECommon standard requirements, if implemented. 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>
Each DataChoice item contains a separate DataRecord that describes the dynamic sensor features such as
observedProperty, units of measure, etc.:
<swe2:field name=”sensor”>
<swe2:DataChoice definition="http://mmisw.org/ont/ioos/definition/sensors">
<swe2:item name="wmo_41001_sensor1">
77
DRAFT
3/18/2016
<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">
78
DRAFT
3/18/2016
<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 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 “&#10;”:
<swe2:encoding>
<swe2:TextEncoding
decimalSeparator="."
tokenSeparator=","
blockSeparator="&#10;" />
</swe2:encoding>
The <swe2:values> block reports the observation values as they were defined in the previous sections of the
dynamic data block. The number of records matches the <swe2:elementCount> value; each record contains
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”&#10;” but must be used as-is instead. The IOOS Convention also requires that the sensor
names unambiguously correspond to the DataChoice item names:
<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>
79
DRAFT
3/18/2016
4.2.2.3.2.2.2.1 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 before description of observations:
<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
DataArrays inside in <swe2:Quantity>. The fragment of the Milestone1.0 template below illustrates that
concept for a 2-component DQA flag; to simplify the description, 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">
80
DRAFT
3/18/2016
<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>
81
DRAFT
3/18/2016
<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>
4.2.2.3.2.2.2.2 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. The
IOOS Convention requires that a nested DataArray element is used for each profiling sensor description in a
DataChoice structure in order to provide for encoding of multiple simultaneous observations in one record.
The value that specifies the dimension of that inner DataArray must always be omitted in the inline
<swe2:elementCount>; instead, it must be specified in each of the <swe2:values> block-encoded records to
allow indication of the number of heights being encoded in this record.
Another <swe2:Count> element in a profileIndex or binIndex field that preceeds each set of observation
values is required by the IOOS Convention to indicate which height/bin is being reported (binIndex and
profileIndex correspond respectively to profileBins or profileHeights in the static data block).
Similar to the non-profiling sensors, the names of the DataChoice items must correspond to the sensor
names in the static sensors’ DataRecord in order to ensure the proper linkage to the static data block; the
same names shall then be repeated in the sensor records 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 />
82
DRAFT
3/18/2016
</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>
83
DRAFT
3/18/2016
</swe2:field>
</swe2:DataRecord>
</swe2:elementType>
</swe2:DataArray>
</swe2:field>
</swe2:DataRecord>
</swe2:item>
</swe2:DataChoice>
4.3 SERVICE IMPLEMENTATION
4.3.1 SOS End Points
4.3.1.1
SOS 52 North End Point
4.3.1.1.1 Associated Interface
Interface Name
Description
SOS 52N
4.3.1.1.2 Communication Protocol
Name
Description
Version
Location
HTTP
Hypertext Transfer Protocol
1.1
http://www.w3.org/Protocols/
4.3.1.1.3 Messaging Protocol
Name
Description
Version
Location
4.3.1.1.4 Network Address
IP Address
TBD
4.3.1.1.5 End Point-Specific Qualities of Service
Qualities of Service identified for the web service in Section 4.1.5 also apply to the end point. No end pointspecific qualities have been identified.
4.3.1.2
ncSOS End Point
4.3.1.2.1 Associated Interface
Interface Name
ncSOS
84
DRAFT
3/18/2016
Description
This service provides SOS access to data in netCDF files.
4.3.1.2.2 Communication Protocol
Name
Description
Version
Location
HTTP
Hypertext Transfer Protocol
1.1
http://www.w3.org/Protocols/
4.3.1.2.3 Messaging Protocol
Name
Description
Version
Location
4.3.1.2.4 Network Address
IP Address
TBD
4.3.1.2.5 End Point-Specific Qualities of Service
Qualities of Service identified for the web service in Section 4.1.5 also apply to the end point. No end pointspecific qualities have been identified.
5 APPENDIXES
5.1 SWE Common Templates Milestone 1.0
5.1.1 TimeSeries records for single station with a single sensor
<!-- 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. -->
<swe2:DataRecord
xmlns:swe2="http://www.opengis.net/swe/2.0"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.opengis.net/swe/2.0 http://schemas.opengis.net/sweCommon/2.0/swe.xsd"
definition="http://mmisw.org/ont/ioos/swe_element_type/observationRecord">
85
DRAFT
3/18/2016
<!-- 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="http://mmisw.org/ont/ioos/swe_element_type/stations">
<!-- 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"
definition="http://mmisw.org/ont/ioos/swe_element_type/station">
<swe2:field name="stationID">
<!-- IoosTech Convention: -->
<!-- The text element containing the station id shall be defined -->
<swe2:Text definition="http://mmisw.org/ont/ioos/definition/stationID">
<swe2:value>urn:ioos:station:wmo:41001</swe2:value>
</swe2:Text>
</swe2:field>
<!-- 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="http://www.opengis.net/def/property/OGC/0/PlatformLocation"
referenceFrame="http://www.opengis.net/def/crscompound?1=http://www.opengis.net/def/crs/EPSG/0/4326&amp;2=http://www.opengis.net/def/crs/EPSG/0/5829"
localFrame="#wmo_41001_frame">
<!-- 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="http://www.opengis.net/def/crs/EPSG/0/4979" -->
<!-- -->
<!-- Each stations localFrame must be unique. -->
<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">
86
DRAFT
3/18/2016
<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>
<!-- 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 -->
</swe2:Quantity>
</swe2:coordinate>
</swe2:Vector>
</swe2:field>
<!-- 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="http://mmisw.org/ont/ioos/swe_element_type/sensors">
<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"
definition="http://mmisw.org/ont/ioos/swe_element_type/sensor">
<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="http://mmisw.org/ont/ioos/definition/sensorID">
<swe2:value>urn:ioos:sensor:wmo:41001:sensor1</swe2:value>
</swe2:Text>
</swe2:field>
<!-- 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="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>
</swe2:DataRecord>
</swe2:field>
</swe2:DataRecord>
</swe2:field>
</swe2:DataRecord>
</swe2:field>
</swe2:DataRecord>
</swe2:field>
87
DRAFT
3/18/2016
<!-- DYNAMIC DATA (SENSOR OBSERVATIONS) -->
<!-- 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="http://mmisw.org/ont/ioos/swe_element_type/sensorObservationCollection">
<!-- Count of records in swe:values -->
<swe2:elementCount>
<swe2:Count>
<swe2:value>3</swe2:value>
</swe2:Count>
</swe2:elementCount>
<!-- 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="http://mmisw.org/ont/ioos/swe_element_type/sensorObservations">
<!-- 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="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>
<!-- 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="http://mmisw.org/ont/ioos/swe_element_type/sensors">
<!-- 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="http://mmisw.org/ont/ioos/swe_element_type/sensor">
<!-- wmo_41001_sensor1's observed properties -->
<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>
88
DRAFT
3/18/2016
</swe2:item>
<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 -->
</swe2:DataChoice>
</swe2:field>
</swe2:DataRecord>
</swe2:elementType>
<swe2:encoding>
<!-- 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. -->
<swe2:TextEncoding
decimalSeparator="."
tokenSeparator=","
blockSeparator="&#10;" />
</swe2:encoding>
<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
</swe2:values>
</swe2:DataArray>
</swe2:field>
</swe2:DataRecord>
5.1.2 TimeSeries records for multiple stations
<!-- This template is an example of a SWE Data Record composed of static and dynamic fields for -->
<!-- multiple stations with multiple sensors -->
<!-- -->
<!-- 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 3 Stations: -->
<!-- Station 1 has 2 sensors -->
89
DRAFT
3/18/2016
<!-- Station 2 has 2 sensors -->
<!-- Station 3 has 1 sensors -->
<swe2:DataRecord
xmlns:swe2="http://www.opengis.net/swe/2.0"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.opengis.net/swe/2.0 http://schemas.opengis.net/sweCommon/2.0/swe.xsd"
definition="http://mmisw.org/ont/ioos/swe_element_type/observationRecord">
<!-- 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="http://mmisw.org/ont/ioos/swe_element_type/stations">
<!-- 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"
definition="http://mmisw.org/ont/ioos/swe_element_type/station">
<swe2:field name="stationID">
<!-- IoosTech Convention: -->
<!-- The text element containing the station id shall be defined -->
<swe2:Text definition="http://mmisw.org/ont/ioos/definition/stationID">
<swe2:value>urn:ioos:station:wmo:41001</swe2:value>
</swe2:Text>
</swe2:field>
<!-- 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="http://www.opengis.net/def/property/OGC/0/PlatformLocation"
referenceFrame="http://www.opengis.net/def/crscompound?1=http://www.opengis.net/def/crs/EPSG/0/4326&amp;2=http://www.opengis.net/def/crs/EPSG/0/5829"
localFrame="#wmo_41001_frame">
<!-- 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="http://www.opengis.net/def/crs/EPSG/0/4979" -->
90
DRAFT
3/18/2016
<!-- -->
<!-- Each stations localFrame must be unique. -->
<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>
<!-- 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 -->
</swe2:Quantity>
</swe2:coordinate>
</swe2:Vector>
</swe2:field>
<!-- 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="http://mmisw.org/ont/ioos/swe_element_type/sensors">
<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"
definition="http://mmisw.org/ont/ioos/swe_element_type/sensor">
<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="http://mmisw.org/ont/ioos/definition/sensorID">
<swe2:value>urn:ioos:sensor:wmo:41001:sensor1</swe2:value>
</swe2:Text>
</swe2:field>
<!-- 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="http://mmisw.org/ont/cf/parameter/height"
axisID="Z"
referenceFrame="#wmo_41001_frame">
<swe2:uom code="m" />
<swe2:value>5</swe2:value>
</swe2:Quantity>
91
DRAFT
3/18/2016
</swe2:field>
</swe2:DataRecord>
</swe2:field>
<swe2:field name="wmo_41001_sensor2">
<!-- 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_sensor2"
definition="http://mmisw.org/ont/ioos/swe_element_type/sensor">
<swe2:field name="sensorID">
<!-- IoosTech Convention: -->
<!-- The text element containing the sensor id shall be defined -->
<swe2:Text definition="http://mmisw.org/ont/ioos/definition/sensorID">
<swe2:value>urn:ioos:sensor:wmo:41001:sensor2</swe2:value>
</swe2:Text>
</swe2:field>
<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>-2</swe2:value>
</swe2:Quantity>
</swe2:field>
</swe2:DataRecord>
</swe2:field>
</swe2:DataRecord>
</swe2:field>
</swe2:DataRecord>
</swe2:field>
<!-- Station 2 static data -->
<swe2:field name="wmo_41002">
<!-- IoosTech Convention: -->
<!-- The data record containing the static data for a station shall be defined -->
<swe2:DataRecord id="wmo_41002"
definition="http://mmisw.org/ont/ioos/swe_element_type/station">
<swe2:field name="stationID">
<!-- IoosTech Convention: -->
<!-- The text element containing the station id shall be defined -->
<swe2:Text definition="http://mmisw.org/ont/ioos/definition/stationID">
<swe2:value>urn:ioos:station:wmo:41002</swe2:value>
</swe2:Text>
</swe2:field>
<swe2:field name="platformLocation">
<swe2:Vector definition="http://www.opengis.net/def/property/OGC/0/PlatformLocation"
referenceFrame="http://www.opengis.net/def/crscompound?1=http://www.opengis.net/def/crs/EPSG/0/4326&amp;2=http://www.opengis.net/def/crs/EPSG/0/5829"
localFrame="#wmo_41002_frame">
<swe2:coordinate name="latitude">
<swe2:Quantity definition="http://mmisw.org/ont/cf/parameter/latitude" axisID="Lat">
<swe2:uom code="deg" />
<swe2:value>32.5</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" />
92
DRAFT
3/18/2016
<swe2:value>-78.5</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</swe2:value>
</swe2:Quantity>
</swe2:coordinate>
</swe2:Vector>
</swe2:field>
<swe2:field name="sensors">
<!-- IoosTech Convention: -->
<!-- The data record containing the static data for each sensor shall be defined -->
<swe2:DataRecord definition="http://mmisw.org/ont/ioos/swe_element_type/sensors">
<swe2:field name="wmo_41002_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_41002_sensor1"
definition="http://mmisw.org/ont/ioos/swe_element_type/sensor">
<swe2:field name="sensorID">
<!-- IoosTech Convention: -->
<!-- The text element containing the sensor id shall be defined -->
<swe2:Text definition="http://mmisw.org/ont/ioos/definition/sensorID">
<swe2:value>urn:ioos:sensor:wmo:41002:sensor1</swe2:value>
</swe2:Text>
</swe2:field>
<swe2:field name="height">
<swe2:Quantity definition="http://mmisw.org/ont/cf/parameter/height"
axisID="Z"
referenceFrame="#wmo_41002_frame">
<swe2:uom code="m" />
<swe2:value>3</swe2:value>
</swe2:Quantity>
</swe2:field>
</swe2:DataRecord>
</swe2:field>
<swe2:field name="wmo_41002_sensor2">
<!-- IoosTech Convention: -->
<!-- The data record containing the static data for a sensor shall be defined -->
<swe2:DataRecord id="wmo_41002_sensor2"
definition="http://mmisw.org/ont/ioos/swe_element_type/sensor">
<swe2:field name="sensorID">
<!-- IoosTech Convention: -->
<!-- The text element containing the sensor id shall be defined -->
<swe2:Text definition="http://mmisw.org/ont/ioos/definition/sensorID">
<swe2:value>urn:ioos:sensor:wmo:41002:sensor2</swe2:value>
</swe2:Text>
</swe2:field>
<swe2:field name="height">
<swe2:Quantity definition="http://mmisw.org/ont/cf/parameter/height"
axisID="Z"
referenceFrame="#wmo_41002_frame">
<swe2:uom code="m" />
<swe2:value>-5</swe2:value>
</swe2:Quantity>
</swe2:field>
93
DRAFT
3/18/2016
</swe2:DataRecord>
</swe2:field>
</swe2:DataRecord>
</swe2:field>
</swe2:DataRecord>
</swe2:field>
<!-- Station 3 static data -->
<swe2:field name="wmo_41003">
<!-- IoosTech Convention: -->
<!-- The data record containing the static data for a station shall be defined -->
<swe2:DataRecord id="wmo_41003"
definition="http://mmisw.org/ont/ioos/swe_element_type/station">
<swe2:field name="stationID">
<!-- IoosTech Convention: -->
<!-- The text element containing the station id shall be defined -->
<swe2:Text definition="http://mmisw.org/ont/ioos/definition/stationID">
<swe2:value>urn:ioos:station:wmo:41003</swe2:value>
</swe2:Text>
</swe2:field>
<swe2:field name="platformLocation">
<swe2:Vector definition="http://www.opengis.net/def/property/OGC/0/PlatformLocation"
referenceFrame="http://www.opengis.net/def/crscompound?1=http://www.opengis.net/def/crs/EPSG/0/4326&amp;2=http://www.opengis.net/def/crs/EPSG/0/5829"
localFrame="#wmo_41003_frame">
<swe2:coordinate name="latitude">
<swe2:Quantity definition="http://mmisw.org/ont/cf/parameter/latitude" axisID="Lat">
<swe2:uom code="deg" />
<swe2:value>33.5</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>-79.5</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</swe2:value>
</swe2:Quantity>
</swe2:coordinate>
</swe2:Vector>
</swe2:field>
<swe2:field name="sensors">
<!-- IoosTech Convention: -->
<!-- The data record containing the static data for each sensor shall be defined -->
<swe2:DataRecord definition="http://mmisw.org/ont/ioos/swe_element_type/sensors">
<swe2:field name="wmo_41003_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_41003_sensor1"
definition="http://mmisw.org/ont/ioos/swe_element_type/sensor">
<swe2:field name="sensorID">
<!-- IoosTech Convention: -->
<!-- The text element containing the sensor id shall be defined -->
<swe2:Text definition="http://mmisw.org/ont/ioos/definition/sensorID">
94
DRAFT
3/18/2016
<swe2:value>urn:ioos:sensor:wmo:41003:sensor1</swe2:value>
</swe2:Text>
</swe2:field>
<swe2:field name="height">
<swe2:Quantity definition="http://mmisw.org/ont/cf/parameter/height"
axisID="Z"
referenceFrame="#wmo_41003_frame">
<swe2:uom code="m" />
<swe2:value>3</swe2:value>
</swe2:Quantity>
</swe2:field>
</swe2:DataRecord>
</swe2:field>
</swe2:DataRecord>
</swe2:field>
</swe2:DataRecord>
</swe2:field>
</swe2:DataRecord>
</swe2:field>
<!-- DYNAMIC DATA (SENSOR OBSERVATIONS) -->
<!-- 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="http://mmisw.org/ont/ioos/swe_element_type/sensorObservationCollection">
<!-- Count of records in swe:values -->
<swe2:elementCount>
<swe2:Count>
<swe2:value>13</swe2:value>
</swe2:Count>
</swe2:elementCount>
<!-- 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="http://mmisw.org/ont/ioos/swe_element_type/sensorObservations">
<!-- 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="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>
<!-- 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="http://mmisw.org/ont/ioos/swe_element_type/sensors">
<!-- 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 -->
95
DRAFT
3/18/2016
<swe2:DataRecord definition="http://mmisw.org/ont/ioos/swe_element_type/sensor">
<!-- wmo_41001_sensor1's observed properties -->
<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/swe_element_type/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/swe_element_type/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/swe_element_type/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/swe_element_type/sensor">
<swe2:field name="air_temperature">
96
DRAFT
3/18/2016
<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>
</swe2:DataRecord>
</swe2:elementType>
<swe2:encoding>
<!-- 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. -->
<swe2:TextEncoding
decimalSeparator="."
tokenSeparator=","
blockSeparator="&#10;" />
</swe2:encoding>
<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>
</swe2:DataArray>
</swe2:field>
</swe2:DataRecord>
97
DRAFT
3/18/2016
5.1.3 TimeSeries records for multiple stations with multiple sensors including quality
elements for some quantities
<!-- This template is an example of a SWE Data Record composed of static and dynamic fields for -->
<!-- multiple stations with multiple sensors including quality elements for some quantities. -->
<!-- -->
<!-- This template is almost identical to the SWE-Multisation-TimeSeries with the addition of some -->
<!-- quality elements. Quality flags for static and dynamic data are included for station1 sensor 1.-->
<!-- An example of NilValue is also provided for wind speed in station 1 sensor 1 -->
<!-- -->
<!-- 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 3 Stations: -->
<!-- Station 1 has 2 sensors -->
<!-- Station 2 has 2 sensors -->
<!-- Station 3 has 1 sensors -->
<swe2:DataRecord
xmlns:swe2="http://www.opengis.net/swe/2.0"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.opengis.net/swe/2.0 http://schemas.opengis.net/sweCommon/2.0/swe.xsd"
definition="http://mmisw.org/ont/ioos/swe_element_type/observationRecord">
<!-- 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="http://mmisw.org/ont/ioos/swe_element_type/stations">
<!-- 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"
definition="http://mmisw.org/ont/ioos/swe_element_type/station">
<swe2:field name="stationID">
<!-- IoosTech Convention: -->
<!-- The text element containing the station id shall be defined -->
<swe2:Text definition="http://mmisw.org/ont/ioos/definition/stationID">
<swe2:quality>
<!-- Optional element can contain any valid static quality element for this station -->
</swe2:quality>
<swe2:value>urn:ioos:station:wmo:41001</swe2:value>
</swe2:Text>
</swe2:field>
<!-- The platformLocation may be defined here, statically, or specified in the dynamic -->
98
DRAFT
3/18/2016
<!-- 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="http://www.opengis.net/def/property/OGC/0/PlatformLocation"
referenceFrame="http://www.opengis.net/def/crscompound?1=http://www.opengis.net/def/crs/EPSG/0/4326&amp;2=http://www.opengis.net/def/crs/EPSG/0/5829"
localFrame="#wmo_41001_frame">
<!-- 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="http://www.opengis.net/def/crs/EPSG/0/4979" -->
<!-- -->
<!-- Each stations localFrame must be unique. -->
<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>
<!-- 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 -->
</swe2:Quantity>
</swe2:coordinate>
</swe2:Vector>
</swe2:field>
<!-- 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="http://mmisw.org/ont/ioos/swe_element_type/sensors">
<swe2:field name="wmo_41001_sensor1">
<!-- IoosTech Convention: -->
<!-- The data record containing the static data for a sensor shall be defined -->
99
DRAFT
3/18/2016
<!-- 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"
definition="http://mmisw.org/ont/ioos/swe_element_type/sensor">
<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="http://mmisw.org/ont/ioos/definition/sensorID">
<swe2:quality>
<!-- Optional element can contain any valid static quality element for this sensor -->
</swe2:quality>
<swe2:value>urn:ioos:sensor:wmo:41001:sensor1</swe2:value>
</swe2:Text>
</swe2:field>
<!-- 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="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>
</swe2:DataRecord>
</swe2:field>
<swe2:field name="wmo_41001_sensor2">
<!-- 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_sensor2"
definition="http://mmisw.org/ont/ioos/swe_element_type/sensor">
<swe2:field name="sensorID">
<!-- IoosTech Convention: -->
<!-- The text element containing the sensor id shall be defined -->
<swe2:Text
definition="http://mmisw.org/ont/ioos/definition/sensorID">
<swe2:quality>
<!-- Optional element can contain any valid static quality element for this sensor -->
</swe2:quality>
<swe2:value>urn:ioos:sensor:wmo:41001:sensor2</swe2:value>
</swe2:Text>
</swe2:field>
<swe2:field name="height">
<swe2:Quantity
definition="http://mmisw.org/ont/cf/parameter/height"
100
DRAFT
3/18/2016
axisID="Z" referenceFrame="#wmo_41001_frame">
<swe2:uom code="m"/>
<swe2:value>-2</swe2:value>
</swe2:Quantity>
</swe2:field>
</swe2:DataRecord>
</swe2:field>
</swe2:DataRecord>
</swe2:field>
</swe2:DataRecord>
</swe2:field>
<!-- Station 2 static data -->
<swe2:field name="wmo_41002">
<!-- IoosTech Convention: -->
<!-- The data record containing the static data for a station shall be defined -->
<swe2:DataRecord id="wmo_41002"
definition="http://mmisw.org/ont/ioos/swe_element_type/station">
<swe2:field name="stationID">
<!-- IoosTech Convention: -->
<!-- The text element containing the station id shall be defined -->
<swe2:Text definition="http://mmisw.org/ont/ioos/definition/stationID">
<swe2:value>urn:ioos:station:wmo:41002</swe2:value>
</swe2:Text>
</swe2:field>
<swe2:field name="platformLocation">
<swe2:Vector
definition="http://www.opengis.net/def/property/OGC/0/PlatformLocation"
referenceFrame="http://www.opengis.net/def/crscompound?1=http://www.opengis.net/def/crs/EPSG/0/4326&amp;2=http://www.opengis.net/def/crs/EPSG/0/5829"
localFrame="#wmo_41002_frame">
<swe2:coordinate name="latitude">
<swe2:Quantity
definition="http://mmisw.org/ont/cf/parameter/latitude"
axisID="Lat">
<swe2:uom code="deg"/>
<swe2:value>32.5</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>-78.5</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</swe2:value>
</swe2:Quantity>
</swe2:coordinate>
</swe2:Vector>
</swe2:field>
<swe2:field name="sensors">
<!-- IoosTech Convention: -->
<!-- The data record containing the static data for each sensor shall be defined -->
101
DRAFT
3/18/2016
<swe2:DataRecord
definition="http://mmisw.org/ont/ioos/swe_element_type/sensors">
<swe2:field name="wmo_41002_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_41002_sensor1"
definition="http://mmisw.org/ont/ioos/swe_element_type/sensor">
<swe2:field name="sensorID">
<!-- IoosTech Convention: -->
<!-- The text element containing the sensor id shall be defined -->
<swe2:Text
definition="http://mmisw.org/ont/ioos/definition/sensorID">
<swe2:value>urn:ioos:sensor:wmo:41002:sensor1</swe2:value>
</swe2:Text>
</swe2:field>
<swe2:field name="height">
<swe2:Quantity
definition="http://mmisw.org/ont/cf/parameter/height"
axisID="Z" referenceFrame="#wmo_41002_frame">
<swe2:uom code="m"/>
<swe2:value>3</swe2:value>
</swe2:Quantity>
</swe2:field>
</swe2:DataRecord>
</swe2:field>
<swe2:field name="wmo_41002_sensor2">
<!-- IoosTech Convention: -->
<!-- The data record containing the static data for a sensor shall be defined -->
<swe2:DataRecord id="wmo_41002_sensor2"
definition="http://mmisw.org/ont/ioos/swe_element_type/sensor">
<swe2:field name="sensorID">
<!-- IoosTech Convention: -->
<!-- The text element containing the sensor id shall be defined -->
<swe2:Text
definition="http://mmisw.org/ont/ioos/definition/sensorID">
<swe2:value>urn:ioos:sensor:wmo:41002:sensor2</swe2:value>
</swe2:Text>
</swe2:field>
<swe2:field name="height">
<swe2:Quantity
definition="http://mmisw.org/ont/cf/parameter/height"
axisID="Z" referenceFrame="#wmo_41002_frame">
<swe2:uom code="m"/>
<swe2:value>-5</swe2:value>
</swe2:Quantity>
</swe2:field>
</swe2:DataRecord>
</swe2:field>
</swe2:DataRecord>
</swe2:field>
</swe2:DataRecord>
</swe2:field>
<!-- Station 3 static data -->
<swe2:field name="wmo_41003">
<!-- IoosTech Convention: -->
<!-- The data record containing the static data for a station shall be defined -->
<swe2:DataRecord id="wmo_41003"
102
DRAFT
3/18/2016
definition="http://mmisw.org/ont/ioos/swe_element_type/station">
<swe2:field name="stationID">
<!-- IoosTech Convention: -->
<!-- The text element containing the station id shall be defined -->
<swe2:Text definition="http://mmisw.org/ont/ioos/definition/stationID">
<swe2:value>urn:ioos:station:wmo:41003</swe2:value>
</swe2:Text>
</swe2:field>
<swe2:field name="platformLocation">
<swe2:Vector
definition="http://www.opengis.net/def/property/OGC/0/PlatformLocation"
referenceFrame="http://www.opengis.net/def/crscompound?1=http://www.opengis.net/def/crs/EPSG/0/4326&amp;2=http://www.opengis.net/def/crs/EPSG/0/5829"
localFrame="#wmo_41003_frame">
<swe2:coordinate name="latitude">
<swe2:Quantity
definition="http://mmisw.org/ont/cf/parameter/latitude"
axisID="Lat">
<swe2:uom code="deg"/>
<swe2:value>33.5</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>-79.5</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</swe2:value>
</swe2:Quantity>
</swe2:coordinate>
</swe2:Vector>
</swe2:field>
<swe2:field name="sensors">
<!-- IoosTech Convention: -->
<!-- The data record containing the static data for each sensor shall be defined -->
<swe2:DataRecord
definition="http://mmisw.org/ont/ioos/swe_element_type/sensors">
<swe2:field name="wmo_41003_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_41003_sensor1"
definition="http://mmisw.org/ont/ioos/swe_element_type/sensor">
<swe2:field name="sensorID">
<!-- IoosTech Convention: -->
<!-- The text element containing the sensor id shall be defined -->
<swe2:Text
definition="http://mmisw.org/ont/ioos/definition/sensorID">
<swe2:value>urn:ioos:sensor:wmo:41003:sensor1</swe2:value>
</swe2:Text>
</swe2:field>
<swe2:field name="height">
103
DRAFT
3/18/2016
<swe2:Quantity
definition="http://mmisw.org/ont/cf/parameter/height"
axisID="Z" referenceFrame="#wmo_41003_frame">
<swe2:uom code="m"/>
<swe2:value>3</swe2:value>
</swe2:Quantity>
</swe2:field>
</swe2:DataRecord>
</swe2:field>
</swe2:DataRecord>
</swe2:field>
</swe2:DataRecord>
</swe2:field>
</swe2:DataRecord>
</swe2:field>
<!-- DYNAMIC DATA (SENSOR OBSERVATIONS) -->
<!-- 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="http://mmisw.org/ont/ioos/swe_element_type/sensorObservationCollection">
<!-- Count of records in swe:values -->
<swe2:elementCount>
<swe2:Count>
<swe2:value>13</swe2:value>
</swe2:Count>
</swe2:elementCount>
<!-- 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="http://mmisw.org/ont/ioos/swe_element_type/sensorObservations">
<!-- 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="http://www.opengis.net/def/property/OGC/0/SamplingTime">
<!-- IoosTech Convention: -->
<!-- This is an optional quality element used to express QC data that applies to an -->
<!-- entire record. The definition of the Category element spcifies that it applies -->
<!-- to the entire record, not to the time element. -->
<swe2:quality>
<swe2:Category
definition="http://mmisw.org/ont/ioos/swe_element_type/recordQuality">
<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>
104
DRAFT
3/18/2016
<swe2:uom
xlink:href="http://www.opengis.net/def/uom/ISO-8601/0/Gregorian"/>
</swe2:Time>
</swe2:field>
<!-- 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="http://mmisw.org/ont/ioos/swe_element_type/sensors">
<!-- 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="http://mmisw.org/ont/ioos/swe_element_type/sensor">
<!-- wmo_41001_sensor1's observed properties -->
<swe2:field name="air_temperature">
<swe2:Quantity
definition="http://mmisw.org/ont/cf/parameter/air_temperature">
<!-- The next 3 elements specify the quality of the Air Temperature field -->
<!-- using ndbc qc flags as an example. -->
<swe2:quality>
<!-- NDBC EQC Quality -->
<!-- Data Descriptor only - value must be block encoded -->
<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"/>
<!-- This is not a formal code space. Use it till something better is created.-->
<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>
<!-- NDBC DQA Quality -->
<!-- Unfortuantly there is no way to specify an array quality elements inside the -->
<!-- quantity. To allow for upto 2 values, two quality fields must be defined. -->
<swe2:Category
definition="http://sdftest.ndbc.noaa.gov/sos/qcflags.shtml">
<swe2:label>DQA Flag 1</swe2:label>
<swe2:codeSpace
105
DRAFT
3/18/2016
xlink:href="http://sdftest.ndbc.noaa.gov/sos/qcflags.shtml"/>
<!-- This is not a formal code space. Use it till something better is created.-->
<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>
<!-- Second DQA element -->
<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"/>
<!-- This is not a formal code space. Use it till something better is created.-->
<swe2:constraint xlink:href="#ndbcDqaFlags"/>
<!-- The second DQA element can reference the constraints defined in the first -->
</swe2:Category>
</swe2:quality>
<!-- End quality elements -->
<swe2:uom code="Celsius"/>
</swe2:Quantity>
</swe2:field>
<swe2:field name="wind_speed">
<swe2:Quantity
definition="http://mmisw.org/ont/cf/parameter/wind_speed">
<!-- Each field and quantity can reference the constraints defined above to -->
<!-- define quality elements. -->
<swe2:quality>
<swe2:Category>
<swe2:label> DQA Flag 1</swe2:label>
<!-- Example of constraint by reference -->
<swe2:constraint xlink:href="#ndbcDqaFlags"/>
</swe2:Category>
</swe2:quality>
<swe2:nilValues>
<swe2:NilValues>
106
DRAFT
3/18/2016
<swe2:nilValue
reason="http://www.opengis.net/def/nil/OGC/0/BelowDetectionRange"
> INF </swe2:nilValue>
<!-- nilValue for a quntity may be one of INF, -INF, NaN or any value (such as 5.28) -->
<!-- See SWE Common Data Moel OGC 08-094r1 section 8.1.14 NilValues Element for details -->
<!-- Use a defined reason where possible -->
</swe2:NilValues>
</swe2:nilValues>
<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/swe_element_type/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/swe_element_type/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/swe_element_type/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>
107
DRAFT
3/18/2016
</swe2:DataRecord>
</swe2:item>
<swe2:item name="wmo_41003_sensor1">
<swe2:DataRecord
definition="http://mmisw.org/ont/ioos/swe_element_type/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>
</swe2:DataRecord>
</swe2:elementType>
<swe2:encoding>
<!-- 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. -->
<swe2:TextEncoding decimalSeparator="." tokenSeparator="," blockSeparator="&#10;"/>
</swe2:encoding>
<swe2:values>
<!-- The first three records are from wmo_41001_sensor1 and contain quality values -->
2009-05-23T00:00:00Z,a,wmo_41001_sensor1,15.4,T,a,r,2.0,m,280
2009-05-23T01:00:00Z,b,wmo_41001_sensor1,15.8,M,j,j,1.8,m,121
2009-05-23T02:00:00Z,c,wmo_41001_sensor1,15.6,M,,,1.0,m,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>
</swe2:field>
108
DRAFT
3/18/2016
</swe2:DataRecord>
5.1.4 TimeSeriesProfile records for a single station
<!-- This template is an example of a SWE Data Record composed of static and dynamic fields for -->
<!-- multiple stations with multiple profiling sensors -->
<!-- -->
<!-- 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 2 sensors -->
<swe2:DataRecord
xmlns:swe2="http://www.opengis.net/swe/2.0"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.opengis.net/swe/2.0 http://schemas.opengis.net/sweCommon/2.0/swe.xsd"
definition="http://mmisw.org/ont/ioos/swe_element_type/observationRecord">
<!-- 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="http://mmisw.org/ont/ioos/swe_element_type/stations">
<!-- 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"
definition="http://mmisw.org/ont/ioos/swe_element_type/station">
<swe2:field name="stationID">
<!-- IoosTech Convention: -->
<!-- The text element containing the station id shall be defined -->
<swe2:Text definition="http://mmisw.org/ont/ioos/definition/stationID">
<swe2:value>urn:ioos:station:wmo:41001</swe2:value>
</swe2:Text>
</swe2:field>
<!-- 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 -->
109
DRAFT
3/18/2016
<!-- 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="http://www.opengis.net/def/property/OGC/0/PlatformLocation"
referenceFrame="http://www.opengis.net/def/crscompound?1=http://www.opengis.net/def/crs/EPSG/0/4326&amp;2=http://www.opengis.net/def/crs/EPSG/0/5829"
localFrame="#wmo_41001_frame">
<!-- 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="http://www.opengis.net/def/crs/EPSG/0/4979" -->
<!-- -->
<!-- Each stations localFrame must be unique. -->
<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>
<!-- 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 -->
</swe2:Quantity>
</swe2:coordinate>
</swe2:Vector>
</swe2:field>
<!-- 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="http://mmisw.org/ont/ioos/swe_element_type/sensors">
<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"
definition="http://mmisw.org/ont/ioos/swe_element_type/sensor">
<!-- An example of an acoustic doppler current profiler -->
<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. -->
110
DRAFT
3/18/2016
<!-- IoosTech Convention: -->
<!-- The text element containing the sensor id shall be defined -->
<swe2:Text definition="http://mmisw.org/ont/ioos/definition/sensorID">
<swe2:value>urn:ioos:sensor:wmo:41001:sensor1</swe2:value>
</swe2:Text>
</swe2:field>
<swe2:field name="sensorOrientation">
<!-- If available for an profiling sensor such as an ADCP, record the sensor -->
<!-- orientation as part of the static (or dyanmic) data. -->
<!-- Orientation could be for the profile or for each observation in the profile. -->
<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>
<swe2:field name="sensorLocation">
<!-- For a profiling sensor such as an ADCP it is best to specify its location relative -->
<!-- to a CRS rather than relative to the platform or buoy unless this relationship is -->
<!-- actually measured. It is likely that the relative measured location would be dynamic -->
<!-- changing with each observation. Where as an absolute lat,lon,Z may be -->
<!-- approximated as static. -->
<!-- Local frames should always be specified as #{short_asset_id}_frame, regardless of feature type -->
<swe2:Vector definition="http://www.opengis.net/def/property/OGC/0/SensorLocation"
referenceFrame="http://www.opengis.net/def/crscompound?1=http://www.opengis.net/def/crs/EPSG/0/4326&amp;2=http://www.opengis.net/def/crs/EPSG/0/5829"
localFrame="#wmo_41001_sensor1_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>
111
DRAFT
3/18/2016
</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>
<swe2:field name="profileBins">
<!-- IoosTech Convention: -->
<!-- Static profile bins and depths shall be encoded as an defined array -->
<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>
<!-- The number of bins defined should be greater than or equal to the -->
<!-- number of binned observations in the dynamic data for this sensor. -->
<!-- This would allow for ragged arrays of data from upward looking adcps. -->
</swe2:Count>
</swe2:elementCount>
<swe2:elementType name="profileBinDescription">
<swe2:DataRecord>
<swe2:field name="binCenter">
<!-- IoosTech Convention: -->
<!-- binCenters shall be represented by a defined quantity -->
<!-- NOTE: sufficient to use height definition for bin center, since it's in a -->
<!-profile_bin? Would be more consistent with normal profiles -->
<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">
<!-- IoosTech Convention: -->
<!-- binEdges shall be represented by a defined quantity -->
<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>
112
DRAFT
3/18/2016
</swe2:DataArray>
</swe2:field>
</swe2:DataRecord>
</swe2:field>
<!-- An example of a thermister chain -->
<swe2:field name="wmo_41001_sensor2">
<!-- 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_sensor2"
definition="http://mmisw.org/ont/ioos/swe_element_type/sensor">
<swe2:field name="sensorID">
<!-- IoosTech Convention: -->
<!-- The text element containing the sensor id shall be defined -->
<swe2:Text definition="http://mmisw.org/ont/ioos/definition/sensorID">
<swe2:value>urn:ioos:sensor:wmo:41001:sensor2</swe2:value>
</swe2:Text>
</swe2:field>
<swe2:field name="sensorLocation">
<!-- For a profiling sensor such as an thermister chain it is best to specify its location relative -->
<!-- to a CRS rather than relative to the platform or buoy unless this relationship is -->
<!-- actually measured. It is likely that the relative measured location would be dynamic -->
<!-- changing with each observation. Where as an absolute lat,lon,Z may be -->
<!-- approximated as static. -->
<!-- Local frames should always be specified as #{short_asset_id}_frame, regardless of feature type -->
<swe2:Vector definition="http://www.opengis.net/def/property/OGC/0/SensorLocation"
referenceFrame="http://www.opengis.net/def/crscompound?1=http://www.opengis.net/def/crs/EPSG/0/4326&amp;2=http://www.opengis.net/def/crs/EPSG/0/5829"
localFrame="#wmo_41001_sensor2_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>
<swe2:field name="profileHeights">
<!-- IoosTech Convention: -->
<!-- Static profile bins and heights shall be encoded as an defined array -->
<swe2:DataArray
113
DRAFT
3/18/2016
definition="http://mmisw.org/ont/ioos/swe_element_type/profileHeights">
<swe2:elementCount>
<swe2:Count>
<swe2:value>3</swe2:value>
<!-- The number of bins defined should be greater than or equal to the -->
<!-- number of binned observations in the dynamic data for this sensor. -->
</swe2:Count>
</swe2:elementCount>
<swe2:elementType name="profileDefinition">
<swe2:DataRecord>
<swe2:field name="height">
<!-- IoosTech Convention: -->
<!-- Profile depth shall be represented by a defined quantity -->
<swe2:Quantity axisID="Z"
definition="http://mmisw.org/ont/cf/parameter/height"
referenceFrame="#wmo_41001_sensor2_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>
</swe2:DataRecord>
</swe2:field>
</swe2:DataRecord>
</swe2:field>
</swe2:DataRecord>
</swe2:field>
</swe2:DataRecord>
</swe2:field>
<!-- DYNAMIC DATA (SENSOR OBSERVATIONS) -->
<!-- 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="http://mmisw.org/ont/ioos/swe_element_type/sensorObservationCollection">
<!-- Count of records in swe:values -->
<swe2:elementCount>
<swe2:Count>
<swe2:value>6</swe2:value>
</swe2:Count>
</swe2:elementCount>
<!-- 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 -->
114
DRAFT
3/18/2016
<swe2:DataRecord definition="http://mmisw.org/ont/ioos/swe_element_type/sensorObservations">
<!-- Time is included for all sensors 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="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>
<!-- 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="http://mmisw.org/ont/ioos/swe_element_type/sensors">
<!-- 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="http://mmisw.org/ont/ioos/swe_element_type/sensor">
<swe2:field name="adcpProfile">
<swe2:DataArray definition="http://mmisw.org/ont/ioos/swe_element_type/profile">
<swe2:description>Array of synchronous observations in a Profile</swe2:description>
<swe2:elementCount>
<!-- IoosTech Convention: -->
<!-- Count value is always omitted here and included inline with the encoded -->
<!-- data array to allow ragged inner array for trajectories and adcps. -->
<swe2:Count />
</swe2:elementCount>
<swe2:elementType name="profileObservation">
<swe2:DataRecord definition="http://mmisw.org/ont/ioos/swe_element_type/profileObservation">
<swe2:field name="profileIndex">
<!-- IoosTech Convention: -->
<!-- A count element, constrained by the maximum dimension of the array -->
<!-- shall specify which zero-based bin index the data applies to, -->
<!-- allowing ragged arrays -->
<!-- NOTE: http://www.opengis.net/def/property/OGC/0/ArrayIndex is mentioned -->
<!-in the SWE 2.0 spec but doesn't resolve... -->
<swe2:Count definition="http://mmisw.org/ont/ioos/swe_element_type/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">
115
DRAFT
3/18/2016
<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 definition="http://mmisw.org/ont/ioos/swe_element_type/sensor">
<swe2:field name="thermisterProfile">
<swe2:DataArray definition="http://mmisw.org/ont/ioos/swe_element_type/profile">
<swe2:elementCount>
<!-- IoosTech Convention: -->
<!-- Count value is always omitted here and included inline with the encoded -->
<!-- data array to allow ragged inner array for trajectories and adcps -->
<swe2:Count />
</swe2:elementCount>
<swe2:elementType name="profileObservation">
<swe2:DataRecord definition="http://mmisw.org/ont/ioos/swe_element_type/profileObservation">
<swe2:field name="binIndex">
<!-- IoosTech Convention: -->
<!-- A count element, constrained by the maximum dimension of the array -->
<!-- shall specify which zero-based bin index the data applies to, -->
<!-- allowing ragged arrays -->
<swe2:Count definition="http://mmisw.org/ont/ioos/swe_element_type/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>
</swe2:field>
</swe2:DataRecord>
</swe2:elementType>
<swe2:encoding>
<!-- 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 -->
116
DRAFT
3/18/2016
<!-- 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. -->
<swe2:TextEncoding
decimalSeparator="."
tokenSeparator=","
blockSeparator="&#10;" />
</swe2:encoding>
<swe2:values>
2009-05-23T00:00:00Z,wmo_41001_sensor1,2,0,359.0,10.0,3,352.0,9.6
2009-05-23T01:00:00Z,wmo_41001_sensor1,1,2,345.0,10.4
2009-05-23T02:00:00Z,wmo_41001_sensor1,4,0,332.0,10.5,1,334.0,10.3,2,336.0,10.1,3,335.0,9.9
2009-05-23T00:00:00Z,wmo_41001_sensor2,3,0,13.7,1,16.8,2,19.2
2009-05-23T01:00:00Z,wmo_41001_sensor2,3,0,13.5,1,16.4,2,19.3
2009-05-23T02:00:00Z,wmo_41001_sensor2,3,0,13.4,1,16.5,2,18.8
</swe2:values>
</swe2:DataArray>
</swe2:field>
</swe2:DataRecord>
5.1.5 TimeSeriesProfile records for multiple station with multiple sensors including
quality elements for some quantities
<!-- This template is an example of a SWE Data Record composed of static and dynamic fields for -->
<!-- multiple stations with multiple profiling sensors -->
<!-- -->
<!-- This template is almost identical to the SWE-SingleSation-TimeSeriesProfile with the addition of some -->
<!-- quality elements. Quality flags for static and dynamic data are included for station1 sensor 1.-->
<!-- The example quality elements in this document are simple, showing where to put them. For more -->
<!-- complete examples of quality elements, see SWE-MultiStation-TimeSeries_QC.xml. -->
<!-- -->
<!-- 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. -->
<!-- -->
<!-- TODO: Finalize some vocabulary issues. See
http://wiki.esipfed.org/index.php/Proposing_Standard_Names_for_data_from_Current_Meters_and_Profilers for some helpful
information. -->
<!-- Description of data -->
<!-- SWE DataRecord containing 1 Station: -->
<!-- Station 1 has 2 sensors -->
<swe2:DataRecord
xmlns:swe2="http://www.opengis.net/swe/2.0"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
117
DRAFT
3/18/2016
xsi:schemaLocation="http://www.opengis.net/swe/2.0 http://schemas.opengis.net/sweCommon/2.0/swe.xsd"
definition="http://mmisw.org/ont/ioos/swe_element_type/observationRecord">
<!-- 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="http://mmisw.org/ont/ioos/swe_element_type/stations">
<!-- 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"
definition="http://mmisw.org/ont/ioos/swe_element_type/station">
<swe2:field name="stationID">
<!-- IoosTech Convention: -->
<!-- The text element containing the station id shall be defined -->
<swe2:Text definition="http://mmisw.org/ont/ioos/definition/stationID">
<swe2:quality>
<!-- 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>
<!-- 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="http://www.opengis.net/def/property/OGC/0/PlatformLocation"
referenceFrame="http://www.opengis.net/def/crscompound?1=http://www.opengis.net/def/crs/EPSG/0/4326&amp;2=http://www.opengis.net/def/crs/EPSG/0/5829"
localFrame="#wmo_41001_frame">
<!-- 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="http://www.opengis.net/def/crs/EPSG/0/4979" -->
<!-- -->
<!-- Each stations localFrame must be unique. -->
118
DRAFT
3/18/2016
<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>
<!-- 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 -->
</swe2:Quantity>
</swe2:coordinate>
</swe2:Vector>
</swe2:field>
<!-- 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="http://mmisw.org/ont/ioos/swe_element_type/sensors">
<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"
definition="http://mmisw.org/ont/ioos/swe_element_type/sensor">
<!-- An example of an acoustic doppler current profiler -->
<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="http://mmisw.org/ont/ioos/definition/sensorID">
<swe2:quality>
<!-- Static quality information about this sensor can be placed here -->
</swe2:quality>
<swe2:value>urn:ioos:sensor:wmo:41001:sensor1</swe2:value>
</swe2:Text>
</swe2:field>
<swe2:field name="sensorOrientation">
<!-- If available for an profiling sensor such as an ADCP, record the sensor -->
<!-- orientation as part of the static (or dyanmic) data. -->
<!-- Orientation could be for the profile or for each observation in the profile. -->
<swe2:Vector definition="http://www.opengis.net/def/property/OGC/0/SensorOrientation"
119
DRAFT
3/18/2016
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>
<swe2:field name="sensorLocation">
<!-- For a profiling sensor such as an ADCP it is best to specify its location relative -->
<!-- to a CRS rather than relative to the platform or buoy unless this relationship is -->
<!-- actually measured. It is likely that the relative measured location would be dynamic -->
<!-- changing with each observation. Where as an absolute lat,lon,Z may be -->
<!-- approximated as static. -->
<!-- Local frames should always be specified as #{short_asset_id}_frame, regardless of feature type. -->
<swe2:Vector definition="http://www.opengis.net/def/property/OGC/0/SensorLocation"
referenceFrame="http://www.opengis.net/def/crscompound?1=http://www.opengis.net/def/crs/EPSG/0/4326&amp;2=http://www.opengis.net/def/crs/EPSG/0/5829"
localFrame="#wmo_41001_sensor1_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>
<swe2:field name="profileBins">
120
DRAFT
3/18/2016
<!-- IoosTech Convention: -->
<!-- Static profile bins and depths shall be encoded as an defined array -->
<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>
<!-- The number of bins defined should be greater than or equal to the -->
<!-- number of binned observations in the dynamic data for this sensor. -->
<!-- This would allow for ragged arrays of data from upward looking adcps. -->
</swe2:Count>
</swe2:elementCount>
<swe2:elementType name="profileBinDescription">
<swe2:DataRecord>
<swe2:field name="binCenter">
<!-- IoosTech Convention: -->
<!-- binCenters shall be represented by a defined quantity -->
<!-- NOTE: sufficient to use height definition for bin center, since it's in a -->
<!-profile_bin? Would be more consistent with normal profiles -->
<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">
<!-- IoosTech Convention: -->
<!-- binEdges shall be represented by a defined quantity -->
<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>
</swe2:DataRecord>
</swe2:field>
<!-- An example of a thermister chain -->
<swe2:field name="wmo_41001_sensor2">
<!-- 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 -->
121
DRAFT
3/18/2016
<!-- name in the dynamic block -->
<swe2:DataRecord id="wmo_41001_sensor2"
definition="http://mmisw.org/ont/ioos/swe_element_type/sensor">
<swe2:field name="sensorID">
<!-- IoosTech Convention: -->
<!-- The text element containing the sensor id shall be defined -->
<swe2:Text definition="http://mmisw.org/ont/ioos/definition/sensorID">
<swe2:quality>
<!-- Static quality information about this sensor may be place here -->
</swe2:quality>
<swe2:value>urn:ioos:sensor:wmo:41001:sensor2</swe2:value>
</swe2:Text>
</swe2:field>
<swe2:field name="sensorLocation">
<!-- For a profiling sensor such as an thermister chain it is best to specify its location relative -->
<!-- to a CRS rather than relative to the platform or buoy unless this relationship is -->
<!-- actually measured. It is likely that the relative measured location would be dynamic -->
<!-- changing with each observation. Where as an absolute lat,lon,Z may be -->
<!-- approximated as static. -->
<!-- Local frames should always be specified as #{short_asset_id}_frame, regardless of feature type. -->
<swe2:Vector definition="http://www.opengis.net/def/property/OGC/0/SensorLocation"
referenceFrame="http://www.opengis.net/def/crscompound?1=http://www.opengis.net/def/crs/EPSG/0/4326&amp;2=http://www.opengis.net/def/crs/EPSG/0/5829"
localFrame="#wmo_41001_sensor2_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>
<swe2:field name="profileHeights">
<!-- IoosTech Convention: -->
<!-- Static profile bins and heights shall be encoded as an defined array -->
<swe2:DataArray
definition="http://mmisw.org/ont/ioos/swe_element_type/profileHeights">
<swe2:elementCount>
<swe2:Count>
<swe2:value>3</swe2:value>
<!-- The number of bins defined should be greater than or equal to the -->
<!-- number of binned observations in the dynamic data for this sensor. -->
122
DRAFT
3/18/2016
</swe2:Count>
</swe2:elementCount>
<swe2:elementType
name="profileDefinition">
<swe2:DataRecord>
<swe2:field name="height">
<!-- IoosTech Convention: -->
<!-- Profile depth shall be represented by a defined quantity -->
<swe2:Quantity axisID="Z"
definition="http://mmisw.org/ont/cf/parameter/height"
referenceFrame="#wmo_41001_sensor2_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>
</swe2:DataRecord>
</swe2:field>
</swe2:DataRecord>
</swe2:field>
</swe2:DataRecord>
</swe2:field>
</swe2:DataRecord>
</swe2:field>
<!-- DYNAMIC DATA (SENSOR OBSERVATIONS) -->
<!-- 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="http://mmisw.org/ont/ioos/swe_element_type/sensorObservationCollection">
<!-- Count of records in swe:values -->
<swe2:elementCount>
<swe2:Count>
<swe2:value>6</swe2:value>
</swe2:Count>
</swe2:elementCount>
<!-- 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="http://mmisw.org/ont/ioos/swe_element_type/sensorObservations">
<!-- Time is included for all sensors 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">
123
DRAFT
3/18/2016
<swe2:Time definition="http://www.opengis.net/def/property/OGC/0/SamplingTime">
<!-- IoosTech Convention: -->
<!-- This is an optional quality element used to express QC data that applies to an -->
<!-- entire record. The definition of the Category element spcifies that it applies -->
<!-- to the entire record, not to the time element. -->
<swe2:quality>
<swe2:Category definition="http://mmisw.org/ont/ioos/swe_element_type/recordQuality">
<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:uom xlink:href="http://www.opengis.net/def/uom/ISO-8601/0/Gregorian" />
</swe2:Time>
</swe2:field>
<!-- 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="http://mmisw.org/ont/ioos/swe_element_type/sensors">
<!-- 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="http://mmisw.org/ont/ioos/swe_element_type/sensor">
<swe2:field name="adcpProfile">
<swe2:DataArray definition="http://mmisw.org/ont/ioos/swe_element_type/profile">
<swe2:elementCount>
<!-- IoosTech Convention: -->
<!-- Count value is always omitted here and included inline with the encoded -->
<!-- data array to allow ragged inner array for trajectories and adcps. -->
<swe2:Count />
</swe2:elementCount>
<swe2:elementType name="profileObservation">
<swe2:DataRecord
definition="http://mmisw.org/ont/ioos/swe_element_type/profileObservation">
<swe2:field name="profileIndex">
<!-- IoosTech Convention: -->
<!-- A count element, constrained by the maximum dimension of the array -->
<!-- shall specify which zero-based bin index the data applies to, -->
<!-- allowing ragged arrays -->
<!-- NOTE: http://www.opengis.net/def/property/OGC/0/ArrayIndex is mentioned -->
<!-in the SWE 2.0 spec but doesn't resolve... -->
<swe2:Count
definition="http://mmisw.org/ont/ioos/swe_element_type/profileIndex">
<swe2:quality>
124
DRAFT
3/18/2016
<!-- Quality flags which apply to all data in a bin go here -->
<swe2:Category>
<swe2:constraint>
<swe2:AllowedTokens>
<swe2:value>1</swe2:value>
<swe2:value>2</swe2:value>
<swe2:value>3</swe2:value>
</swe2:AllowedTokens>
</swe2:constraint>
</swe2:Category>
</swe2:quality>
<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:quality>
<!-- Quality flags which apply to a single field in a bin go here -->
<swe2:Category>
<swe2:constraint>
<swe2:AllowedTokens>
<swe2:value>x</swe2:value>
<swe2:value>y</swe2:value>
<swe2:value>z</swe2:value>
</swe2:AllowedTokens>
</swe2:constraint>
</swe2:Category>
</swe2:quality>
<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 definition="http://mmisw.org/ont/ioos/swe_element_type/sensor">
<swe2:field name="thermisterProfile">
<swe2:DataArray definition="http://mmisw.org/ont/ioos/swe_element_type/profile">
<swe2:elementCount>
<!-- IoosTech Convention: -->
<!-- Count value is always omitted here and included inline with the encoded -->
<!-- data array to allow ragged inner array for trajectories and adcps -->
125
DRAFT
3/18/2016
<swe2:Count />
</swe2:elementCount>
<swe2:elementType name="profileObservation">
<swe2:DataRecord
definition="http://mmisw.org/ont/ioos/swe_element_type/profileObservation">
<swe2:field name="binIndex">
<!-- IoosTech Convention: -->
<!-- A count element, constrained by the maximum dimension of the array -->
<!-- shall specify which zero-based bin index the data applies to, -->
<!-- allowing ragged arrays -->
<swe2:Count
definition="http://mmisw.org/ont/ioos/swe_element_type/profileIndex">
<!-- Quality flags for each bin go here -->
<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:quality>
<!-- Quality flags for an individual field go in a bin go here -->
</swe2:quality>
<swe2:uom code="Cel" />
</swe2:Quantity>
</swe2:field>
</swe2:DataRecord>
</swe2:elementType>
</swe2:DataArray>
</swe2:field>
</swe2:DataRecord>
</swe2:item>
</swe2:DataChoice>
</swe2:field>
</swe2:DataRecord>
</swe2:elementType>
<swe2:encoding>
<!-- 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. -->
126
DRAFT
3/18/2016
<!-- -->
<!-- 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. -->
<swe2:TextEncoding
decimalSeparator="."
tokenSeparator=","
blockSeparator="&#10;" />
</swe2:encoding>
<swe2:values>
2009-05-23T00:00:00Z,a,wmo_41001_sensor1,2,0,1,359.0,x,10.0,3,2,352.0,y,9.6
2009-05-23T01:00:00Z,a,wmo_41001_sensor1,1,2,2,345.0,y,10.4
2009-0523T02:00:00Z,b,wmo_41001_sensor1,4,0,3,332.0,z,10.5,1,2,334.0,x,10.3,2,3,336.0,z,10.1,3,1,335.0,x,9.9,4,2,333.0,y,9.6
2009-05-23T00:00:00Z,b,wmo_41001_sensor2,3,0,13.7,1,16.8,2,19.2
2009-05-23T01:00:00Z,c,wmo_41001_sensor2,3,0,13.5,1,16.4,2,19.3
2009-05-23T02:00:00Z,a,wmo_41001_sensor2,3,0,13.4,1,16.5,2,18.8
</swe2:values>
</swe2:DataArray>
</swe2:field>
</swe2:DataRecord>
127
DRAFT
3/18/2016
128