NODC NetCDF Templates v1.0

Purpose

The NOAA National Oceanographic Data Center (NODC) has 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, NODC also provides several recommendations for both netCDF variables and attributes. These best practices capture NODC'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 NODC 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 NODC. However, we do hope that you will see the benefits in structuring your data following these conventions and NODC stands ready to assist you in doing so.

We welcome your comments, questions, and any suggestions you might have for recommended attributes. Please submit your concerns using the form at: https://docs.google.com/a/noaa.gov/spreadsheet/viewform?formkey=dDdWdEdBb2xOdVV3OXJjcmFFYjRBMXc6MQ#gid=0 - 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:

1. 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.
2. 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 NODC) metadata record.
3. Also remember that ACDD and CF tend to focus on what are sometimes know 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.
4. Our templates don't try to cover every possibility. We focused on the templates that we felt would cover most situations involving observations of the ocean. If your situation doesn't match one of the templates, that is ok! 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:

1. 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.
2. 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 NODC, 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. NODC 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 NODC 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 NODC 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	Kachemak Bay, NS and T Bioeffects Program Data	Kachemak Bay
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	Bodega Marine Lab Buoy	Bodega Marine Lab Buoy
		Multiple platforms collecting observations at different time intervals.	Incomplete	Bodega Marine Lab Buoy Combined	Bodega Marine Lab Buoy Combined
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	1. Okeanos Explorer SCS Data; 2. AOML TSG; 3. Jason-2 Altimeter Data	1. Okeanos Explorer SCS Data; 2. AOML TSG; 3. Jason-2 Altimeter Data
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	World Ocean Database Standard Level Data	World Ocean Database Standard Level Data
		Multiple CTD or XBT casts that do not have the exact same depth (z) values.	Incomplete	World Ocean Database Observed Level Data	World Ocean Database Observed Level Data
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	USGS Internal Wave Data	USGS Internal Wave Data
		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 NODC 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 NODC 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 NODC 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 NODC TDS available.
			Incomplete	No example CDL available.	No netCDF file on NODC TDS available.
