NCEI NetCDF Templates v2.0
The NOAA National Centers for Environmental Information (NCEI) have developed netCDF templates based on what are called "feature types" by Unidata and CF. These templates conform to Unidata's netCDF Attribute Convention for Dataset Discovery (ACDD) and netCDF Climate and Forecast (CF) conventions. Adding to these established conventions, NCEI also provides several recommendations for both netCDF variables and attributes. These best practices capture NCEI's experience in providing long-term preservation, scientific quality control, product development, and multiple data re-use beyond its original intent.
These templates are intended as a service to our community of Data Producers, and are also being used internally at NCEI in our own data development efforts. We hope the templates will serve as good starting points for Data Producers who wish to create preservable, discoverable, accessible, and interoperable data. It is important to note that these templates do not represent an attempt to create a new standard, and they are not absolutely required for archiving data at NCEI. However, we do hope that you will see the benefits in structuring your data following these conventions and NCEI stands ready to assist you in doing so.
NCEI NetCDF Template Guide
|v2.0||2015-12-07||New template for swath data
Updated attributes to conform to ACDD 1.3
Updated guidance table
Minor corrections and improvements
We welcome your comments, questions, and any suggestions you might have for recommended attributes. Please submit your concerns to: NCEI.NetCDF@noaa.gov - we will evaluate any feedback received and will update the templates as needed, likely on an annual basis for the next few years and then less frequently thereafter.
Key principles to keep in mind while using the templates
A few key "principles" appear to be emerging based on initial use of these templates:
- Be explicit! Do your best to provide accurate values for the attributes, and if you don't know them, state that clearly. Avoid "NA" or "N/A" as they can have multiple meanings.
- Keep your attributes focused on the content of the file, not the overall collection to which it might belong. For broader information about the collection, consider providing an FGDC or an ISO 19115-2 (preferred by NCEI) metadata record.
- Also remember that ACDD and CF tend to focus on what are sometimes known as "discovery" and "use" metadata. Basically, this kind of information focuses on helping you find the file, then using it in your application. The attributes don't try to capture every possible detail of the provenance or processing of the data, for example. Again, for richer information your best bet is to look to ISO 19115-2 as your metadata transfer standard.
- Our templates don't try to cover every possibility. We focused on the templates that we felt would cover most situations involving environmental observations, primarily of the ocean. If your situation doesn't match one of the templates, that is okay! Just use as much of the templates as you can and consider using some of the more complicated representations detailed in the full CF documentation.
As we move forward we will refine our thinking about these "principles" and look at ways they may help us to better explain how to implement these templates for specific data projects.
Background on CF Feature Types
The netCDF conventions identify eight feature types, each one describing a way of storing environmental data. These feature types are not based on the kind of observing system, instrument type, or variable collected. Instead, they are based on fundamental relationships among the spatiotemporal coordinates. This approach allows for CF to provide appropriate standards for representing very nearly all kinds of environmental observations. Six of these are known as "discrete sampling geometries" or "point observation types". These are supplemented by the swath and grid feature types used for non-discrete data.
For most of the discrete sampling geometries, the relationship between the data can be categorized in two ways:
- The first representation is referred to as an Orthogonal Multidimensional Array representation, in which variables of a dataset contain identical coordinate values along an axis. An example could be the vertical coordinates of variables measured on moored buoys with identical depth levels . The depth coordinate variable would store the array of the identical depth levels from the buoys. Therefore, if the depth levels for the first buoy are [5,10,15, 20] and the second buoy are [5,10,15,20,25], then the depth coordinate variable Z in the Orthogonal Multidimensional Array representation would be a single dimensional array Z = [5,10,15,20,25], and data value for the first buoy at z = 25 would be marked as a missing value.
- The second representation is referred to as the Incomplete Multidimensional Array representation. This representation is used when the variables of a dataset contain different coordinate values along an axis. This is a useful approach, for example, if multiple XBT profiles with different vertical resolution or levels are to be stored in the same netCDF file. A variable would need to be generated that would act as an indexed array to the depth levels of all the profiles combined. For example, if the depth levels for the first XBT are [11, 23, 35, 47, 59] and for the second XBT are [12, 24, 36, 48, 50, 61, 65], then the new depth variable containing data from both the XBTs would be two dimensional array Z = [[11, 23, 35, 47, 59, _, _] [12, 24, 36, 48, 50, 61]] where "_" is a missing value, and the data values for the first XBT would be padded with missing values for indices i = 5 & i = 6.
Apart from Orthogonal multidimensional array and incomplete multidimensional array, CF allows two additional methods of packing data in an array – contiguous ragged array and indexed ragged array. While there are benefits to using these representations over multidimensional array representations, they are generally more complex. Multidimensional representations can instead be used in all the cases where these representations could be used, but are space inefficient. Where the storage efficiency is important, contiguous ragged array representation could be used instead. In this version, we have chosen to focus on the multidimensional array approaches. We wanted to start with the simplest representations first that we believe will handle most of the data that we receive at NCEI, and then move to more complex representations. Later versions of the templates might include the contiguous ragged array representation. So, if you feel that ragged arrays are the more appropriate way to represent your data then please feel free to use them.
A Word on netCDF Versions and Data Models
While CF does not assume the usage of netCDF as the underlying choice of data format being used, netCDF is a highly recommended format. Within netCDF, there are two broad versions – netCDF 3 and netCDF 4. NetCDF-3 implements netCDF classic data model and netCDF-4 implements both classic and enhanced data models. NCEI recommends the use of netCDF-4, classic data model. The ability to internally compress or "chunk" data in netCDF-4 is a significant advantage over netCDF-3, especially for larger files. Chunking and internal compression allow for typically much faster access to the contents of the file, since only the relevant parts need to be decompressed. The best chunking and compression parameters for given a dataset is highly usage dependent. It is recommended that data creator play with different choices of the parameters before deciding on a good set of parameters. The classic data model does not take advantage of new features in the netCDF-4 enhanced data model, in particular the ability to use what are known as "groups" and "structures". These can be very useful features but we have found that many applications can not yet take advantage of them and the CF conventions have not yet incorporated them. So, our current approach could be phrased like this: "Start with netCDF-4 classic data model. If it works for your data, then you are all set and your files will be immediately useful in a wide range of applications. If you find yourself making too many concessions, or can see that groups or structures would greatly simplify your data, then go ahead and use them. Eventually the applications and conventions will catch up."
Decision Tree for Selecting the Right Template for Your Data
Please refer to our Feature Type Decision Tree if you are unsure of which template to use. The decision tree is designed to get you to the right template by asking a few yes/no questions.
Feature Type Templates and Examples
The table below lists the 8 feature types and provides templates for 13 of the 14 most common combinations of feature type (point, profile, etc.) and array representation (orthogonal, incomplete) expected for oceanographic observations. We are waiting on conclusions of the CF-satellite group before publishing a swath template and examples. The table provides the templates themselves in the "CDL Template" column. For many of the templates, we have one or more real-world examples as well. The CDL representations of those examples are listed in the "Specific CDL Examples" column, and links to the corresponding netCDF files on the NCEI THREDDS Data Server (TDS) are in the last column on the right. Following those links, you can explore the numerous services the TDS provides.
|Feature Type||Description||General Ocean Data Examples||CDL Template||Specific CDL Examples||Specific Examples on NCEI THREDDS Data Server|
|point||A single data point (having no implied coordinate relationship to other points).||One or more recorded observations that have no temporal or spatial relationship (where each observation equals one point in time and space).||Point||No example CDL available.||No netCDF file on NCEI TDS available.|
|timeSeries||A series of data points at the same spatial location with monotonically increasing times.||Sea Surface Temperature from one or more fixed platforms with the exact same increasing time intervals.||Orthogonal||No example CDL available.||No netCDF file on NCEI TDS available.|
|Multiple platforms collecting observations at different time intervals.||Incomplete||No example CDL available.||No netCDF file on NCEI TDS available.|
|trajectory||A series of data points along a path through space with monotonically increasing times.||One or more events where an underway platform collected data from a thermosalinograph.||Incomplete||No example CDL available.||No netCDF file on NCEI TDS available.|
|profile||An ordered set of data points along a vertical line at a fixed horizontal position and fixed time.||One or more CTD or XBT casts that have the exact same depth (z) values (do not need to have the same number of depth levels).||Orthogonal||No example CDL available.||No netCDF file on NCEI TDS available.|
|Multiple CTD or XBT casts that do not have the exact same depth (z) values.||Incomplete||No example CDL available.||No netCDF file on NCEI TDS available.|
|timeSeriesProfile||A series of profile features at the same horizontal position with monotonically increasing times.||Single or multiple mooring lines with stationary instruments at the same depths across all the mooring lines and all the instruments measuring at the same points in time.||Orthogonal Time and Depth||No example CDL available.||No netCDF file on NCEI TDS available.|
|Multiple mooring lines with stationary instruments at different depths across the mooring lines but all the instruments measuring at the same points in time.||Orthogonal Time and Incomplete Depth||No example CDL available.||No netCDF file on NCEI TDS available.|
|Multiple mooring lines with stationary instruments at the same depth across all the mooring lines but the instruments measuring at different points in time.||Incomplete Time and Orthogonal Depth||No example CDL available.||No netCDF file on NCEI TDS available.|
|Multiple mooring lines with stationary instruments at different depths across the mooring lines and the instruments measuring at different points in time.||Incomplete Time and Depth||No example CDL available.||No netCDF file on NCEI TDS available.|
|trajectoryProfile||A series of profile features located at points ordered along a trajectory.||Undulating gliders, Argo floats||Orthogonal||No example CDL available.||No netCDF file on NCEI TDS available.|
|Incomplete||No example CDL available.||No netCDF file on NCEI TDS available.|
|swath||An array of data in "sensor coordinates".||Level 2 polar-orbiting satellite data||Swath||No example CDL available.||No netCDF file on NCEI TDS available.|
|grid||Data represented or projected on a regular or irregular grid.||1-degree resolution salinity analysis product||Grid||No example CDL available.||No netCDF file on NCEI TDS available.|
Standard Attributes and Guidance Table
The table below lists the global and variable-level attributes recommended and required by the ACDD and CF conventions, with a very small number of additional NCEI recommended attributes. For many of the attributes, we also provide advice and guidance on what information should be put into those attributes. You can also refer directly to the guidance of ACDD and CF for definitions.
|Attribute||Convention||Global / Variable||Format||Description||NCEI Recommended Use and Comments|
|acknowledgment||ACDD||global||string||A place to acknowledge various types of support for the project that produced this data.||Please identify the funding agency and proposal number.|
|cdm_data_type||ACDD||global||string||The data type, as derived from Unidata's Common Data Model Scientific Data types and understood by THREDDS. The current choices are: Grid, Image, Point, Radial, Station, Swath, and Trajectory.||These data types do not map equally to the CF feature types. If the CF feature type = Trajectory Time Series, use "Trajectory"; if Profile, or Time Series Profile, use "Station", if Point, use "Point".|
|comment||ACDD/CF||global / variable||string||Miscellaneous information about the data or methods used to produce it. This attribute is defined in the CF Conventions.||Note the difference between comment and long_name for a variable: While long_name is intended for a phrase or a one line description of what the data represents, comment could be much longer and is intended to provide in greater detail any miscellaneous information important to interpret the data.|
|contributor_name||ACDD||global||string||The name of any individuals, projects, or institutions that contributed to the creation of this data. May be presented as free text, or in a structured format compatible with conversion to ncML (e.g., insensitive to changes in whitespace, including end-of-line characters).||Note that there is also an attribute called creator_name. This can have multiple comma separated values.|
|contributor_role||The role of any individuals, projects, or institutions that contributed to the creation of this data. May be presented as free text, or in a structured format compatible with conversion to ncML (e.g., insensitive to changes in whitespace, including end-of-line characters). Multiple roles should be presented in the same order and number as the names in contributor_names.||Please follow the guidance in the Description.|
|Conventions||ACDD/NUG||global||string||A comma-separated list of the conventions that are followed by the dataset.||This attribute is described in the NetCDF Users Guide. Try to use the most recent version of the CF convention. Currently, it is "CF-1.6". For files that follow this version of ACDD, include the string 'ACDD-1.3'.|
|coverage_content_type||ACDD||variable||string||An ISO 19115-1 code to indicate the source of the data (image, thematicClassification, physicalMeasurement, auxiliaryInformation, qualityInformation, referenceInformation, modelResult, or coordinate).|
|creator_email||ACDD||global||string||The email address of the person (or other creator type specified by the creator_type attribute) principally responsible for creating this data.||The information may be found in the NCEI Ocean Archive System database (http://www.nodc.noaa.gov/cgi-bin/OAS/prd/person). Other sources may be used as applicable.|
|creator_institution||The institution of the creator; should uniquely identify the creator's institution. This attribute's value should be specified even if it matches the value of publisher_institution, or if creator_type is institution.||The information may be found in the NCEI Ocean Archive System database (http://www.nodc.noaa.gov/cgi-bin/OAS/prd/institution). Other sources such as GCMD may be used as applicable (http://gcmdservices.gsfc.nasa.gov/static/kms/providers/providers.csv).|
|creator_name||The name of the person (or other creator type specified by the creator_type attribute) principally responsible for creating this data.||The information may be found in the NCEI Ocean Archive System database (http://www.nodc.noaa.gov/cgi-bin/OAS/prd/person). Other sources may be used as applicable.|
|creator_type||Specifies type of creator with one of the following: 'person', 'group', 'institution', or 'position'. If this attribute is not specified, the creator is assumed to be a person.|
|creator_url||The URL of the person (or other creator type specified by the creator_type attribute) principally responsible for creating this data.||The information may be found in the NCEI Ocean Archive System database (http://www.nodc.noaa.gov/cgi-bin/OAS/prd/institution or http://www.nodc.noaa.gov/cgi-bin/OAS/prd/person) tables. Other sources such as GCMD may be used as applicable (http://gcmdservices.gsfc.nasa.gov/static/kms/providers/providers.csv).|
|date_created||ACDD||global||string||The date on which this version of the data was created. (Modification of values implies a new version, hence this would be assigned the date of the most recent values modification.) Metadata changes are not considered when assigning the date_created. The ISO 8601:2004 extended date format is recommended, as described in the Attribute Content Guidance section.||Please follow the guidance in the Description.|
|date_issued||The date on which this data (including all modifications) was formally issued (i.e., made available to a wider audience). Note that these apply just to the data, not the metadata. The ISO 8601:2004 extended date format is recommended, as described in the Attributes Content Guidance section.|
|date_metadata_modified||The date on which the metadata was last modified. The ISO 8601:2004 extended date format is recommended, as described in the Attributes Content Guidance section.|
|date_modified||The date on which the data was last modified. Note that this applies just to the data, not the metadata. The ISO 8601:2004 extended date format is recommended, as described in the Attributes Content Guidance section.||In an archive generally a file is never modified, another version might be created instead. In such cases, date_modified is redundant and could be same as date_created.|
|geospatial_bounds||ACDD||global||string||Describes the data's 2D or 3D geospatial extent in OGC's Well-Known Text (WKT) Geometry format (reference the OGC Simple Feature Access (SFA) specification). The meaning and order of values for each point's coordinates depends on the coordinate reference system (CRS). The ACDD default is 2D geometry in the EPSG:4326 coordinate reference system.||The default may be overridden with geospatial_bounds_crs and geospatial_bounds_vertical_crs (see those attributes). EPSG:4326 coordinate values are latitude (decimal degrees_north) and longitude (decimal degrees_east), in that order. Longitude values in the default case are limited to the [-180, 180) range. Example: 'POLYGON ((40.26 -111.29, 41.26 -111.29, 41.26 -110.29, 40.26 -110.29, 40.26 -111.29))'.|
|geospatial_bounds_crs||ACDD||global||string||The coordinate reference system (CRS) of the point coordinates in the geospatial_bounds attribute. This CRS may be 2-dimensional or 3-dimensional, but together with geospatial_bounds_vertical_crs, if that attribute is supplied, must match the dimensionality, order, and meaning of point coordinate values in the geospatial_bounds attribute.||If geospatial_bounds_vertical_crs is also present then this attribute must only specify a 2D CRS. EPSG CRSs are strongly recommended. If this attribute is not specified, the CRS is assumed to be EPSG:4326. Examples: 'EPSG:4979' (the 3D WGS84 CRS), 'EPSG:4047'.|
|geospatial_bounds_vertical_crs||ACDD||global||string||The vertical coordinate reference system (CRS) for the Z axis of the point coordinates in the geospatial_bounds attribute. This attribute cannot be used if the CRS in geospatial_bounds_crs is 3-dimensional; to use this attribute, geospatial_bounds_crs must exist and specify a 2D CRS. EPSG CRSs are strongly recommended.||There is no default for this attribute when not specified. Examples: 'EPSG:5829' (instantaneous height above sea level), "EPSG:5831" (instantaneous depth below sea level), or 'EPSG:5703' (NAVD88 height).|
|geospatial_lat_min||ACDD||global||float||These attributes define the latitude and longitude coordinates of the bounding box of the data set; may be part of a 2- or 3-dimensional bounding region.||Report the latitude coordinates in decimal degrees north (south is negative). These values should be given in WGS 84 coordinate system. If the data is in a projected coordinate system, the bounding box for the data should be mapped to a bounding box on WGS 84 ellipsoid.|
|geospatial_lat_units||ACDD||global||string||This attribute defines the units applied to the geospatial_lat_min and geospatial_lat_max attributes.||CF recommends the units should be "degrees_north". Regardless of what is used, it must conform to udunits (http://www.unidata.ucar.edu/software/udunits/).|
|geospatial_lat_resolution||ACDD||global||string||Information about the targeted spacing of points in latitude. Recommend describing resolution as a number value followed by the units. Does not apply to discrete sampling geometries (non-gridded data). Not to be confused with measurement resolution.||Examples: '100 meters', '0.1 degree'|
|geospatial_lon_units||ACDD||global||string||This attribute defines the units applied to the geospatial_lon_min and geospatial_lon_max attributes.||CF recommends the units should be "degrees_east". Regardless of what is used, it must conform to udunits (http://www.unidata.ucar.edu/software/udunits/).|
|geospatial_lon_resolution||ACDD||global||string||Information about the targeted spacing of points in longitude. Recommend describing resolution as a number value followed by units. Does not apply to discrete sampling geometries (non-gridded data). Not to be confused with measurement resolution.||Examples: '100 meters', '0.1 degree'|
|geospatial_vertical_min||ACDD||global||float||These attributes define the numerically smallest and largest highest vertical measurements of the data set's bounding box; may be part of a 2- or 3-dimensional bounding region.|
|geospatial_vertical_units||ACDD||global||string||This defines the units applied to the geospatial_vertical_min and geospatial_vertical_max attributes.||The default is EPSG:4979 (height above the ellipsoid, in meters); other vertical coordinate reference systems may be specified. Note that the common oceanographic practice of using pressure for a vertical coordinate, while not strictly a depth, can be specified using the unit bar. Examples: 'EPSG:5829' (instantaneous height above sea level), 'EPSG:5831' (instantaneous depth below sea level).|
|geospatial_vertical_resolution||ACDD||global||string||Information about the targeted regular vertical spacing of points.||Example: '25 meters'|
|geospatial_vertical_positive||ACDD||global||string||One of 'up' or 'down'. If up, vertical values are interpreted as 'altitude', with negative values corresponding to below the reference datum (e.g., under water). If down, vertical values are interpreted as 'depth', positive values correspond to below the reference datum.||Note that if geospatial_vertical_positive is down ('depth' orientation), the geospatial_vertical_min attribute specifies the data's vertical location furthest from the earth's center, and the geospatial_vertical_max attribute specifies the location closest to the earth's center.|
|history||ACDD/NUG||global||string||Provides an audit trail for modifications to the original data. This attribute is also in the NetCDF Users Guide: 'This is a character array with a line for each invocation of a program that has modified the dataset. Well-behaved generic netCDF applications should append a line containing: date, time of day, user name, program name and command arguments.' To include a more complete description you can append a reference to an ISO Lineage entity; see NOAA EDM ISO Lineage guidance||This attribute is meant to give provenance of the data. The user should be able to trace the origin of the raw data and all the intermediate modifications which the data has gone through before reaching her/him. Any changes made to the file should be tracked here. (For example: "2010-06-09; previous version's uuid; added attributes for the calibration coefficients to the depth variable.")|
|id||ACDD||global||string||An identifier for the data set, provided by and unique within its naming authority. The combination of the "naming authority" and the "id" should be globally unique, but the id can be globally unique by itself also. IDs can be URLs, URNs, DOIs, meaningful text strings, a local key, or any other unique string of characters. The id should not include white space characters.||Use any combination of alpha-numeric digits or words that make this data set unique in relation to the naming authority.|
|institution||ACDD/CF||global||string||The name of the institution principally responsible for originating this data. This attribute is recommended by the CF convention.||The information may be found in the NCEI Ocean Archive System database (http://www.nodc.noaa.gov/cgi-bin/OAS/prd/institution). Other sources such as GCMD may be used as applicable (http://gcmdservices.gsfc.nasa.gov/static/kms/providers/providers.csv).|
|instrument||ACDD/NCEI||global / variable||string||If using as a global attribute: Name of the contributing instrument(s) or sensor(s) used to create this data set or product. Indicate controlled vocabulary used in instrument_vocabulary.
If using as a variable attribute: This attribute can be used with a geophysical variable to identify the instrument that collected the data.The value of the attribute should be set to another variable which contains the details of the instrument. There can be multiple instruments involved depending on if all the instances of the featureType in the collection come from the same instrument or not. If multiple instruments are involved, a variable should be defined for each instrument and referenced from the geophysical variable in a comma separated string. NCEI recommends the use of the following attributes for those instrument variables: make_model, serial_number, calibration_date, factory_calibrated, user_calibrated, calibration_report, accuracy, valid_range, and precision.
|The information may be found in the NCEI Ocean Archive System database (http://www.nodc.noaa.gov/cgi-bin/OAS/prd/insttype). Other sources such as GCMD may be used as applicable (http://gcmdservices.gsfc.nasa.gov/static/kms/instruments/instruments.csv).|
|instrument_vocabulary||ACDD||global||string||Controlled vocabulary for the names used in the "instrument" attribute.||The information may be found in the NCEI Ocean Archive System database (http://www.nodc.noaa.gov/cgi-bin/OAS/prd/insttype). Other sources such as GCMD may be used as applicable (http://gcmdservices.gsfc.nasa.gov/static/kms/instruments/instruments.csv).|
|keywords||ACDD||global||string||A comma separated list of keywords and phrases.||keywords should be specified in the vocabulary mentioned in the attribute keywords_vocabulary.|
|keywords_vocabulary||ACDD||global||string||Identifies the controlled list of keywords from which the values in the "keywords" attribute are taken.||Good choices include: GCMD Science Keywords Version 8.1, CF Standard Names, ISO Topic Categories, NCEI Data Types, NCEI Observation Types.|
|license||ACDD||global||string||Describe the restrictions to data access and distribution.||NCEI strongly recommends that all data submitted to NCEI for archiving be freely and openly available without restriction. We suggest you set this attribute to "These data may be redistributed and used without restriction."|
|long_name||ACDD/CF/NUG/COARDS||variable||string||A long descriptive name for the variable (not necessarily from a controlled vocabulary). This attribute is recommended by the NetCDF Users Guide, the COARDS convention, and the CF convention.||Often long_name is used as the title of an image, a graph or title of an axis when showing the data graphically. Try not to put too much here. Use comment if you want to be more elaborate.|
|metadata_link||ACDD||global||string||This attribute provides a link to a complete metadata record for this dataset or the collection that contains this dataset. This attribute is not included in Version 1 of the Unidata Attribute Convention for Data Discovery and is also a proposed attribute. It is recommended here because a complete metadata collection for a dataset will likely contain more information than can be included in granule formats. This attribute contains a link to that information.|
|naming_authority||ACDD||global||string||The combination of the "naming authority" and the "id" should be a globally unique identifier for the dataset.||Recommend using the reverse URL of the institution. (e.g., gov.noaa.ncei)|
|platform||ACDD/NCEI||global / variable||string||If using as a global attribute: Name of the platform(s) that supported the sensor data used to create this data set or product. Platforms can be of any type, including satellite, ship, station, aircraft or other. Indicate controlled vocabulary used in platform_vocabulary.
If using as a variable attribute:This attribute can be used with a geophysical variable to identify the platform that was used in the collection of the data. The value of the attribute should be set to another variable which contains the details of the platform. There can be multiple platforms involved depending on if all the instances of the featureType in the collection share the same platform or not. If multiple platforms are involved, a variable should be defined for each platform and referenced from the geophysical variable in a comma separated string. NCEI recommends the use of the following attributes for those platform variables: call_sign, ices_code, wmo_code, and imo_code
|The information may be found in the NCEI Ocean Archive System database (http://www.nodc.noaa.gov/cgi-bin/OAS/prd/platform).
Other sources such as GCMD may be used as applicable (http://gcmdservices.gsfc.nasa.gov/static/kms/platforms/platforms.csv)
Information on WMO codes is available at http://www.wmo.int/pages/prog/amp/mmop/wmo-number-rules.html
We recommend you avoid using ambiguous phrases like "NA" or "N/A" which might mean different things (e.g., Not Applicable, or Not Available).
|platform_vocabulary||ACDD||global||string||Controlled vocabulary for the names used in the "platform" attribute.|
|processing_level||ACDD||global||string||A textual description of the processing (or quality control) level of the data.||This attribute should also identify the authority which defined the processing level along with the processing level itself. The processing levels defined by NOAA for satellite data can be found here: https://www.ngdc.noaa.gov/wiki/index.php?title=NOAA_Processing_Levels. Similar list for NASA data can be found here: http://science.nasa.gov/earth-science/earth-science-data/data-processing-levels-for-eosdis-data-products/.|
|product_version||ACDD||global||string||Version identifier of the data file or product as assigned by the data creator. For example, a new algorithm or methodology could result in a new product_version.|
|program||ACDD||global||string||The overarching program(s) of which the dataset is a part. A program consists of a set (or portfolio) of related and possibly interdependent projects that meet an overarching objective. Examples: 'GHRSST', 'NOAA CDR', 'NASA EOS', 'JPSS', 'GOES-R'.|
|project||ACDD||global||string||The name of the project(s) principally responsible for originating this data. Multiple projects can be separated by commas, as described under Attribute Content Guidelines. Examples: 'PATMOS-X', 'Extended Continental Shelf Project'.||The information may be found in the NCEI Ocean Archive System database (http://www.nodc.noaa.gov/cgi-bin/OAS/prd/project). Other sources such as GCMD may be used as applicable (http://gcmdservices.gsfc.nasa.gov/static/kms/projects/projects.csv).|
|publisher_email||ACDD||global||string||The email address of the person (or other entity specified by the publisher_type attribute) responsible for publishing the data file or product to users, with its current metadata and format.||Please follow the guidance in the Description.|
|publisher_institution||The institution that presented the data file or equivalent product to users; should uniquely identify the institution. If publisher_type is institution, this should have the same value as publisher_name.|
|publisher_name||The name of the person (or other entity specified by the publisher_type attribute) responsible for publishing the data file or product to users, with its current metadata and format.||Please follow the guidance in the Description.|
|publisher_type||ACDD||global||string||Specifies type of publisher with one of the following: 'person', 'group', 'institution', or 'position'. If this attribute is not specified, the publisher is assumed to be a person.|
|publisher_url||ACDD||global||string||The URL of the person (or other entity specified by the publisher_type attribute) responsible for publishing the data file or product to users, with its current metadata and format.||Please follow the guidance in the Description.|
|references||ACDD/CF||global / variable||string||Published or web-based references that describe the data or methods used to produce it. Recommend URIs (such as a URL or DOI) for papers or other references. This attribute is defined in the CF conventions.||This attribute should point to project web sites, published papers, and similar items.|
|source||ACDD/CF||global / variable||string||The method of production of the original data. If it was model-generated, source should name the model and its version. If it is observational, source should characterize it. This attribute is defined in the CF Conventions. Examples: 'temperature from CTD #1234'; 'world model v.0.1'.||Please follow the guidance in the Description.|
|standard_name||ACDD/CF||variable||string||A long descriptive name for the variable taken from a controlled vocabulary of variable names. We recommend using the CF convention and the variable names from the CF standard name table. This attribute is recommended by the CF convention.||Standardized field which uses the CF Standard Names (http://www.cfconventions.org/documents.html/). If a variables does not have an existing standard_name in the CF-managed list, this attribute should not be used. In these cases, a standard name can be proposed to the CF community for consideration and acceptance.|
|standard_name_vocabulary||ACDD||global||string||The name and version of the controlled vocabulary from which variable standard names are taken. (Values for any standard_name attribute must come from the CF Standard Names vocabulary for the data file or product to comply with CF.)||"Example: 'CF Standard Name Table v27'.|
|summary||ACDD||global||string||A paragraph describing the dataset, analogous to an abstract for a paper.||Write a paragraph or abstract about the data contained within the file, expanding on the title to provide more information.|
|time_coverage_start||ACDD||global||string||Describes the temporal coverage of the data as a time range. The temporal coverage of the data can be described with any of the following pairs of values: start/end, start/duration, or end/duration.||Use ISO 8601:2004 for date and time; preferably the extended format.|
|time_coverage_resolution||Describes the targeted time period between each value in the data set.||Use ISO 8601:2004; preferably the extended format. Examples: P1Y, P3M, P10D|
|title||ACDD/CF/NUG||global||string||A short phrase or sentence describing the dataset. In many discovery systems, the title will be displayed in the results list from a search, and therefore should be human readable and reasonable to display in a list of such names. This attribute is also recommended by the NetCDF Users Guide and the CF conventions.||Write one sentence that describes the scope of the data contained within the file; answer the five "W's": Who, What, Where, Why, When. Please use the following construction guidelines for creating a meaningful title for your netCDF file: Do not use all capitals or capitalize words other than proper nouns or widely used acronyms. Avoid using acronyms, especially for projects or organizations. If you feel you must include an acronym, spell out the meaning of the acronym then put the acronym in parentheses after the meaning. General construction guideline for data set title "Summary of variables and feature type" collected by instrument(s) from the platform(s) in the sea_name(s) from time_coverage_start to time_coverage_end;
Here are some good examples: a. Physical and chemical profile data from bottle and conductivity-temperature-depth (CTD) casts from the R/V Jere Chase in the Gulf of Maine from 1982 to 1984; b. Temperature and salinity trajectory data from thermosalinograph measurements from the R/V Jere Chase in the Gulf of Maine from 1982 to 1984;
A bad example would be: Temperature, Salinity and Chlorophyll Data from WADOE during NWCOP San Juan from the '80's.
|units||ACDD/CF/NUG/COARDS||variable||string||The units of the variable's data values. This attribute value should be a valid udunits string. The "units" attribute is recommended by the NetCDF Users Guide, the COARDS convention, and the CF convention.||Required for most all variables that represent dimensional quantities. The value should come from udunits (http://www.unidata.ucar.edu/software/udunits/) authoritative vocabulary, which is documented in the CF standard name table with it's corresponding standard name. The udunits package includes a file udunits.dat which lists its supported unit names.|
|add_offset||CF||variable||float/double||This attribute along with scale_factor is used for unpacking data or for converting the data to CF valid units. CF places a lot of restrictions on the use of these attributes. Please read the CF documentation for best practices. Should be the same datatype as the scale_factor.||Please follow the guidance in the Description.|
|ancillary_variables||CF||variable||string||This attribute can be used to associate two different variables with one another. This attribute is generally used to associate with the given geophysical variable another variable containing metadata about each value in the given geophysical variable. An example is the flag variables used to show the status of each value in the geophysical variable. The standard name for the ancillary variable could be standard name of the geophysical variable followed by standard name modifier. See the comments for an example.||Example:float temperature(z); temperature:standard_name="sea_water_temperature"; temperature:ancillary_variables="temperature_WODflag"; int temperature_WODflag(z); temperature_WODflag:standard_name="sea_water_temperature status_flag"; temperature_WODflag:flag_values="..."; temperature_WODflag:flag_meanings="...";|
|axis||CF||variable||char||This attribute is specifically for the variables time, latitude, longitude, and altitude when they are identified as the coordinate variables. The values of each variable coordinates axis are as follows: time = “T”, latitude = “Y”, longitude = “X”, and altitude = “Z”.||The axis attribute can only be attached to true, 1-D coordinate variables. If the true coordinates are X and Y (a projected coordinate system, for example), then the axis attribute is to be applied to those and not to the 2-D latitude and longitude auxiliary coordinate variables. If the X and Y coordinates are not included in the file, then no variable should have an 'X' or 'Y' axis attribute attached. Additionally, the 'Z' axis attribute can be applied to any 1-D coordinate variable that represents vertical position, such as depth or pressure.|
|bounds||CF||variable||string||Name of the variable which contains the vertices of the cell boundaries. This attribute must be present for all the coordinate variables which are used within cell_methods for representing non-point statistics.||It is important to have bounds for a geophysical coordinate variable if a geophysical variable is extensive along it.|
|calendar||CF||variable||string||This attribute is used to show the type of calendar used for representing dates within a netcdf file. The possible values are gregorian(default), proleptic_gregorian, all_leap, 360_day, julian, or none.||Please follow the guidance in the Description.|
|cell_measures||CF||variable||string||This attribute has the form "measure_type:variable_name" where measure_type could be one of the two: "area" or "volume" and variable_name holds the name of the variable holding the areas or volumes corresponding to the cells. This attribute is necessitated by the fact that the cell areas or volumes cannot be determined purely by the boundary points of the cells. One would have to know how they are connected, though it is common to assume great circle connectivity.||This attribute is not a required attribute.|
|cell_methods||CF||variable||string||Describes the characteristic of the field. This is a string attribute comprising a list of blank-separated words of the form "name: method", e.g. t: mean. The possible values for method are point, sum, maximum, median, mid_range, minimum, mean, mode, standard_deviation and variance. The possible values for name are dimension of the variable, a scalar coordinate variable, a valid standard name, or the word "area".||Multiple strings of this form could be repeated if more than one cell method is present. They would be arranged in the order they were applied. CF recommends use of cell_methods for each spatio-temporal dimension and each spatio-temporal scalar coordinate variable.|
|cf_role||CF||variable||string||Where feasible a variable with the attribute cf_role should be included. The only acceptable values of cf_role for Discrete Geometry CF data sets are "=station_id=", "=profile_id=", and "=trajectory_id=". The variable carrying the cf_role attribute may have any data type. When a variable is assigned this attribute, it must provide a unique identifier for each feature instance. CF files that contain timeSeries, profile or trajectory featureTypes, should include only a single occurrence of a cf_role attribute; CF files that contain timeSeriesProfile or trajectoryProfile may contain two occurrences, corresponding to the two levels of structure in these feature types.||The cf_role attribute should only be attached to a coordinated variable (See Appendix A ). In order for the CF Checker to determine that station_name is indeed a coordinate variable it must be listed as such in the "coordinates" attribute.|
|climatology||CF||variable||string||This attribute points to another variable containing climatological bounds. Climatological bounds are the starting and ending dates for each climatological interval.||Please follow the guidance in the Description.|
|compress||CF||variable||string||This attribute is used in order to achieve some compression of the data.||Please follow the guidance in the Description.|
|coordinates||CF||variable||string||This attribute contains a space separated list of all the coordinates corresponding to the variable.The list should contain all the auxiliary coordinate variables and optionally the coordinate variables.||Also, note that whenever any auxiliary coordinate variable contains a missing value, all other coordinate, auxiliary coordinate and data values corresponding to that element should also contain missing values.|
|flag_masks||CF||variable||same as type of the variable||(Comma-separated) Describes the binary condition of the flags.||The boolean conditions are identified by performing bitwide AND of the variable value and the flag_masks. For example, if the variable value is of type unsigned byte and equal to 5 and the flag_masks are 1b, 2b, 4b, 8b, 16b, 32b. The binary encoding of 5 is 00000101 and the binary encoding of the flags are 00000001, 00000010, 00000100, 00001000, 00010000, 00100000. Now bitwide AND of the value with the masks returns 00000001, 00000000, 00000100, 00000000, 00000000, 00000000 respectively or 1b,0,4b,0,0,0,0,0 in decimal. So the masks corresponding to 1b and 4b are "true", rest are "false". In this example, first two bits are not used. If the variable were 4b, the flag_mask corresponding to 4b would be "true" and rest would be "false".|
|flag_meanings||CF||variable||string||(Space-separated) Interpretation corresponding to each of the flag_values and/or flag_masks||CF allows a single variable to contain both flag_values and flag_masks. The interpretation of the flags in such cases is slightly tricky. In such cases flag_masks is used to "group" a set of flag_values into a nested conditional. Please see the example 3.5 in the CF document on how to interpret flag_meanings in such cases. NCEI recommends that boolean and enumerated flags be kept in separate variables.|
|flag_values||CF||variable||same as type of the variable||(Comma-separated) flag_values maps values in the variable to values in the flag_meanings in order to interpret the meanings of the values in the array.||Please follow the guidance in the Description.|
|_FillValue||CF||variable||same datatype as variable||This value is considered to be a special value that indicates undefined or missing data, and is returned when reading values that were not written.||CF does not allow fill values for coordinate variables (Note that, here coordinate variable is not same as geophysical coordinates, see below). If the geophysical coordinates in your dataset could have null values, coordinate variables (http://www.cfconventions.org/1.6.html#terminology) should be used to represent the geophysical coordinates.
Note that the term "coordinate variable" here is NOT used in the sense of geophysical coordinates. The term is defined in the netCDF users guide (section 2.3.1 (http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Variables)). It is a one-dimensional variable with the same name as its dimension [e.g., time(time)], and it is defined as a numeric data type with values that are ordered monotonically. Unfortunately, lot of terminology used by CF and netCDF interferes with the terminology used by scientists and has different meaning. Some examples - variable (netCDF variable or geophysical variable), coordinate variable (geophysical coordinate (lat, lon, depth, etc) or netCDF/CF coordinate variable), dimension (geophysical dimension or netCDF dimension), etc. Depending on the context, the reader should be careful to distinguish the subtle variation in the meaning of the terms used.
|grid_mapping||CF||variable||string||Describes the horizontal coordinate system used by the data. The grid_mapping attribute should point to a variable which would contain the parameters corresponding to the coordinate system. There are typically several parameters associated with each coordinate system. CF defines a separate attributes for each of the parameters. Some examples are "semi_major_axis", "inverse_flattening", "false_easting"||All the attributes within a grid_mapping variable are described in http://www.cfconventions.org/1.6.html#grid-mappings-and-projections. For all the measurements based on WSG84 which is the default coordinate system used for GPS measurements, the following parameters should be used: crs:grid_mapping_name = "latitude_longitude"; crs:longitude_of_prime_meridian = 0.0 ; crs:semi_major_axis = 6378137.0 ; crs:inverse_flattening = 298.257223563 ; Here "crs" represents the name of the variable pointed to by grid_mapping attribute.|
|missing_value||CF||variable||same datatype as variable||This attribute is not treated in any special way by generic applications, but is often useful documentation and may be used by specific applications. The missing_value attribute can be a scalar or vector containing values indicating conditions of missing data. These values should all be outside the valid range so that generic applications will treat them as missing.||When scale_factor and add_offset are used for packing, the value(s) of the missing_value attribute should be specified in the domain of the data in the file (the packed data), so that missing values can be detected before the scale_factor and add_offset are applied.|
|sample_dimension||CF||variable||string||An attribute which identifies a count variable and names the sample dimension to which it applies. The count variable indicates that the contiguous ragged array representation is being used for a collection of features.||Please follow the guidance in the Description.|
|scale_factor||CF||variable||float/double||This attribute along with add_offset is used for unpacking data or for converting the data to CF valid units. CF places a lot of restrictions on the use of these attributes. Please read the CF documentation for best practices. Should be the same datatype as add_offset||Note that the packed value is calculated from original value as follows: packedValue = (originalValue - add_offset)/scale_factor and NOT packedValue = (orginalValue/scale_factor) - add_offset|
|valid_max||CF||variable||same datatype as variable||Maximum possible value of a variable. Note that if the data values are packed with scale_factor and add_offset, these values are packed too.||Please follow the guidance in the Description.|
|valid_min||CF||variable||same datatype as variable||Minimum possible value of a variable. Note that if the data values are packed with scale_factor and add_offset, these values are packed too.||Please follow the guidance in the Description.|
|uuid||NCEI||global||string||Machine readable unique identifier for each netCDF file. A new uuid should be created whenever the netCDF file is changed. Review the history attribute listed below for further information about tracking older versions of the data file.
From Wikipedia: A UUID is a 16-byte (128-bit) number. The number of theoretically possible UUIDs is therefore about 3 × 1038. In its canonical form, a UUID consists of 32 hexadecimal digits, displayed in 5 groups separated by hyphens, in the form 8-4-4-4-12 for a total of 36 characters (32 digits and 4 hyphens). (e.g., 550e8400-e29b-41d4-a716-446655440000) http://en.wikipedia.org/wiki/Universally_unique_identifier
|Numerous tools exist to rapidly and easily create UUIDs. See the wiki page for a list.|
|sea_name||NCEI||global||string||The names of the sea in which the data were collected.||See the list of NCEI sea names here: NCEI Sea Names (http://www.nodc.noaa.gov/General/NODC-Archive/seanamelist.txt)|
|ncei_name||NCEI||variable||string||The NCEI controlled vocabulary name for the variable if different from the standard name attribute or the standard name attribute does not exist.||See the list of available NCEI data type names (http://www.nodc.noaa.gov/cgi-bin/OAS/prd/datatype).|
|ncei_template_version||NCEI||global||string||This attribute tracks the version of the feature type created by NCEI. (for example: ncei_template_version = "netCDF_single_trajectory_v2.0")||Please follow the guidance in the Description.|