|
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 oceanographic 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.
Data are distributed conforming to either the Climate and Forecast (CF) conventions or the Equatorial Pacific Information Collection (EPIC) conventions. Prior to 2021, data were released in both EPIC and CF conventions. Beginning in 2021, most data are released only in the CF-compliant version. Appropriate attributes that link the CF standard names to EPIC codes, when available, are listed in the CF-compliant data to ease the transition from EPIC to CF.
For EPIC-compliant files, the netCDF common data model “grid” data type has four dimensions (time, depth, latitude, longitude). 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 longitude, latitude, and depth variables.
In CF-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 given in the form “{units} since {datetime}”; for example, “seconds since 1992-10-8 15:15:42.5 +0:00” in the Gregorian calendar. A z dimension exists only if the data have 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 files may retain the EPIC variable names, and where available, a “standard_name” attribute is added to the variable attributes containing the equivalent CF 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.”
| Return to Top | |
| Go to Next Topic |
|