Although each type of sensor or instrument collects and stores data in a proprietary format, all the information provided in this database has the same form. A common methodology is used to treat all the kinds of data collected, and create files of a format called the Network Common Data Form (NetCDF). All the processing steps are discussed in the Data Processing section, and more detailed information about NetCDF is provided in the NetCDF storage section. The following paragraphs provide an overview of what the user can expect to find in files in this database. The files in this database each contain data from one instrument, and since current meters don't typically also measure hydrographic properties, a user must access several files to examine both velocity and temperature data from a single platform.
The measurements in these files are collected during scientific research projects focusing on coastal processes, including sediment transport. Most of the observations were made near the sea floor, though many experiments also obtained current velocity data throughout the water column. Measurements made at a single depth are referred to as “point” data; measurements made at multiple depths from a single instrument (for example, acoustic or optical instruments) are called “profile” data. In some projects, meteorological measurements were also collected to provide data that may be used to determine atmospheric forcing.
Two forms of the data are distributed: one conforms to the conventions for Climate and Forecast (CF) version 1.6 (CF-1.6) and the other to the Equatorial Pacific Information Collection (EPIC) conventions. Our existing processing software generates EPIC-compliant files, and these are considered the definitive form of the data. The EPIC convention also includes standard names and vocabulary that are more specific to oceanography than the CF-1.6 names are, and maintaining it allows for backward compatibility. In 2014–15, we developed additional software to convert the EPIC files to CF-1.6 compliance because CF-1.6 is more widely used now, and the feature types and data models needed to describe our time-series data exist in version 1.6 and newer. We continue to use the EPIC vocabulary because it contains more terms specific to oceanography and for backwards compatibility.
For EPIC-compliant files, the NetCDF common data model “grid” data type has four dimensions (time, depth, lat, lon). Even though there are four dimensions, five coordinate variables define these dimensions. The time of the observation is encoded as two variables because of historical accuracy problems stemming from the limited number of bits older computers could access. The first time variable ("time") is true Julian Day (May 23, 1968 = 2,440,000); the second time word ("time2") is milliseconds (ms) from 00:00 on that day. The actual time in days may be computed as time + (time2/86,400*1,000) [the conversion uses 86,400 seconds per day and 1,000 milliseconds per second]. The x,y,z spatial coordinates are specified in the “lon,” “lat,” and “depth” variables.
In CF-1.6 compliant files, two feature types are used: ‘timeSeries’ for data acquired at one depth and ‘timeSeriesProfile’ for data acquired at many depths. The time of the observation is encoded as a single time variable that is used as a dimension. The units are usually “seconds since 1970-01-01T00:00:00Z” in the Gregorian calendar. A z dimension exists only if the data has multiple depths, such as velocity data from profiling current meters. The elevation of the sensor head is contained in the “sensor_depth” attribute of each variable, and the x,y coordinates are provided in the “latitude” and “longitude” variables. CF-1.6 files retain the EPIC variable names, and where available, a “standard_name” attribute is added to the variable attributes containing the equivalent CF-1.6 name. For instance, in a CF compliant file, the “u_1205” variable name comes from the EPIC vocabulary, and it has a “standard_name” attribute of “eastward_seawater_velocity”.
Some data types do not fit the data model for either convention; for files measuring bursts or wave spectra, more dimensions are used to describe the shape of the field than are permitted by the conventions. For instance, a file containing 200 bursts of 1,024 points has time dimensioned as (200, 1,024), when an evenly spaced timeseries would be dimensioned as (200). Files containing wave directional spectra data will have a “dspec” variable; these files are dimensioned as (time, frequency, direction, latitude, and longitude). Similarly, our sonar data files have dimensions of (time, points, scans) to describe the shape of the data, since they have spatial extent at the measurement location. At the time of publication, the burst, wave, and sonar data are not converted to CF-1.6 and are released only in EPIC-compliant form. We plan to add these types of data to the CF conversion list when representations in the data model become available.
|Return to Top||
||Go to Next Topic |