OOSDB with PostgreSQL at CMOP

Bill Howe, Ph.D.

Affiliations

Senior Research AssociateOne of 16 “Science and Technology Centers” funded by the National Science Foundationbased at OGI @ OHSU

DMAC CoordinatorNorthwest Association of Networked Ocean Observing Systems (NANOOS)

Oregon Graduate Institute merged with OHSU in 2001 to form “The OGI School of Science & Engineering at Oregon Health & Science University”

Liaison with CMOP PIsin Computer Science

Goals

Build an integrated repository for observations and, increasingly, model results

Remain source agnostic fixed moorings, UUVs, (quantitative) biological samples external websites, model results,

Leverage PostgreSQL’s sophisticated features

Incremental improvement Testing of pre-release underway

Notes

Vectors supported uniformly with scalars with Postgres arrays

Hierarchy of spatial and temporal containment stationary platforms vs., e.g., UUVs

Nested “Missions” Vessel cruise is a mission CTD casts from the vessel are also missions

“Virtual Observations” Model extractions captured uniformly with measurements

Quality control on a per-value basis not yet deployed

OOSDB: Schema (1/2)

value

mission v(20)

configuration v(20)

location point

depth float

time time

value [float]

deployment

mission v(20)

configuration v(20)

mission

mission v(20)

parent

platform v(20)

location geo

timerange range

configuration

configuration v(20)

instrument v(20)

instrumenttype v(20)

entity v(20)

variable v(20)

units v(20)

sample rate float

depth ref. text

etc.

platform

platform v(20)

type v(20)

agency geo

location geo

timerange range

activeflag bool

units

instrument

capability

“X11 is a UUV”;“red26 is a

fixed station”

“red26 was active from 1/1/2005 to 12/31/2005”

“The CTD with serial number 1234 was

deployed for red26’s 2005 mission with this specific configuration”

“The CTD with serial number 1234 can be configured

to report temperature

measurements in degrees celsius, at

a given sample rate, etc.”

“On 1/1/2005 at 13:01, this deployment

reported the temperature to be ‘19’”

qc_value qc_assessment

OOSDB: Schema (2/2)entity

entity v(20)

urn text

uri text

variable

variable v(20)

standardname text

urn text

uri text

characteristic

entity text

variable text

capability

instrumenttype v(20)

entity v(20)

variable v(20)

units

variable v(20)

units v(20)

standardname text

urn text

uri text

configuration

configuration v(20)

instrument v(20)

instrumenttype v(20)

entity v(20)

variable v(20)

units v(20)

sample rate float

depth ref. text

etc.

instrument

instrument v(20)

instrumentype v(20)

serialnumber text

vendor text

uri text

instrumenttype

instrumenttype v(20)

description text“Ocean”; “Atmosphere”

“CTD”; “ADP”

“A CTD is capable of measuring salinity,

conduct., temperature, pressure, depth”

“A specific CTD with serial number

1234 exists”

“The temperature of the ocean can

be measured”

“Temperature is a quantity that can

be measured”

“Temperature can be measured in

degrees Celsius”

“The CTD with serial number 1234 can be configured

to report temperature

measurements in degrees celsius, at

a given sample rate, etc.”

Other Features: Unit Conversions

linearconversion

fromvariable text

fromunit text

tovariable text

tounit text

a float

b float

units

variable text

units time

standardname float

T = a*F + b

SELECT v.time, to.a*v.value + to.b as value FROM configuration d, linearconversion c, value v WHERE d.datasetid = v.datasetid AND d.variable = c.fromvariable AND d.units = c.units AND c.tovariable = ‘temp’ AND c.tounits = ‘C’

value

configuration int

location geo

depth float

time time

value [float]

configuration

configuration v(20)

variable v(20)

units v(20)

Other Features: Containment in SpaceTime Platform may have a fixed location

If not, the mission may be to a fixed location

If not, the deployment may be at a fixed location

If not, each measurement may be at a different location

e.g., permanent moorings

e.g., ORCA

e.g., Casts

e.g., UUVs

Parent location contains its children’s locations if not null.

Defaults cascade upwards

PostgreSQL provides an elegant solution: Rules on Insert

Example: Fixed Stations Platform

One per station, e.g., ‘red26’ Mission

One begins at each visit Stores a spacetime ‘Envelope’; a single

point in this case. Configuration

One per (instrument, variable) Can be reused on multiple missions

Deployment assignment of a configuration to a mission

Value measurements redundantly store the

location information

add another picture

Example: Vessel Platform

The forerunner itself, maybe the cast devices are

separate Mission

One for each cruise Envelope is the cruise plan as a

PostGIS linestring Configuration / Deployment

Sample rate, cast protocol, etc. Value

Time/Location changes with each measurement

Example: Oceanic Remote Chemical-optical Analyzer Platform

The ORCA mooring itself Mission

One for each of 3 long-term deployments

Envelope is a single point Configuration / Deployment

Sample rate, cast protocol, etc. Value

Location: local drift is ignored Time: estimated from sample rate

and profile time Depth: estimated from pressure and

latitude with a postgres UDF

         

    

         

    

image source: ORCA (http://www.ocean.washington.edu/research/orca/)

Example: Umanned Underwater Vehicles Platform

The vehicle Mission

Each excursion is a mission Envelope is a linestring

Configuration / Deployment Frequent changes

Value Location, depth, and time all

vary

image source: MBARI (http://www.mbari.org/auv/)

Example: External Data

Platform Each site or service

Mission Fine-grained: each request Coarse-grained: each feed

Instrument Program used for retrieval

Configuration / Deployment Command-line arguments

Value Location, depth, and time may vary

Example: Model Extractions

Platform Each model: ELCIRC, SELFE

Mission A sequence of related runs e.g, “Tilamook forecast”

Instrument “Virtual Instruments”

Configuration / Deployment Command-line arguments

Value Location, depth, and time may

vary

Interfaces to OOSDB

Integrated Schema

Modeling

Stations

Cruises

External

Ingest via

Postgres Rules

OpenDAP

Legacy and application-specific

RDBMS

Egress via Views

SOSSOS

SOS

Standards and external applications

Apps need not understand database

organization

“Logical Data Independence”

Enables agile development of

the schema