swath	An array of data in "sensor coordinates".	Level 2 polar-orbiting satellite data	NODC is awaiting results of recent CF-satellite discussions before constructing a swath template and supporting examples.	No example CDL available.	No netCDF file on NODC TDS available.
grid	Data represented or projected on a regular or irregular grid.	1-degree resolution salinity analysis product	Grid	Pathfinder SST Climatology	Pathfinder SST Climtology

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 NODC 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	NODC Recommended Use and Comments
acknowledgment	ACDD	global	string	This optional free text field identifies the funding agency and other relevant information.	Please identify the funding agency and proposal number.
cdm_data_type	ACDD	global	string	This attribute is used by THREDDS to identify the feature type, what THREDDS calls a "dataType". The current choices are: Grid, Image, 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 Point, Profile, or Time Series Profile, use "Station".
comment	ACDD	global	string	Miscellaneous information about the data, that cannot be described in any of the other available attributes.	Note the difference bewteen 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 or institutions that contributed to the creation of this data. Please use commas to separate the names. When applicable, use the conventions described above when identifying persons and/or institutions.	Note that there is also an attribute called creator_name. This can have multiple comma seperated values.
contributor_role				The role of the individual or institution that contributed to the creation of this data. Ensure that the listed roles are comma separated and in the same order as listed in the contributor_name attribute.	Please follow the guidance in the Description
creator_email	ACDD	global	string	Email address of the person or institution that collected the data.	The email of the person or institution may be found in the NODC tables for persons(http://www.nodc.noaa.gov/cgi-bin/OAS/prd/person) and institutions(http://www.nodc.noaa.gov/cgi-bin/OAS/prd/institution). Use the short name of the institution if available.
creator_name				Name of the person who collected the data.	Use the name from the NODC persons(http://www.nodc.noaa.gov/cgi-bin/OAS/prd/person) table when applicable.
creator_url				The URL of the institution that collected the data.	The url of the institution can be found in the NODC institutions(http://www.nodc.noaa.gov/cgi-bin/OAS/prd/institution) table.
date_created	ACDD	global	string	The date or date and time when the file was created. Use ISO 8601 and give date or date and time in UTC (e.g., "yyyy-mm-dd" or "yyyy-mm-ddThh:mn:ssZ"). This time stamp will never change, even when modifying the file.	Please follow the guidance in the Description
date_modified				The date or date and time when the file was modified. Use ISO 8601 and give date or date and time in UTC (e.g., "yyyy-mm-dd" or "yyyy-mm-ddThh:mn:ssZ").This time stamp will change any time information is changed in this file.	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_lat_min	ACDD	global	float	These attributes define the latitude and longitude coordinates of the bounding box of the data set.	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_max
geospatial_lon_min
geospatial_lon_max
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	This attribute defines the resolution of the latitude coordinates.	For example, "point" or "10 degree grids".
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_north". Regardless of what is used, it must conform to udunits(http://www.unidata.ucar.edu/software/udunits/).
geospatial_lon_resolution	ACDD	global	string	This attribute defines the resolution of the longitude coordinates.	For example, "point" or "10 degree grids".
geospatial_vertical_min	ACDD	global	float	These attributes define the lowest and highest vertical measurements of the data set's bounding box.	These values should be given ideally with respect to WGS 84 ellipsoid.
geospatial_vertical_max
geospatial_vertical_units	ACDD	global	string	This defines the units applied to the geospatial_vertical_min and geospatial_vertical_max attributes.	Conform to udunits(http://www.unidata.ucar.edu/software/udunits/).
geospatial_vertical_resolution	ACDD	global	string	This defines the resolution of the vertical axis values.	Use the cell methods vocabulary in Appendix E(http://www.cfconventions.org/1.6.html#cell-methods) of the CF conventions.
geospatial_vertical_positive	ACDD	global	string	This attribute indicates which direction is positive (a value of "up" means that z increases up, like units of height, while a value of "down" means that z increases downward, like units of pressure or depth).	Select from "up" or "down".
history	ACDD	global	string	Any changes made to the file should be tracked here. (e.g., "2010-06-09; previous version's uuid; added attributes for the calibration coefficients to the depth variable.")	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.
id	ACDD	global	string	Unique identifier for the data set represented in the file. The combination of the "naming authority" and the "id" should be a globally unique identifier for the dataset.	Use any combination of alpha-numeric digits or words that make this data set unique in relation to the naming authority.
institution	ACDD	global	string	The institution of the person or group that collected the data.	Use the NODC institutions(http://www.nodc.noaa.gov/cgi-bin/OAS/prd/institution) name when applicable, selecting the short name if available.
keywords	ACDD	global	string	A comma separated list of key words 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: NODC Data Types, NODC Observation Types, GCMD Science Keywords Version 8.0, CF Standard Names, and ISO Topic Categories.
license	ACDD	global	string	Describe the restrictions to data access and distribution.	NODC strongly recommends that all data submitted to NODC 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."
Metadata_Conventions	ACDD*	global	string	This attribute should be set to "Unidata Dataset Discovery v1.0" or the most current version for netCDF files that follow this convention.	Note: be careful with the case here. It is indeed "Metadata_Conventions", with the capitalization. Most attributes are normally lower case. *Also note that this is a proposed attribute, and not yet officially part of ACDD.
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.	Note: This is a proposed attribute in ACDD. The latest version of the TDS "UDDC" service accepts either "Metadata_Link" or "metadata_link". NODC recommends the use of the lower case form to be more consistent with other attributes, which with only one or two exceptions are also lower case.
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.nodc)
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/ .
project	ACDD	global	string	The scientific project that the data was collected under.	Use the NODC projects (http://www.nodc.noaa.gov/cgi-bin/OAS/prd/project) name when applicable.
publisher_email	ACDD	global	string	The email address of the person or group that distributes the data files.	Please follow the guidance in the Description
publisher_name				Name of the person or group that distributes the data files. Use the conventions described above when identifying persons and/or institutions when applicable.	Please follow the guidance in the Description
publisher_url	ACDD	global	string	URL of the person or group that distributes the data files.	Please follow the guidance in the Description
standard_name_vocabulary	ACDD	global	string	The name of the controlled vocabulary from which variable standard names are taken.	Since these templates comply with CF conventions, this attribute should contain "CF-1.6".
summary	ACDD	global	string	One paragraph describing the data set.	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 for date and time.
time_coverage_end
time_coverage_duration					Use udunits(http://www.unidata.ucar.edu/software/udunits/) date (e.g., "25 days since 1970-01-01"), or the string "present".
time_coverage_resolution				Describes the resolution of the time variable in the data.	Use ISO 8601 for time resolution (e.g., P1Y ,P3M, P10D).
title	ACDD	global	string	One sentence about the data contained within the file.	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 RV JERE CHASE in the Gulf of Maine from 1982 to 1984; b. Temperature and salinity trajectory data from thermosalinograph measurements from the RV 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.
add_offset	CF	variable	float	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.	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	Please follow the guidance in the Description
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 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.The cell methods would have 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, 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	char	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.	Please follow the guidance in the Description
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
comment	CF	global / variable	string	This attribute is defined the same way as in ACDD. The only difference is that this can be used as a variable attribute.	Note the difference bewteen 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.
compress	CF	variable	string	This attribute is used in order to achieve some compression of the data.	Please follow the guidance in the Description
Conventions	CF	global	string	States that the CF convention is being used and what version.	Try to use the most recent version of the CF convention. Currently, it is "CF-1.6".
coordinates	CF	variable	string	This attribute contains a space seperated list of all the coordinates corresponding to the variable.The list should contain all the arxiliary 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. NODC 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 each value in the variable to a value in the flag_meanings in order to interpret the meaning of the value in the array.	Please follow the guidance in the Description
_FillValue	CF	variable	float	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
institution	CF	global / variable	string	This attribute is defined the same way as in ACDD. The only difference is that this can be used as a variable attribute. Use the conventions defined above for institution.	Please follow the guidance in the Description
long_name	CF	variable	string	A free-text field to describe the variable.	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.
references	CF	global / variable	string	Published or web-based references that describe the data or methods used to produce it.	This attribute should point to project web sites, published papers, and similar items.
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	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.	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
source	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, as specifically as could be useful. If it is observational, source should characterize it (e.g., "surface observation" or "radiosonde").	Please follow the guidance in the Description
standard_name	CF	variable	string	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.	Please follow the guidance in the Description
units	CF	variable	string	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.	Please follow the guidance in the Description
valid_max	CF	variable	float	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	float	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	NODC	global	char	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.
platform	NODC	global / variable	char	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. NODC recommends the use of the following attributes for those platform variables: call_sign, ices_code, wmo_code, and imo_code	Information on ICES codes is available at http://www.ices.dk/datacentre/requests/Login.aspx 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).
instrument	NODC	global / variable	char	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 seperated string. NODC 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.	Please follow the guidance in the Description
sea_name	NODC	global	char	The names of the sea in which the data were collected.	See the list of NODC sea names here: NODC Sea Names (http://www.nodc.noaa.gov/General/NODC-Archive/seanamelist.txt)
nodc_name	NODC	variable	char	The NODC 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 NODC data type names (http://www.nodc.noaa.gov/cgi-bin/OAS/prd/datatype).
nodc_template_version	NODC	global	char	This attribute tracks the version of the feature type created by NODC. (e.g., nodc_template_version = "netCDF_single_trajectory_v1.0")	Please follow the guidance in the Description

NODC Responses to Comments Received during netCDF Template Public Review and Comment Period

Thanks to everyone who sent us comments during the Public Review and Comment Period, February 20 through March 12. We solicited your feedback on the three components of our NODC netCDF templates: 1) The set of 13 templates, in the ASCII representation of a netCDF file known as CDL along with their corresponding real-world examples; 2) A decision tree to help you decide which of the templates to use; and 3) A table providing guidance and recommendations on creating the netCDF variable and global-level attributes. We received 46 comments from more than 15 people, and have published our responses to them.