Skip to end of metadata
Go to start of metadata

Time Series Scalar Data

Time-series data files for sensors collecting one-dimensional data are described here (i.e., every time-stamped data record refers to a value at a single point in space). This definition may include instruments on mobile platforms such as Wally (a crawler in Barkley Canyon) or the Vertical Profiling System (VPS), for more information see the mobile device page. However, gridded data from instruments like multibeam sonar and echosounders are excluded. For data searches defined by location and data source, (e.g. CTD at Folger Deep), new files will not be made if the device contributing the data is modified, (i.e. if the CTD is swapped for another). For data searches defined by instrument type, (e.g. CTD 10600), if the device is moved (e.g. from MTC to Folger Deep), new files will be made.

Four formats of Time Series Scalar Data are currently offered: CSV (comma-separated variables), JSON (javascript object notation), ODV (Ocean Data View) and MAT (matlab). CSV, JSON and ODV are text format files readable by any text editor or text-reading capable software. MAT format files are readable by Mathworks Matlab. User requests for additional formats will be seriously considered (we're always happy to help), please Contact us

Oceans 2.0 API filter: dataProductCode=TSSD

Revision History

  • 20170401: JSON format files added
  • 20131003: Ocean Data View Spreadsheet TXT files added
  • 20130725: Data product options implemented, merged in CSV-NaN data product
  • 20130320: Improved support of varying sample periods, integration of QAQC flags
  • 20120626: Station search fully supported, so that file breaks are not made when the devices change
  • 20110912: Subsampled data products modified to extend query time range such that it has exact subsample period endpoints
  • 20110823: CSVs modified to contain up to 1 million records per file, header slightly modified
  • 20101130: 1 minute interval added to subsampling options
  • 20100513: Subsampling option introduced
  • 20091208: Data product initially released

See New Features Release Notes for more updates

Data Product Options

Quality Control

For time series scalar data:

Raw Data

When this option is selected, raw data will be supplied in the data products: no action is taken to modify the data. In general, all scalar data is associated with a quality control flag. These flags are stored adjacent to the data values.

Oceans 2.0 API filterdpo_qualityControl=0

Clean Data

Selecting this option will cause any data values with quality control failures (QAQC flags 3, 4 and 6) to be replaced with NaNs. If the do not fill data gaps option is selected, data values with quality control failures will be removed. For all data products, when resampling with the clean option, any data with quality control failures are removed prior to the resampling (this rule applies to all resampling types: average, min/max, etc).

This is the default option for all data products.

Oceans 2.0 API filterdpo_qualityControl=1


File-name mode field

'clean' is added to the file-name when the quality option is set to clean data.

Data Gaps

For time series data only:

Fill missing/bad data with NaNs (Not Number)

This option will, as it says, fill in data gaps with 'NaN' values in the data products. For CSV files, the text 'NaN' is inserted, while MAT files have a built-in type of the same name. Data gaps occur when the time difference between subsequent readings is greater than 1.9 times the sample period (otherwise known as the data rating). The NaNs are placed one sample period after the last reading before the data gaps.

This option will also keep any existing NaNs in the data. These are most often caused by the clean data option being selected, or by real NaNs being report, or when a sensor in a multi-sensor data product has no data. The metadata report accompanying the data product will elaborate on the QAQC test that was applied.

This is the default option.

Oceans 2.0 API filter: dpo_dataGaps=1

Do not fill gaps

This option will not take action to fill in data gaps.

This option will cause action to be taken to remove all NaNs in the data. The main implication of this is if the clean option had been selected, data that failed quality control tests will be removed entirely. However, there is an exception to this: for multi-sensor time series scalar data, if one sensor at a given time stamp has valid data, the entire row/time stamp cannot be removed, so the remaining sensors will be left as NaNs. For clarification, see the following example, note that QAQC flags of 1s are good data, 4s are failures and 9s are missing data:

sample time

sensor 1

sensor 1 flag

sensor 2

sensor 2 flag

Comment

12:00:00

42

1

42

1

Good row.

12:00:01

NaN

4

NaN

9

Two bad values; one QAQC failure, one data gap. If the do not fill gaps is selected, this entire row will be removed.

12:00:02

NaN

4

44

1

One good value, can't remove row.

File-name mode field

'NaN' is added to the file name when the data gaps are filled with NaNs.

Oceans 2.0 API filter: dpo_dataGaps=0

Resampling

For time series scalar data:

Resample Type:

  • None - no resampling. This is the default option for time series scalar data.

    Oceans 2.0 API filterdpo_resample=none

  • Average - the mean value within resample period (fixed-window averaging without overlap). This is also known as a 'box-car' or ensemble average. It is subject to the 70% data completeness QAQC check (see below) with the exception of engineering data or data from irregular or scheduled sampling. Only available with the clean data product option.

    Oceans 2.0 API filterdpo_resample=average

Resample Period:

Visible when an actionable resample type is selected, immediately to the right of the resample type. Current periods offered:

When resampling is selected:

  • The timestamps in the data series correspond to the centre of each resampling interval. (Data downloaded prior to 13 Feb 2013: timestamps were at beginning of interval). The resample interval always begins and ends at an integer multiple of the resample period, so minutes on the minute, hours on the hour, days on the day, etc.
  • If the date/time range on the search has limits that are within a resampling interval, the date/time endpoints are extended to include the entire resampling interval. For example, when daily resampling is selected from 03:00:00.000 on Monday to 20:00:00.000 on Thursday, the date range is extended to 00:00:00.000 on Monday to 23:59.59.999 on Thursday.
  • Note that tides are not filtered out in resampled products.
  • No anti-alias filtering is done. This is why only averaging and min/max are offered at this time. Box-car / ensemble averaging is an easily understood and ubiquitous process that is an effective low-pass anti-alias filter. For more information, see this page on data reduction and time-averaging.
  • All resampled data products are subject to an additional QAQC check on data completeness (except engineering data or data from irregular or scheduled sampling). If any resample period does not contain at least 70% of the expected data, the QAQC flag for this period will be a failure (6), unless overridden by a manual QAQC flag, see the QAQC page. For live data, it is quite likely that the last resample period will not be complete and will be flagged; this is especially obvious for plots. Future improvements will allow users to modify the data completeness threshold.

More options will be available in the future as we work to improve the data products, an example is Min/Max resampling (only available for plots). Feedback is welcomed and encouraged. For custom resampling, users can develop their own matlab code in CodeRunner in the ONC computing environment (users can access all production data and code). See CodeRunner Help for more details.

File-name mode field

The resample type and period are added to the file-name when resampling is selected. Example: 'avg1hour'.

JSON Output Encoding

Applies to JSON format files only.

Observations & Measurements (OM – JSON) Array Schema

Data will be output as three arrays for each sensor: sampleTime, values, qaqcFlags.

Oceans 2.0 API filterdpo_jsonOutputEncoding=OM

ONC Object Schema

Data will be output as a list of objects for each sensor. Inside each data object, there are single values of sampleTime, value, and qaqcFlag.

Oceans 2.0 API filterdpo_jsonOutputEncoding=ONC

File-name mode field

"OM" or "ONC" will appear last in the file-name mode, immediately prior to the ".json" file extension.


Formats

This data is available in CSV, JSONODV and MAT formats. Content descriptions and example files are provided below. A new file is started whenever an instrument has new coordinates (lat, lon, depth). See the mobile device page to see how these data products handle data from mobile devices.

CSV (Comma Separated Variables)

CSV-formatted data files can be opened with Microsoft Excel, Ocean Data View, R, SPSS, Minitab, Matlab, text editors or any other software capable of reading delimited text files. Each file is limited to a maximum of 1 million records.

Files are divided into sections for metadata and data. All non-data entries are preceded by the pound sign (#). Sub-sections are delimited by dashed-lines. Each section and its contents are described here, and a sample can be found below. 

  • Creation Date: Date and time (using ISO8601 format) that the data product was produced. This is a valuable indicator for comparing to other revisions of the same data product.

Origin Section

  • SOURCE: Citation author.
  • HTTP: Citation publication site.
  • HOME: Citation publication location.
  • FLDATE: Creation date of the file.
  • CITATION: Citation title (Can have multiple entries for each citation contributor and date range).
  • METADATF: Metadata file name.
  • SEARCHID: DMAS search ID from Oceans2.0.

Location Section

  • STNNAME: Station name. 
  • STNCODE: Station code.
  • LATITUDE:  Latitude north.
  • LONGITUDE: Longitude east.
  • DEPTH: Obtained at time of deployment (m).

Device Section

  • DEVCAT: Device category.
  • DEVTOT: Total number of device deployments contributing to data.
  • DEPLDATE: Device deployment date.
  • DEVNAME: Full device name.
  • DEVCODE: Device code.
  • DEVID: Device ID.

Data Section

  • DATEFROM: First timestamp (using ISO8601 format) contained within the time series.
  • DATETO:  Last timestamp (using ISO8601 format) contained within the time series.
  • PERIODTOT: Total number of sample periods.
  • PERIODST: Sample period start time.
  • PERIOD: Sensor sample period (s).
  • RESAMPPRD:  Re/subsample time in seconds.
  • RESAMPTYP:  As selected via the data search.
  • RESAMPMIN: Minimum percent valid data per resample. 
  • RESAMPDCR: Description of subsample type.
  • TOTSAMPLE: Total number of data samples in the file.
  • TOTSMPEXP: Total number of expected samples for the date range.
  • DPOPTGAPS: Data product option selected for data gaps: fill or remove missing data.
  • DPOPTQC: Data product option to select clean or raw data.
  • QAREMARK: Quality assurance remarks.

EXAMPLE FILE: BritishColumbiaFerries_Tsawwassen-SwartzBay_Fluorometer_Chlorophyll_20110317T212536Z_20110330T212506Z-NaN_clean.csv 

Oceans 2.0 API filter: extension=csv

CSV with NaNs

When the 'Fill data gaps with NaNs (Not A Number)' is selected, the time series scalar data products add lines of NaNs for missing samples or empty resample periods to fill the gap in the data, as described in the data gaps section

For example, a regular Time Series Scalar CSV file for an instrument with 4 sensors might contain the following for an instrument with a one second sampling period: (QAQC flags are excluded for this example)

20120206T000000.000Z,45.34,0.01,NaN,2543
20120206T000001.001Z,45.53,0.01,NaN,2542
20120206T000006.045Z,46.01,0.01,NaN,2541

while the same data for a CSV with NaNs would contain the following

20120206T000000.000Z,45.34,0.01,NaN,2543
20120206T000001.001Z,45.53,0.01,NaN,2542
20120206T000002.001Z,NaN,NaN,NaN,NaN
20120206T000003.001Z,NaN,NaN,NaN,NaN
20120206T000004.001Z,NaN,NaN,NaN,NaN
20120206T000005.001Z,NaN,NaN,NaN,NaN
20120206T000006.045Z,46.01,0.01,NaN,2541

In the first example, there was a data gap of four sample periods between the second and third lines.  This shows up in the CSV with NaNs as four lines of NaNs. In both cases, NaNs was written into the fourth column.  This is because no data was found for that sensor for any of the timestamps.  

This data product was created for users that are opening their CSV data within an application that requires the NaN-valued time stamps in order to graph the data properly.

The timestamps for the rows of NaN-values are calculated programatically as follows:

  1. Determine the gap size in milliseconds.
  2. Determine the number of missing time stamps in that gap.
  3. For each missing timestamp, increment by one sample period. In the example above, the timestamps were incremented by one second.

If there is any clock drift on the instrument, there may be a noticeable jump between the last timestamp in the datagap and the one immediately following, but it should never be more or less than two sample periods.


JSON

JSON-formatted data files can be opened with many text editors or any other software capable of parsing JSON format. Each file is limited to a maximum of one hundred thousand records.

Files contain two main objects: metadata and sensorData (one object per sensor). metadata contains the same metadata as the CSV file header, whereas sensorData differs from the CSV data section by having additional fields such as sensorName, unitofMeasure and actualSamples. See the CSV documentation above for more information on each field - the same definitions and java-code engine are used to generate both CSV and JSON. JSON files can be downloaded in two different formats as noted in the Data Product Options. The only difference between these two formats is the output of data field in sensorData. 

Here is the generalized JSON structure for both OM and ONC format JSON:

"metadata": {
      "dataSection": {
         "dataProductOptionGap": string,
         "dataProductOptionQualityControl": string,
         "dataQualityAssuranceRemark": string,
         "dateFrom": string,
         "dateTo": "string,
         "minPercentValidData": string,
         "resampleDescription": string,
         "resamplePeriod": string,
         "resampleType": string,
         "samplePeriodTotal": integer,
         "samplePeriods": [
            {
               "samplePeriod": integer,
               "samplePeriodStartTime": string
            }
         ],
         "totalSample": integer,
         "totalSampleExpected": integer
      },
      "deviceSection": {
         "deploymentTotal": integer,
         "deviceCategory":  string,
         "deviceDeployments": [
            {
               "deploymentDate": string,
               "deviceCode": string,
               "deviceId": integer,
               "deviceName": string
            }
         ]
      },
      "locationSection": {
         "depth": double,
         "latitude": double,
         "longitude": double,
         "stationCode": string,
         "stationName": string
      },
      "originSection": {
         "citations": string,
         "creationDate": string,
         "http": string,
         "metadataFileName": string
         "searchId": integer,
         "source": string
      }
   }
sensorData": [
      {
         "actualSamples": integer,
         "sensor": string,
         "sensorName": string,
         "unitOfMeasure": string,
 
         "data": [// for ONC-JSON (standard object-based)
            {
            "sampleTime": string,
            "value": double,
            "qaqcFlag": integer
            },
         ...
         "data": [ // for OM-JSON (Observations & Measurements)
            {
            "sampleTime": [array of strings],
            "value": [array of doubles],
            "qaqcFlag": [array of integers]
            },
          ]
      },
   ] 
}


Oceans 2.0 API filterextension=json


TXT (Ocean Data View Spreadsheet File)

Ocean Data View (ODV) spreadsheet files are plain text (ASCII) semi-colon delimited files similar to CSV files described above. They can be opened by Ocean Data View, R, SPSS, Minitab, Matlab, Microsoft Excel, text editors or any other software capable of reading delimited text files. Ocean data view can open/import this format without any additional user input and the data is instantly available for visualization. MS Excel users can view the file easily by importing with the delimiter set to a semi-colon. Each file is limited to a maximum of 1 million records (for compatibility with MS Excel).

ODV text files have three main parts: the file header, containing metadata, the data header and the data body. The data body contains the same data as a CSV file with additional metadata columns that Ocean Data Views uses to break up multiple deployments (for instance if instruments are swapped out, Ocean Data View will show this as separate stations). The file header has a fixed number of rows (it will grow horizontally with additional data), making it easy to handle in statistical packages like R. The field definitions provided below are the same as the MAT format data product (below) as both are generated by the matlab scalar data engine.

File Header

The file header contains the same information as the CSV header, with additional fields. All time data listed is in ISO 8601 format with dashes and colons; the time base is UTC or 'zulu' time, which is what the 'Z' following all the time stamps indicates. The header is structured with a comment marker '//' preceding every row, with data contained within XML-like tags that describe the data. For example, the first line of the header will normally be this:

//<Creator>Ocean Networks Canada - University of Victoria</Creator>

Additional important fields include:

  • CreateTime - the time that the file was created.
  • Citation - a single line with all of the citations, ordered by importance and date. For internal users, go to the Network Console to configure the citations. If a company has more that one role it will be collated. If there are gaps in the date ranges, they are filled in with the default Ocean Networks Canada citation. If the "Citation Required?" field is set to "No" on the Network Console then the citation will not appear.  If the special citation is blank/null, then the company default citation will be used and if it is also blank/null, then the citation will consist of the company name and role: "Ocean Networks Canada (Owner, Collaborator)".
  • DeviceDeployment - this is the time range of each deployment in a comma separated list. Each deployment is defined in the following fields: Location, SiteName, DeviceName, DeviceCode, Latitude, Longitude, Depth. In most cases, there will be only one device deployment listed. However, the likelihood of multiple deployments increases if the location search time range spans our maintenance season (June-September) when devices are swapped or redeployed.
  • SamplePeriod, SamplePeriodDateFrom, SamplePeriodDateTo - these three fields contain all of the sample period information that is applicable to the data found. (This is a different format than the presentation in the CSV file).
  • SamplesReceived, SamplesExpected - this is a summary of the number data samples in the file and number expected, after resampling/cleaning. Filled values don't count.
  • DataProductOptions - summarizes the options choosen for the data product, including quality control filtering, data gaps and resampling.
  • QC - this field describes the QAQC flags used. For ODV spreadsheet files only, the flag scheme is the ARGO standard adapted by ODV. ONC and ARGO flags are essentially identical with the exception that ONC uses flag 7 to represent averaged data. To conform to the ARGO scheme, any flags with a value of 7 are replaced with 1, where flag 1 is 'good data' and flag 7 is 'good averaged data'. The transformation from our flag scheme to ARGO and ODV flags can be found at the top of the QAQC page. Here is ODV's description of the available flag schemas: ODV4_QualityFlagSets.pdf. Note that ARGO flags are only supported in ODV version 4 and above.
  • DataQualityComment: In some cases, there are particular quality-related issues that are mentioned here. This is distinct from QAQC information mentioned above.

Data Header

The data header is the column headings for the data body. It contains headings like the following example. The top row is the column headings stripped of data format tags, the second row is a description of the headings, the third row is an example row of data.

Type

Cruise

Station

yyyy-mm-ddThh:mm:ss.sss

Latitude [degrees_north]

Longitude [degrees_east]

time_ISO8601

Seafloor Pressure [decibar]

QV:ARGO:Seafloor Pressure [decibar]

Blank

Device Name (ID number)

Site-Device Name (ID number)

Site-Device start time

(for the Site-Device)

(for the Site-Device)

time of data reading - primary variable

data value - dependent variable

ARGO QAQC Flag

*

NRCan Bottom Pressure Recorder 5 (22790)

Deep_BPR_2011-07 (100150)

2013-09-09T23:10:08.222

48.814

-125.281

2013-09-09T23:10:08.222

107.237646131

1

Here is an example file for one day of data: FolgerPassage_FolgerDeep_BPR_20110120T000000Z_20110120T235959Z-NaN_clean_ODV.txt

Resampled ODV txt files will also contain a variable containing the count of the data points that contributed to the resampled value (average and/or min/max). When averaging, the standard deviation is also provided.

Data Body

The data body contains semi-colon delimited data corresponding the column header. Some specific data may be blank if there is nothing to report (the type, cruise, station, yyyy-mm-ddThh:mm:ss.sss, Latitude, Longitude columns are blank except when the device deployment changes (as summarized in the file header). Data gaps are filled with 'NaN' (Not a Number). Time stamps follow the ISO 8601 standard with dashes and colons, as shown above. All times are UTC, not local time.

Instructions for Getting Started with Ocean Data View - How to Open ODV Spreadsheet Text Files

We recommend that users install the latest version of Ocean Data View from the ODV website. (Version 4 or newer is recommended for ARGO flag support). ODV's getting started guide can be found on their documentation page.

For an even faster start, follow these directions: start Ocean Data View, select File->Open, change the type of file to 'Data Files' so that it will find and accept .TXT files. To add more data to an existing collection (such as the one just created by opening a .TXT), select Import->ODV Spreadsheet. As data is added and plots are made, the data collection is automatically saved in an .ODV file and a sub-folder containing additional data. If you exit Ocean Data View, you can resume your data collection by opening that .ODV file. The default view is a world map, which isn't interesting. To add a simple plot, select View->Layout Templates->SCATTER WINDOW. Following these steps with the above example ODV spreadsheet file, you should see this:

In addition, right-click on the plot to change which variables are plotted and access the plots' properties. For multiple device deployments, go to View->Station Selection Criteria and select different cruise labels to see the data from different device deployments. To sort out QAQC flags, right-click on the plot and select Sample Selection Criteria and then highlight the flags to filter the data inclusively.

Oceans 2.0 API filter: extension=txt

MAT (Matlab data file) 

MAT files (v7) can be opened using Mathworks Matlab 7.0 or later. These files are limited to a size of 400 MB. The file contains two structures, metadata and data.

 metadata: a structure array (one structure per device) containing the following metadata fields:

  • creationDate:Date and time (using ISO8601 format) that the data product was produced. This is a valuable indicator for comparing to other revisions of the same data product.
  • deviceDetails: a structure array with a structure for each deployment, with the following fields:

    • deviceDeploymentDateFrom
    • deviceDeploymentDateTo
    • deviceID: A unique identifier to represent the instrument within the ONC observatory.
    • deviceName: A name given to the instrument.
    • deviceCategory: A unique name given to the category of devices, such as 'CTD'
    • deviceCategoryCode: Code representing the device category. Used for accessing webservices, as described here: API / webservice documentation (log in to see this link).
    • deviceCode: A unique string for the instrument which is used to generate instrument search data product file names.
  • location: a structure array with a structure for each deployment location, with the following fields:

    • stationName: Secondary location name.
    • stationCode: Code representing the station. Used for accessing webservices, as described here: API / webservice documentation (log in to see this link).
    • depth_metres: Obtained at time of deployment. If NaN, the device is mobile and this position is a variable, the data for which is supplied by a sensor in the data struct.
    • lat_degrees: Obtained at time of deployment. If NaN, the device is mobile and this position is a variable, the data for which is supplied by a sensor in the data struct.
    • lon_degrees: Obtained at time of deployment. If NaN, the device is mobile and this position is a variable, the data for which is supplied by a sensor in the data struct.
    • heading_degrees: Obtained at time of deployment. If NaN, the device is mobile and this position is a variable, the data for which is supplied by a sensor in the data struct.
    • pitch_degrees: Obtained at time of deployment. If NaN, the device is mobile and this position is a variable, the data for which is supplied by a sensor in the data struct.
    • roll_degrees: Obtained at time of deployment. If NaN, the device is mobile and this position is a variable, the data for which is supplied by a sensor in the data struct.
  • dataQualityComments: In some cases, there are particular quality-related issues that are mentioned here. This is distinct from QAQC information contained in the data structure.
  • Attribution: A structure array with citation information, ordered by importance and date. For internal users, go to the Network Console to configure the citations. If a company has more that one role it will be collated. If there are gaps in the date ranges, they are filled in with the default Ocean Networks Canada citation. If the "Citation Required?" field is set to "No" on the Network Console then the citation will not appear. For data products with a citation (except MAT files) and for users making products from a MAT file, if the special citation is blank/null, then the company default citation will be used and if it is also blank/null, then the final citation will consist of the company name and role: "Ocean Networks Canada (Owner, Collaborator)". Here are the fields:

    • acknowledgement: the citation text, note that if the special citation is blank/null, the default citation is used.
    • startDate: datenum format
    • endDate: datenum format
    • organizationName
    • organizationRole
  • totalScalarSamplesReceived: The number of time stamps that have any valid data on any sensor (at each time stamp). Only defined for metaData(1).totalScalarSamplesReceived, as this total is a summary of all device deployments in the data product.

data: a structure array (one structure per sensor) containing the following fields:

  • sensorID: Unique identifier number for sensor.
  • sensorName: Name of sensor.

  • sensorCode: Unique string for the sensor.

  • sensorDescription: Description of sensor.

  • sensorType: Type of sensor as classified in the ONC data model.

  • sensorTypeID: ONC ID given to sensor type.

  • units: Unit of measure for the sensor data.

  • isEngineeringSensor: boolean (flag) to determine if sensor is an engineering sensor.

  • sensorDerivation: String describing the source of the sensor data: derived from calibration formula (dmas-derived), calculated on the device (instrument-derived), calculated by an external process (externally-derived), or direct from the instrument.

  • propertyCode: unique string for the sensor that is used in the Oceans 2.0 API.
  • isMobilePositionSensor: boolean (flag) to determine if sensor is a mobile sensor. Note, this will only be flagged true if this data was added in addition to the requested data. For example, if the user requests a device-level mat product from a GPS device, then the latitude sensor is not flagged. Conversely, if the user requests temperature data from a mobile platform like a ship, then the latitude data from the GPS is added and interpolated to match the time stamps of the temperature sensor. See Positioning and Attitude for Mobile Devices for more information.

  • deviceID: Unique identifier number for the parent device.

  • searchDateNumFrom: Start date of the specific search in MATLAB datenum format - searches are truncated by availability and deployment dates.

  • searchDateNumTo: End date of the specific search MATLAB datenum format - searches are truncated by availability and deployment dates.

  • samplePeriod: Vector of sample periods in seconds.

  • samplePeriodDateFrom: Vector of the start date of each sample period (MATLAB datenum format).

  • samplePeriodDateTo: Vector of the end date of each of sample period (MATLAB datenum format).

  • sampleSize: The size of the data sample. 

  • resampleType: Type of resampling used.

  • resampleDescription: Description of the resampleing used.

  • resamplePeriod_sec: Resample period in seconds.

  • resampleTypeID: Unique identifier of the subsample type used: 0/NaN - none, 1 - average, 2 - decimated (not offered), 3 - min/max, 4 - linear interpolation (VPS pressure only).

  • dataProductOptions: A string describing the data product options selected for this data product. This information is reflected in the file name.

  • qaqcFlagDescription: A string describing the flags. See the QAQC page for more information.

  • time: A vector of data timestamps in MATLAB datenum format.

  • dat: A vector of sensor values corresponding to each timestamp. When resampling by averaging, this becomes the average value. (May make a separate field for this in the future, especially if users prefer that option).

  • qaqcFlags: A vector indicating the quality of the data, matching the time and dat vectors. See the QAQC page for more information.

  • dataDateNumFrom: First time-stamp of the time series.

  • dataDateNumTo: Last time-stamp of the time series.

  • samplesExpected: The number of valid samples expected from the minimum returned data to the maximum returned data, accounting for variations in sample period.

  • samplesReceived: The number of raw samples received, maybe less than length(data.time) when data gaps are being filled with the NaN option.

  • Calibration: Structure containing information on the calibration formula applied to the data, as a it appears on the sensor listing page, in the JEP langauage. Fields include: dateFrom, dateTo, sensorID, name, formula.

EXAMPLE FILE: FolgerPassage_FolgerDeep_BPR_SeafloorPressure_20160614T000133Z_20160615T000132Z-NaN_clean.mat

Oceans 2.0 API filter: extension=mat


Discussion

To comment on this product, click Add Comment below.