NOTE: The netcdf-hdf mailing list is no longer active. The list archives are made available for historical reasons.
EVALUATION OF THE STANDARD DATA FORMATS
HDF, netCDF, and CDF
FOR SeaWiFS OPERATIONAL PRODUCTS
Calibration/Validation Program
SeaWiFS Project (Code 970.2)
NASA Goddard Space Flight Center
Greenbelt, Maryland 20771
September 24, 1992
INTRODUCTION
The SeaWiFS Project would like to define a standard data
format for its operational distribution products. A standard
format permits the applications programmers and the data users to
not have to concern themselves with the physical storage format of
the data--a set of software routines associated with the format are
used to read or write the data in the standard's form. The
technical and practical considerations of such a format include:
1. Technical considerations:
a. Machine independence
b. Support of platform-native formats
c. Translation of foreign formats on I/O
d. Platforms supported
e. Self describing
f. Subsampling on input
g. Support of multi-dimensional data
h. High-level specification of data structure
i. Computer language interfaces
j. Availability of convenient library routines
k. Storage requirements
2. Practical considerations:
a. Acceptance by scientific community
b. Development and user support
c. Documentation
d. Cost
e. Accompanying tools
f. Available data and software for SeaWiFS
It should be noted that none of these items are absolutely required
to permit distribution of data, but they are important in ensuring
a certain level of convenience for the users of the SeaWiFS
products and in facilitating the Project's efforts in software
development and data validation.
Three candidate formats have been considered: HDF (for
Hierarchical Data Format), developed by the University of Illinois'
National Center for Supercomputer Applications (NCSA); netCDF (for
Network Common Data Form), developed by UCAR's Unidata Project; and
CDF (for Common Data Format), developed at the NASA Goddard Space
Flight Center. NetCDF is a derivative of an earlier version of CDF
and these two formats therefore have many similarities.
RECOMMENDATIONS
Of the three formats evaluated, NASA's CDF format offers the
clearest advantages and no technical disadvantages with respect to
its application to SeaWiFS products. Important advantages of CDF
include:
- Translation of native formats across platforms on I/O (1c).
- Current or planned availability on all platforms of interest
to SeaWiFS (1d).
- Capability to subsample on input (1f).
- Data structure specification language (1h).
- Good support and documentation (2b and 2c).
- Large amounts of data and software available for use by the
Project (2f).
The only negative with respect to CDF is the fact that it is not
currently planned to be supported by the EOS Project directly, as
for HDF, or indirectly, as for netCDF (Section 2a).
HDF, on the other hand, suffers from serious disadvantages
including:
- No translation of native formats across platforms on I/O
(1c).
- No port to NeXT computer (1d).
- Awkward in terms of programming and suitability for SeaWiFS
product contents (1e and 1j).
- No capability to subsample on input (1f).
- No data structure specification language (1h).
- No integrated documentation manual for current release (2c).
Because of these disadvantages, its use would entail a significant
additional burden to the SeaWiFS Project in terms of development
effort, its ability to coordinate non-GSFC HRPT stations' data,
and, ultimately, in convenience to its end users. The only
advantage of HDF over CDF is its designation by the EOS Project as
the standard prototype format for DAAC products (Section 2a).
NetCDF also suffers from serious disadvantages relative to CDF
with respect to its applicability to SeaWiFS products. These
disadvantages include:
- No support of native formats (Section 1b).
- No recognition of native formats across platforms (1c).
- No port to NeXT computers (1d).
- No capability to subsample on input (1f).
- Small development group (2b).
- Poor tools (2e).
However, netCDF shares some advantages with CDF over HDF, such as
a greater suitability to SeaWiFS product contents (Sections 1e and
1j) and a similar data structure specification language (1h). Its
only advantage over CDF is the fact that the EOS Project is funding
a netCDF/HDF merger (Section 2a), currently in progress. Such a
merger, of course, does not eliminate the shared disadvantages from
either of the merged formats.
1. TECHNICAL CONSIDERATIONS
1a. Machine independence.
Machine independence implies that a data file created and used
on one platform may be copied and used directly on another platform
whose binary storage format is different. HDF, netCDF and CDF all
provide this capability by using a binary format based on XDR (for
eXternal Data Representation). Some platforms (e.g., Sun) use XDR
as their native format. However, on platforms whose binary format
is not this machine-independent form, the software automatically
converts the data into the native form during read operations for
processing and converts the data into the machine-independent form
during write operations for storage. The applications programmer
and the user need not concern themselves with the binary format of
the data. The extent of "independence" is defined by the platforms
for which the format software has been ported (see Section 1d).
The conversion to and from machine-independent form results in
a significant decrease of input/output speed (see Section 1b) but
is extremely useful for data that are meant to be transferred often
across differing platforms. An alternative to "machine
independence" is to provide utilities that convert data from one
binary form to another for use when data files are transferred to
different platform types. This is not a convenient option when
data are transferred often since it is a time consuming process and
may result in serious error if the user neglects to do a
conversion.
1b. Support of platform-native formats.
As stated in the previous section, the conversion to and from
machine-independent form results in a significant decrease of
input/output speed. This "overhead" may be avoided if the format
software provides options for creating the data files in native
formats. If the data files are stored on the platform on which
they will be used primarily, it would obviously be most efficient
to create them in that platform's native format. When transferred
to a new platform type, they could then be converted to the
machine-independent format or to the native binary format of the
new platform. Thus, this capability permits data to be distributed
in machine-independent form and be converted to native format for
storage and use on users' individual machines.
This capability is especially important to the SeaWiFS Project
since it would permit HRPT receiving stations around the world to
rely on various platforms, including less expensive, but slower,
PC-compatible computers for data capture and processing. Thus, it
is important to have a standard format that performs reasonably
well on such slower platforms when dealing with SeaWiFS' very large
image files. The savings (20 to 50%, depending on data types,
structure, and access speed) of this overhead is significant and
may be essential to permit the effective use of slower platforms.
HDF and CDF support the use of native formats on all their
platforms. The new version of HDF allows native formats for its
Science Data Sets (SDS) as well as its Vsets (V is for vertices)
construct. (Vsets allow relationships among SDSs and other data
types to be specified.) NetCDF provides no native format
capability. (Of course, as stated above, certain platforms use a
native format based on XDR.)
1c. Translation of foreign formats on I/O.
In addition to its native format capabilities, CDF software
can also recognize the native formats of platforms other than the
host platform (foreign formats) and convert them to that of the
host for processing. This capability is again especially useful to
the SeaWiFS Project since all non-GSFC HRPT stations which obtain
SeaWiFS research licenses will be required to deliver data to the
SeaWiFS Project or to other authorized users in the specified
machine-independent format upon request. Only CDF would allow them
to store and efficiently use their data in native formats and also
deliver those data without having to convert them on those
stations' possibly slower machines. In essence, this capability
makes the native format the machine-independent format.
Users receiving those data would also not have to convert them
to their respective native formats for storage unless choosing to
do so for the sake of efficiency. Conversion of large amounts of
data can be very time consuming and would not be worthwhile for
data that are to be used occasionally.
HDF software recognizes when data are stored in a differing
native format. The software issues an error in such cases but does
not allow translation of the data. Since netCDF uses only XDR,
even detection of foreign formats is not necessary.
1d. Platforms supported.
The extent to which the software of each standard is supported
at any one time on different platforms is difficult to ascertain.
In theory, the software should be tested, and possibly modified,
for each new version of each operating system. Moreover, different
models from the same computer manufacturer may not be completely
binary compatible, so that the inclusion of a manufacturer should
not imply that the software has been validated on all its platform
models. Given these caveats, the following is a list of platforms
claimed to be supported by the formats:
HDF:
Unix: SGI, Sun, DECstation, Cray, Alliant
Other: PC/DOS, Macintosh, (VAX)
netCDF:
Unix: SGI, Sun, DECstation, IBM RS/6000, HP 9000, Cray
Other: VAX, PC/DOS and OS/2, IBM mainframes, Macintosh
CDF:
Unix: SGI, Sun, DECstation, IBM RS/6000, HP 9000, (Cray)
Other: VAX, PC/DOS, NeXT, (Macintosh)
VAX for HDF, and Cray and Macintosh for CDF, are in parentheses to
indicate that those ports are in progress or are planned for the
next release.
Platforms that are of special interest to the SeaWiFS Project
should be noted:
- SGI, used by various elements of the Project and for the
operational generation of SeaWiFS products.
- NeXT, used for the field data processing system by the
Calibration/Validation (Cal/Val) element.
- VAX, used for the field data processing system, the Univ. of
Miami group, the GSFC Laboratory for Hydrospheric Processes
Ocean Color Group, and, to a lesser extent, by the Science
Data Processing System (SDPS) element.
- PC (DOS), used for the field data processing system, by
individual Project investigators, and supported by SEAPAK,
the oceanographic satellite and environmental data analysis
package developed by the Ocean Color Group.
- Macintosh, used for the field data processing system and by
individual Project investigators.
- Cray, used by the Mission Operations and Cal/Val.
In addition, personal computers, workstations, and mini-computers
are all potential platforms for the HRPT receiving stations and are
therefore also of interest (see also Sections 1b and 1c).
Support for a variety of platforms, as is indicated for
platform-independent formats, requires almost continual attention
by the development group. Because of problems often encountered
when using software with new operating system versions, the
availability of development support (see Section 2b below) will be
very important for SeaWiFS programmers over the life of the
Project.
1e. Self describing.
Data formats are considered self describing when the files
contain explicit information allowing their contents to be
interpreted. This information includes details, such as the number
of variables, the size of arrays, and their data types, that permit
the software to correctly access the data values. In addition,
self describing information includes metadata or information about
the data contents that is more useful to the user. Metadata
includes descriptive names, units, or comments.
Although all three candidate formats provide this self-
description capability, HDF provisions for such information are not
nearly as convenient as those of netCDF or CDF. SeaWiFS products
will require metadata in the form of characters, integers, real
numbers, scalars, arrays, as well as on a per-record basis. HDF
requires attributes to be associated with their variables via
pointers. Array metadata would have to be declared as separate
SDSs associated implicitly with their corresponding variables in an
SDS file or use Vsets to make this association explicit. (Vsets
allow additional relational information to be defined. See also
Sections 1b and 1j). Of course, metadata can always be written as
ASCII strings within HDF annotation fields. However, this is not
a satisfactory solution since ingest software would have to parse
the string in order to find the labels and read in the values.
1f. Subsampling on input.
CDF is the only format that allows a programmer to specify a
pixel subsampling rate upon input. This capability is particularly
useful for SeaWiFS' very large image files (100MB or more) in that
it allows, for example, the direct display of an entire image at
lower resolution. The less convenient and less efficient
alternative would be to read the file in small sections in order to
accommodate a computer's memory while subsampling into smaller
arrays to effect the lower resolution.
1g. Support of multi-dimensional data.
All three formats allow variables of differing dimensions to
be represented in the same data set.
1h. High-level specification of data structure.
CDF and netCDF support a high-level "language" that can
describe a data set's structure and list its metadata. CDF and
netCDF provides utilities that can generate the specifications for
a given data set and create a data set skeleton from a given
specification. This provides, for example, a convenient way for a
user to create a data set structure and input its metadata by
writing the specifications in the proper syntax or by editing those
of an existing data set. Moreover, it allows the specifications of
a data set (its "layout") to be communicated among users in a
concise, unambiguous manner.
HDF does not support this type of data set specification. For
a large development effort such as the SeaWiFS data system, the
lack of this capability is a serious handicap.
1i. Computer language interfaces.
All three formats support interfaces for C and FORTRAN to
their library routines.
1j. Availability of convenient library routines.
Based on programming experience with all three formats, CDF
appears to have the most convenient set of library routines for
programming, followed closely by netCDF. HDF tends to require, for
example, many more calls to various subroutines in order to perform
a similar task than CDF or netCDF. Moreover, HDF requires
additional HDF-specific "tags" for explicitly defining variable
types.
HDF's ease-of-use suffers from the fact that the format was
originally designed to represent only raster images in 8- and
24-bit pixels. The SDS and Vsets constructs were added
subsequently to support other data types, such as real numbers, and
other data structures. SeaWiFS' requirement to store multiple data
types in Level-3 products, for example, and multiple bands or
parameter fields within the same data sets for all its products,
can best be handled in HDF via its Vsets construct. This
representation is more awkward and tedious than for CDF and netCDF
in that the user must explicitly specify the relationships of the
bands to the underlying grid or the geocoordinate lattice.
The complexity of HDF's various data structures is of
additional concern to SeaWiFS because of the HRPT stations. These
stations may not have the resources in terms of expertise in data
formats or personnel for software development. As a result, there
can be a reluctance on their part to use a format that is less
directly suited to their data requirements. Because the SeaWiFS
Project is responsible for providing support to these stations, any
additional support required by these stations for development of
software to input, output, or transfer data translates into greater
demands on the resources available to the Project.
1k. Storage requirements.
The storage space overhead associated with each of the formats
is essentially the same and is usually trivial. The amount of
overhead depends on the amount of metadata and the type and amount
of actual data. For SeaWiFS products, this overhead will be about
two percent.
Although none of the formats provide a data compression
capability, such a capability could be very useful for large data
set files such as SeaWiFS products. Of interest, therefore, are
the plans of the HDF and CDF development teams to implement this
capability. Depending on the exact methodology, data compression
would be useful to SeaWiFS for distribution purposes and for the
added convenience of storing occasionally used data in compressed
form by the end user.
2. PRACTICAL CONSIDERATIONS
2a. Acceptance by scientific community.
The acceptance of a standard format by the scientific
community is important for several reasons:
- It helps ensure that political and financial support for the
format and its development effort will continue, evolving
with new features and supporting new platforms and operating
systems.
- It increases convenience for users who are familiar with the
standard and have obtained or developed software based on
that standard.
- It allows relevant data using the same format to be analyzed
using essentially the same software, again increasing user
convenience.
- It results in support of that format by commercial companies
for their analysis packages, thus greatly increasing the
availability of useful software to users of that format.
It should be noted that it is very difficult to gauge the extent to
which formats are actively being used by the outside communities
and to judge the level of satisfaction of the users. Such a survey
would obviously be very useful.
HDF has been selected as the standard format by EOSDIS for use
by the Distributed Active Archive Centers (DAACs). The format
appears to be widely used by researchers especially for raster
image type data for which it was originally designed. NetCDF also
appears to be widely used, especially by the meteorological
community. In addition, NCSA has been funded by NSF and EOS to
incorporate the netCDF library into the HDF library, allowing users
who normally use HDF to input netCDF data sets and, presumably,
convert them into HDF if desired.
At this time, it is not clear for the merged HDF/netCDF format
how all the attributes and other metadata are handled and
converted; whether or not the netCDF data must follow a "standard"
structure or, conversely, how "generic" the code must be; and if
there is any overhead associated with inputting netCDF vs. HDF. If
no overhead is involved, there would be no need to convert them
since there would be no disadvantage to remaining as netCDF data.
NCSA is also planning to allow netCDF software to input HDF data,
a much more difficult task, as the next part of this effort.
One should note here that merging different format standards
is not necessarily a good idea since a desirable attribute of any
format is that it be easy to use. The forcing of formats that
differ fundamentally in their structure into one "mega-format" may
result in a standard that is too big and complicated to understand
and use. Also, a merger does not eliminate disadvantages shared by
both formats with respect to the SeaWiFS Projects as discussed in
this report. Finally, such a merger adds additional constraints on
each format development group, forcing them to march in lock-step
with respect to their support of new features or operating systems.
Thus, a merger may hinder a format's ability to overcome its
current disadvantages as well as keep up with the ever changing
computing environment. In this sense, the benefits of merging
netCDF with HDF remain to be seen.
NASA's CDF is also widely used by the meteorological
community. CDF's exposure to this group is primarily via the NASA
Climate Data System (NCDS), whose users number in the hundreds.
Over two thousand CD-ROM diskettes containing meteorological and
atmospheric constituent data in CDF form were also produced and
distributed by Goddard's Distributed Active Archive Center (DAAC)
at the recent world conference on the global environment in Rio de
Janeiro. CDF has been selected as the standard format for the
prototype TRMM data system and for the data generated from the ISTP
satellites. Although the large ISTP planetary science community is
unlikely to be interested in any Earth science data, their
selection does help ensure that adequate funding to the CDF group
will continue for at least the next decade.
NCSA will also look into the possibility of a merger of CDF
and HDF similar to that of netCDF and HDF. The CDF development
group has expressed an interest in such an effort although there
are no definite plans or funding for this at this time. Because of
the design similarities between CDF and netCDF, the effort required
to merge each with HDF would also be expected to be similar.
2b. Development and user support.
Development support is support for the development of the
format software. This includes the timely correction and
notification of errors; continued testing for ports to new
platforms or new operating systems (see Section 1d); the continued
evolution of the software, especially to incorporate new features
found to be desirable or necessary; and the improvement and
updating of documentation. User support includes response to
queries regarding programming with the software and regarding the
efficient implementation of unusual data.
A primary indicator of both types of support is the size of
the development group for each format. HDF appears to have the
largest group, with 4 to 8 people (including student personnel)
working on the project. A substantial portion of this effort
involves the development of display, analysis, and data management
tools associated with HDF (see Section 2e) and another part of this
effort involves the netCDF/HDF merger. EOS' use of the standard
ensures that support for DAAC product developers will be adequate.
Furthermore, NCSA has expressed, via the EOS Project, a desire to
accommodate requirements by such developers.
The CDF group is comprised of 3 to 4 people. Members of the
SeaWiFS Calibration/Validation (Cal/Val) team and the Laboratory
for Hydrospheric Processes' Ocean Color Group have worked with the
group for a number of years. The interaction has been the result
of an ongoing collaboration with the NCDS which has been funded for
the past five years. The Ocean Color Group has found the response
to be very fast and the quality of support to be excellent.
Moreover, they have already incorporated features suggested by the
Ocean Color Group in new versions of their software. A major
advantage to the SeaWiFS Project of the CDF group in this regard is
its physical location at GSFC permitting person-to-person
discussions of problems.
Finally, the netCDF group includes the equivalent of less than
one person on their development effort. Of the three format
groups, netCDF seems to rely the most on outside users performing
ports and providing public domain software. Such use of third-
party software ensures that the quality of the products and support
for these products will not be uniform. NetCDF does, however, have
a very active electronic mail group which provides a convenient
forum for the exchange of useful information.
2c. Documentation.
A comparison of the documentation associated with each format
indicates that the current documentation for CDF is the best,
followed closely by that for netCDF. The documentation for HDF
however is outdated, poorly organized, and difficult to follow and
understand. The new release of HDF was not accompanied with
integrated documentation; its new features are described in a
series of updates to the documentation of the previous release
(dated 1990).
2d. Cost.
All software packages and documentation for the three formats
are available for little or no cost.
2e. Accompanying tools.
HDF appears to have the most comprehensive set of software
tools for that format, including graphical display of data, data
analysis, and data management. However, most of these do not
support Vsets which would be useful to SeaWiFS products (see
Sections 1b and 1j). CDF has a beta version of a graphical display
tool as well as a well developed interactive tool for ASCII
examination of the data. The netCDF group has not developed good
comparable tools but again relies on outside users to make such
tools available to the community.
It should be noted that, for the SeaWiFS Project, the
availability of accompanying tools is not an important
consideration since more powerful, customized tools will be
developed using IDL (for Interactive Data Language), a commercial
data analysis package. IDL's current beta version supports netCDF
and CDF as input data formats and will have similar support for HDF
within a month. Therefore, the availability of accompanying tools
serves mainly as a convenience to SeaWiFS' end users. However,
since IDL and a number of other commercial analysis packages
support or plan to support these formats, and since these packages
are becoming quite popular, many end users are also likely to
prefer them for building customized tools.
2f. Available data and software for SeaWiFS.
As a result of a March, 1992, decision to use netCDF, some
effort has been expended by the SeaWiFS Project to implement the
netCDF software and create test data sets on the SGI and PC
platforms and to develop a simple display program for the SGI. The
extent of the effort was on the order of a few man-weeks. This
earlier decision to use netCDF was based primarily on the judgement
that it was more suitable for SeaWiFS products than either HDF or
CDF. At the time, for example, HDF did not support the storage of
two-byte integers in addition to not having a data structure
specification language (see Section 1h). For CDF, the available
version did not directly support variables of differing
dimensionality (see Section 1g).
Previous efforts by the Ocean Color Group include about five
man-years developing software for using CDF data and another five
man-years for the creation of over 15 gigabytes of ocean related,
CDF data sets (see Appendix). Some of this software and data are
directly applicable to the Cal/Val effort. The use of the CDF
format by SeaWiFS would eliminate the very resource consuming task
of converting these data and software for use by the Project.
No effort in development of software or creation of data sets
has been expended by the Project for HDF. However, some effort
(several man-days) has been spent on evaluating HDF documentation,
attending demonstrations, and discussing its capabilities with
others who have used the format.
APPENDIX
SEAPAK NASA-CDF DATASETS
1. Climate Analysis Center Sea Surface Temperature product
Period: 01/82-Present(Blended), 01/70-12/84(In-Situ)
Temporal/Spatial Resolution: Monthly/2 degrees
Spatial Coverage: Global
2. FNOC Surface Winds
Period: 1/79-present
Spatial Coverage: Global
Temporal/Spatial Resolution: 12hr/2.5ox2.5o
Parameters: Surface U and V components
3. COADS Trimmed Monthly Groups
Period: 1/46-12/79, 1/80-12/89
Spatial Resolution: 2 degrees
Parameters:
Group 3: SST (S), rel. humid., spec. humid. (Q), air temp.(A)
Group 4: scalar wind speed (W), U, V, pressure
Group 5: total cloudiness, rel. humidity, wind stress (U,V)
Group 6: (S - A), (S - A)*W, (saturation Q at S) - Q, evapora-
tion parameter
Group 7: U*A, V*A, U*Q, V*Q
Statistics: (1/46-12/79) mean, std. dev., number of obs.
(1/80-12/89) mean, number of obs.
4. The NCAR World River Discharge Data Set (Source = UNESCO)
Period: 1807-1972
Temporal Resolution: Monthly and Annual
Parameters-Annual: latitude, longitude, altitude, drainage
area, site number, average annual discharge, maximum dis-
charge, date of maximum discharge, minimum discharge, date of
minimum discharge, data source code, time
Parameters-Monthly: latitude, longitude, altitude, drainage
area, site number, average monthly discharge, data source
code, time
5. Levitus Mixed-Layer Climatology
1. 1-degree global grid, monthly, 0.5 degree criterion
6. NODC Global Annual Hydro. Analyses
Spatial Resolution: 1 degree
Standard Depths: 0, 10, 20, 30, 50, 75, 100, 125, 150, 200,
250, 300, 400, 500, 600, 700, 800, 900, 1000, 1100, 1200,
1300, 1400, 1500, 1750, 2000, 2500, 3000, 3500, 4000, 4500,
5000, 5500 m.
Parameters: temperature, salinity, dissolved oxygen, % oxygen
saturation.
7. NODC Global Seasonal Hydro. Analyses
Spatial Resolution: 1 degree
Winter (Feb-Apr), Spring (May-Jul), Summer (Aug-Oct), Fall
(Nov-Jan).
Standard Depths: 0, 10, 20, 30, 50, 75, 100, 125, 150, 200,
250, 300, 400, 500, 600, 700, 800, 900, 1000, 1100, 1200,
1300, 1400, 1500m.
Parameters: temperature, salinity.
8. NODC Global Monthly Hydro. Analyses
Spatial Resolution: 1 degree
Standard Depths: 0, 10, 20, 30, 50, 75, 100, 125, 150, 200,
250, 300, 400, 500, 600, 700, 800, 900, 1000 m.
Parameters: temperature
9. NODC Global Seasonal 5o Hydro. Statistics
Standard Depths: 0, 10, 20, 30, 50, 75, 100, 125, 150, 200,
250, 300, 400, 500, 600, 700, 800, 900, 1000, 1100, 1200,
1300, 1400, 1500, 1750, 2000, 2500, 3000, 3500, 4000 m.
Parameters: temperature, salinity, dissolved oxygen, %
dissolved oxygen saturation, potential density, specific
volume.
Statistics: number of observations, mean, std. deviation.
10. Hellerman Wind Stress Climatology
2-degree resolution, global ocean, monthly mean
11. European Center for Medium Range Weather Forecasts (ECMWF)
Products.
Period: 01/01/80-12/31/87
Temporal/Spatial Resolution: 12hr/2.5 degrees
Spatial Coverage: Global
Parameters: geopotential height, temperature, wind velocity
(all three components), humidity, 8-yr monthly climatology.
Pressure levels (mb): 100, 200, 300, 500, 700, 850, 1000.
12. NMC Atmospheric Pressure Data (from CD-ROM)
Temporal Resolution: Daily and monthly means
Spatial Resolution: 4o x 7o
Coverage: Global
Period: 1973-1985 (daily), 1973-1984 (monthly means)
Parameters: Sea level pressure (daily)
Pressure, height and temperature @ surface,
850mb, 700mb, 500mb and 200mb (monthly means)
13. GALE (Genesis of Atlantic Lows Experiment
Period: 1/02/86 to 4/02/86
Coverage: 40W-90W, 25N-60N
Parameters: (B) gridded SST analyses: 14 km res., 30N-46N,
60W-80W, SST, SST anamaly, # of obs., 3-4 day
coverage.
14. NODC Pacific temperature and salinity profiles (on CD-ROM)
Coverage: Pacific, Atlantic, Polar and Indian Oceans
Parameters: temperature and salinity, 10o statistics (8
quantities.
Data Types: Nansen cast, XBT, MBT, IBT (radio message bt), SBT
(selected level bt), C/STD.
15. FNOC Mixed Layer Depth Product
Period: 12/88-present
Temporal Resolution: Daily
Spatial Resolution: Polar Stereographic grids
Northern Hemi.: 12/1/88-7/19/89 (5.7ox2.85o)
7/20/89-present (2.9ox1.4o)
Southern Hemi.: 12/1/88-7/19/89 (5.7ox2.85o)
16. COADS/ICE SST Climatology
Period: 1950-1979
Temporal Resolution: Monthly climatologies (30-yr means).
Spatial Resolution: 2o
17. Trenberth Surface Wind Stress Products
(derived from ECMWF 1000mb winds)
Temporal Resolution: Monthly climatology
Spatial Resolution: 2.5o x 2.5o
Coverage: Global
Period: 7/1/76-6/30/86
Parameters: Wind stress, wind stress curl, Sverdrup transport
18. Hsiung Heat Flux Climatology
Temporal Resolution: Monthly
Spatial Resolution: 5o
Coverage: 67.5N - 47.5S, global in longitude
Parameters: Latent heat flux, sensible heat flux, outgoing
radiation, incoming radiation, net energy flux (all at 72
levels from 0-2900 meters.
19. Miami Global SST Fields
Temporal Resolution: Weekly, Daytime and Nighttime
Spatial Resolution: 18 km
Coverage: Global
Period: 9/24/86-6/27/89, update 9/27{?}/81-3/8/90
Parameters: SST, number of observations
20. SMMR Monthly Mean Antarctic Sea Ice Concentration
Spatial Resolution: variable (South Polar Stereographic Proj.)
Period: 11/78-8/87
Parameters: Mean sea ice concentration
21. Florida State University Indian Ocean Wind Pseudo Stress
1. Temporal Resolution: Monthly climatology
Spatial Resolution: 1.0o x 1.0o
Coverage: Indian Ocean (31.5S - 25.5N Latitude/28.5E -
121.5E Longitude)
Period: 1/79-12/82
Parameters: Wind stress (derived and pseudo)
2. Temporal Resolution: Monthly climatology
Spatial Resolution: 1.0o x 1.0o
Coverage: Indian Ocean (29.5S - 23.5N Latitude/30.5E -
119.5E Longitude)
Period: 1/77-12/88
Parameters: Wind stress (derived and pseudo)
3. Temporal Resolution: Monthly climatology
Spatial Resolution: 2.0o x 2.0o
Coverage: Pacific Ocean (27S - 31N Latitude/124E - 70W
Longitude)
Period: 1/61-12/88
Parameters: Wind stress (derived and pseudo)
22. Oberhuber Heat Flux Climatology (COADS)
Period: 1/50-12/79
Spatial Resolution: 2.0 degrees
Parameters: Surface air temp., ocean mixed-layer temp.,
precip., surface rel. humidity, cloud cover, wind speed, wind
speed std. dev., sea surface pressure, salinity, abs. sw rad.,
outgoing lw rad., net rad. budget, latent heat flux, sensible
heat flux, net down. heat flux, net freshwater flux, bouyancy
flux, frictional vel., Newtonian cooling, latent heat trans.
coefficient.
23. TOGA Sea Level Time Series
Temporal Resolution: Hourly, Daily, and Monthly
Period: Hourly: 1/73-12/89
Daily: 1/57-12/89
Monthly: 1/57-12/89
Spatial Resolution: 94 stations
Coverage: Tropical Pacific
Parameters: Sea level (hourly, daily mean, monthly mean)
24. TOGA ECMWF Surface and 1000mb Analyses
Temporal Resolution: 12 Hour
Spatial Resolution: 2.5o x 2.5o
Coverage: Global
Period: 1/85-12/89
Parameters:
1000mb: Temperature, U and V wind components,
Relative humidity
Surface: Temperature (surface and 2m), Dewpoint (2m),
U and V wind components (Surface and 10m), Land/Sea
flag, Pressure, Relative humidity
25. TOGA-TAO mooring data
Temporal Resolution: daily mean
Spatial Resolution: 20 moorings
Coverage: tropical Pacific
Period: 11/28/84-3/29/90
Parameters:
Subsurface: Temperature, Depth
Surface: Air temperature, U and V wind components
26. Ocean Weather Ship Data Set
Resolution: 3 hour
Periods: Variable
Locations:
A: 62N/35W
B: 56.5N/51W
C: 52.75N/35.5W
D: 44N,41W
E: 35N,48W
F: 37N,41W
G: 45.9N,31.6W
H: 33N,70W
I: 59N,19W
J: 52.5N,20W
K: 45N/16W
L: 66N/2E
N: 30N/140W
P: 50N/145W
R: 47N/17W
T: 29N/135E
V: 34N/164E
X: 39N/153E
Parameters: SST, number of observations, wind direction,
windspeed, pressure, air temperature, dew point tempera-
ture, cloud amountt, wave height, precipitation
27. ERICA data set
Satellite SST products
1. Period: 11/23/88-3/19/89
Location: 30o-46o,60o-82oW
Temporal Resolution: 2/week
Spatial Resolution: 0.125o
Parameters: SST
2. Period: 11/15/88-3/25/89
Location: 5o-53oN,52o-100oW
Temporal Resolution: 2/week
Spatial Resolution: 0.5o
Parameters: SST
28. Bidston global sea-level data set
Period: 1/1807-12/1990
Location: >1300 stations
Temporal Resolution: hourly to daily
Parameters: platform name, country, quality flag, lat/long,
flatform type, annual mean, monthly mean, reference year,
sampling frequency, start year, stop year, total years
29. Levitus Nutrient Climatology
Location: Global
Spatial Resolution: 1o
Standard Depths: 0, 10, 20, 30, 50, 75, 100, 125, 150, 200,
250, 300, 400, 500, 600, 700, 800, 900, 1000, 1100, 1200,
1300, 1400, 1500, 1750, 2000, 2500, 3000, 3500, 4000, 4500,
5000, 5500 m.
Parameters: phosphate, nitrate, silicate
30. Australian Meteorological Data
Temporal Resolution: Monthly
Spatial Resolution: Variable
Coverage: Southern Hemisphere
Period: 1/77-2/90
Parameters: u,v surface components (1000mb)
31. TOGA Buoy-GEOSAT match-up data set
Period: 11/86-6/89
Location: tropical Pacific
Parameters-Buoy: buoy-id, anemometer height, wind speed,
wind direction, significant wave height, wave period,
sst, air temperature, sea level pressure
Parameters-Geosat: number of footprints/match-up, attitude,
wind speed, waveheight, footprint distance from buoy,
number of observations.
32. NODC Southern Ocean Atlas
Spatial Coverage: 30S-80S, 180W-180E, 1 (lat.) x 2 (lon.), 47
standard levels (0 - 9500 m).
Parameters: depth, temperature, salinity, sigma-t, oxygen,
silicate, phosphate, nitrate.
netcdf-hdf archives: