Data Transport

1
Data Transport
2

• Were talking specifically and only about 'late'
  data transport.

3
Data Transport

• Data Transport is a service layer which should
• Be minimally invasive to the Certified Data
  Providers IT shop.
• Support basic parameter specific geospatial (bbox
  or sensor) and temporal queries and result
  thresholds ( gt or lt or )
• Be flexible as the output data model will likely
  change as the system matures.
• Support data response including optional grouping
  by collection event (e.g. profile, glider, etc.)
• Present limited risk due to cost of
  implementation and maintenance.

4
Data Transport Laboratory

• Purpose to strengthen the transport
  implementation practices among IOOS partners via
  a development and testing facility that is
  persistent and objective.
• Considers pre-existing efforts/projects/technologi
  es.
• Is not necessarily intended to develop final
  solutions, but to consider/critique possible
  solutions.
• Is intended to produce information that supports
  decision making.
• Employs a project selection process, testing with
  external partners, full report of results and
  critiques.

5
DTL projects

• DTL Proj1 OPenDAP (v3) NetCDF/CF for In-situ
  Data
• This project found utility in the OPeNDAP
  NetCDF stack but concluded that it is intrusive
  to the data provider's IT shop.
• The report recommends use of RDBMS with more
  loosely coupled service layer.

6
DTL projects

• DTL Proj3 - Exploration of OOSTethys (SOS and
  OM) Testing is currently underway.
• DTL Proj4 - Use of WFSGML/SFP for Time Series
  Data Testing is currently underway.
• Demonstrates GML/SFP via WFS as a valid mechanism
  for transport of in-situ data.
• DTL plans - Further development of microWFS
  service and client to be fully compliant.
• Continued development of content standards and
  schemata.
• Continued development of microWFS service to be
  fully compliant. OGC WFS specifies 3 mandatory
  methods getFeature, getCapabilities, and
  describeFeature. Currently, microWFS only
  supports getFeature.
• Survey of interest in continued development in
  Java, Perl, Python, or other.

7
Why OGC WFS?

• WFS is a stable OGC standard and is in committee
  with ISO.
• GML/Simple Feature Profile offers a rich library
  of XML elements.
• Incorporates the use of content standards,
  dictionaries, and schemata.
• DTL Project4 Example of GML/SFP via WFS
• Was intended to determine the feasibility of
  handling time series data in GML/SFP via a WFS.
• Produced a valid simple architecture that
  produces GML/SFP output without a map server
  greatly simplifying the required server stack.

Client
RDBMS
Servlet or CGI Application

• Demo microWFS
• http//csc-s-ial-p.csc.noaa.gov/DTL/DTLProjects/m
  icrowfs/

8
Why OGC WFS?

• Given a content standard and a set of schemas,
  supporting the required service methods is
  straight forward.
• Facilitates simple implementation while allowing
  for substantial extension/expansion or the
  service definition and transport schemata.
• WFS is supported by popular map server packages
• WFS output can be generated without a map server
  reducing complexity if all you want is GML/SFP
  WFS.
• Helps move from DMAC pre-operational toward
  operational.
• Consistent with IOOS PO DIF development efforts.

9
Suggestions

• Suggestion Use GML/SFP via WFS services to
  transport discrete in-situ data.
• Suggestion Use OGC WCS or OPenDAP for grids
  (model output or remotely sensed data).
• Suggestion Set a minimum 30 day sliding window
  for data availability.
• Suggestion Set a maximum period for getting data
  from sensor to service.