5. GDS Data Product File Structure and attributes

5.1. Overview of the GDS-2.2r0 netCDF File Format

GDS-2.2r0 data files preferentially use the netCDF-4 Classic format. A major advantage to the use of NetCDF-4 format products is that it offers internal compression so that reading a given variable or some attributes does not require to explicitly decompress the entire file.

These GDS-2.2r0 formatted data sets must comply with the Climate and Forecast (CF) Conventions, v1.7 or later [1] because these conventions provide a practical standard for storing oceanographic data in a robust, easily-preserved for the long-term, and interoperable manner. The CF-compliant netCDF data format is flexible, self-describing, and has been adopted as a de facto standard for many operational and scientific oceanography systems. Both netCDF and CF are actively maintained including significant discussions and inputs from the oceanographic community. The CF convention generalizes and extends the Cooperative Ocean/Atmosphere Research Data Service (COARDS) Convention [2] but relaxes the COARDS constraints on dimension order and specifies methods for reducing the size of datasets. The purpose of the CF Conventions is to require conforming datasets to contain sufficient metadata so that they are self-describing, in the sense that each variable in the file has an associated description of what it represents, physical units if appropriate, and that each value can be located in space (relative to earth-based coordinates) and time. In addition to the CF Conventions, GDS-2.2r0 formatted files follow some of the recommendations of the Unidata Attribute Convention for Dataset Discovery (ACDD) [3].

In the context of netCDF, a variable refers to data stored in the file as a vector or as a multidimensional array. Each variable in a GHRSST netCDF file consists of a 2-dimensional [i x j], 3-dimensional [i x j x k], or 4-dimensional [i x j x k x l] array of data. The dimensions of each variable must be explicitly declared in the dimension section.

Within the netCDF file, global attributes are used to hold information that applies to the whole file, such as the data set title. Each individual variable must also have its own attributes, referred to as variable attributes. These variable attributes define, for example, an offset, scale factor, units, a descriptive version of the variable name, and a fill value, which is used to indicate array elements that do not contain valid data. Where applicable, SI units should be used and described by a character string, which is compatible with the Unidata UDUNITS-2 package [4].

All GHRSST GDS-2.2r0 files conform to this structure and share a common set of netCDF global attributes. These global attributes include those required by the CF Convention plus additional ones required by the GDS-2.2r0. The required set of global attributes is described in Section 5.2 and entities within the GHRSST R/GTS framework are free to add their own, as long as they do not contradict the GDS-2.2r0 and CF requirements.

Following the CF convention, each variable also has a set of variable attributes. The required variable attributes are described in Section 5.3. In a few cases, some of these variable attributes may not be relevant for certain variables or additional variable attributes may be required. In those cases, the variable descriptions in each of the L2P, L3, L4 product specifications will identify the differences and specify requirements for each product. As with the global attributes, entities within the GHRSST R/GTS framework are free to add their own variable attributes, as long as they do not contradict the GDS-2.2r0 and CF requirements.

While the exact volumes can vary, an average L2P file will use about 33 bytes per pixel, an L3 file 28 bytes per pixel, and an L4 file about 8 bytes per pixel. The data type encodings for each variable are fixed except for the experimental fields, which are flexible and can chosen by the GHRSST producer.

5.2. Global Attributes

Table 5.1 below summarizes the global attributes that are mandatory for every GDS-2.2r0 netCDF data file. More details on the CF-mandated attributes (as indicated in the Source column) are available at: http://cfconventions.org/cf-conventions/cf-conventions.html#attribute-appendix and information on the ACDD recommendations is available at https://wiki.esipfed.org/Attribute_Convention_for_Data_Discovery_1-3.

Table 5.1 Mandatory global attributes for GDS-2.2r0 netCDF data files (blue are mandatory, purple are optional)

Global Attribute Name	Format	Description	Example	Source
Conventions	string	A comma-separated list of the conventions that are followed by the dataset. For files that follow this version of ACDD, include the string ‘ACDD-1.3’.(This attribute is defined in NUG 1.7.)	Conventions = "CF 1.7+, ACDD 1.3<br>ISO 8601";	ACDD 1.3 CF 1.7++
title	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 recommended by the NetCDF Users Guide (NUG) and the CF conventions.	title = "VIIRS L2P Sea Surface Skin Temperature" ;	ACDD 1.1 ACDD 1.3 CF 1.7+
summary	string	A paragraph describing the dataset, analogous to an abstract for a paper.	summary = "Sea surface temperature (SST) retrievals produced at the NASA OBPG for the Visible Infrared Imaging Radiometer Suite (VIIRS) sensor on the Suomi National Polar-Orbiting Parnership (Suomi NPP) platform. These have been reformatted to GHRSST GDS version 2 Level 2P specifications by the JPL PO.DAAC." ;	ACDD 1.1 ACDD 1.3
references	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.	references = "GHRSST Data Processing Specification v2r5" ;	ACDD 1.3 CF 1.7+
institution	string	The name of the institution principally responsible for originating this data. This attribute is recommended by the CF convention.	institution = "NASA Jet Propulsion Laboratory (JPL) Physical Oceanography Distributed Active Archive Center (PO.DAAC)/NASA Goddard Space Flight Center (GSFC), Ocean Biology Processing Group (OBPG)/University of Miami Rosential School of Marine and Atmospheric Science (RSMAS)" ;	ACDD 1.1, ACDD 1.3 CF 1.7+
history	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.	history = "VIIRS L2P created at JPL PO.DAAC by combining OBPG SNPP_SST and SNPP_SST3, and outputing to the GHRSST GDS2 netCDF file format" ;	ACDD 1.1 ACDD 1.3 CF 1.7+
comment	string	Miscellaneous information about the data, not captured elsewhere. This attribute is defined in the CF Conventions.	comment = "L2P Core without DT analysis or other ancillary fields; Night, Start Node:Descending, End Node:Descending; WARNING Some applications are unable to properly handle signed byte values. If values are encountered > 127, please subtract 256 from this reported value; Quicklook" ;	ACDD 1.1 ACDD 1.3
license	string	Provide the URL to a standard or specific license, enter “Freely Distributed” or “None”, or describe any restrictions to data access and distribution in free text. GHRSST data sets should be freely and openly available to comply with the R/GTS framework, with no restrictions. However, if a user should submit a simple registration via a web form, for example, the URL could be given here.	license = "GHRSST protocol describes data use as free and open.” ;	ACDD 1.1 ACDD 1.3
id	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. This id should be a unique string of characters and should not include white space characters. Use here the unique GHRSST character string for this product as defined in Section 4.9.	id = "VIIRS_NPP-JPL-L2P-v2016.0" ;	ACDD 1.1 ACDD 1.3
naming_authority	string	The organization that provides the initial id (see above) for the dataset. The naming authority should be uniquely specified by this attribute. We recommend using reverse-DNS naming for the naming authority; URIs are also acceptable. Fixed as “org.ghrsst” following ACDD convention.	naming_authority = "org.ghrsst" ;	ACDD 1.1 ACDD 1.3
product_version	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. It may be different than the file version used in the file naming convention (Section 4).	product_version = "2016.0" ;	ACDD 1.3
uuid	string	A uuid (Universal Unique Identifier) is a 128-bit number used to uniquely identify some object or entity on the Internet. Depending on the specific mechanisms used, a uuid is either guaranteed to be different or is, at least, extremely likely to be different from any other uuid generated until 3400 A.D. See http://en.wikipedia.org/wiki/Universally_Unique_Identifier for more information and tools.	uuid = "b6ac7651-7b02-44b0-942b-c5dc3c903eba" ;	GDS
gds_version_id	string	GDS version used to create this data file. For example, “2.2”.		GDS
netcdf_version_id	string	Version of netCDF libraries used to create this file. For example, “4.1.1”		GDS
date_created	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.	date_created = "2016-10-14T21:00:25" ;	ACDD 1.1 ACDD 1.3
date_modified	string	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.	date_modified = "2016-10-14T21:00:25" ;	ACDD 1.1 ACDD 1.3
date_issued	string	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.	date_issued = "2016-10-14T21:00:25" ;	ACDD 1.1 ACDD 1.3
date_metadata_modified	string	The date on which the metadata was last modified. The ISO 8601:2004 extended date format is recommended.	date_metadata_modified = "2016-10-14T21:00:25" ;	ACDD 1.3
file_quality_level	integer	A code value describing the quality of the data:   0 = unknown quality   1 = extremely suspect (frequent problems, e.g. with known satellite problems)   2 = suspect (occasional problems, e.g. after launch)   3 = excellent (no known problems)		GDS
spatial_resolution	string	A string describing the approximate resolution of the product. For example, “1.1km at nadir”		GDS
time_coverage_start	string	Describes the time of the first data point in the data set. Use the ISO 8601:2004 date format, of yyyy-mm-ddThh:mm:ssZ. The exact meaning of this attribute depends the type of granule:   L2P: first measurement in granule (identical to ‘time’ netCDF variable)   L3U: start time of granule   L3C and L3S: representative start time of first measurement in the collation   L4: representative start time of the analysis (time_coverage_start and time_coverage_end together represent the valid period of the L4 granule)	time_coverage_start = "2016-09-01T08:12:01" ;	ACDD 1.1 ACDD 1.3
time_coverage_end	string	Describes the time of the last data point in the data set. Use ISO 8601:2004 date format, of “yyyy-mm-ddThh:mm:ssZ”. The exact meaning of this attribute depends the type of granule: >  L2P: last measurement in granule >  L3U: stop time of granule >  L3C and L3S: representative stop time of last measurement in collation >  L4: representative stop time of the analysis (time_coverage_start and time_coverage_end together represent the valid period of the L4 granule)	time_coverage_end = "2016-09-01T08:17:59" ;	ACDD 1.1 ACDD 1.3
instrument	string	Name of the contributing instrument(s) or sensor(s) used to create this data set or product. Indicate the controlled vocabulary used in instrument_vocabulary. We recommend for consistency to use the CEOS mission table (http://database.eohandbook.com/database/instrumenttable.aspx). Provide as a comma separated list if there is more than one.	sensor = "VIIRS" ;	ACDD 1.3
instrument_vocabulary	string	Controlled vocabulary for the names used in the instrument attribute.	instrument_vocabulary = "CEOS instrument table" ;	ACDD 1.3
metadata_link	string	A URL that gives the location of more complete metadata. A persistent URL is recommended for this attribute. It is recommended to link to the product description in the GHRSST central catalogue.	metadata_link = "http://podaac.jpl.nasa.gov/ws/metadata/dataset/?format=iso&shortName=VIIRS-JPL-L2P-v2016.0" ;	ACDD 1.3
keywords	string	A comma-separated list of key words and/or phrases. Keywords may be common words or phrases, terms from a controlled vocabulary (GCMD is often used), or URIs for terms from a controlled vocabulary (see also keywords_vocabulary attribute).	keywords = "Oceans, Ocean Temperature, Sea Surface Temperature , Sea Surface Skin Temperature" ;	ACDD 1.1 ACDD 1.3
keywords_vocabulary	string	If you are using a controlled vocabulary for the words/phrases in your keywords attribute, this is the unique name or identifier of the vocabulary from which keywords are taken. If more than one keyword vocabulary is used, each may be presented with a prefix (e.g.,NASA Global Change Master Directory (GCMD) Science Keywords [5]) and a following comma, so that keywords may optionally be prefixed with the controlled vocabulary key.	keywords_vocabulary = "NASA Global Change Master Directory (GCMD) Science Keywords" ;	ACDD 1.1 ACDD 1.3
standard_name_vocabulary	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).	CF Standard Name Table v27’.	ACDD 1.1 ACDD 1.3
geospatial_lat_min	float	Describes a simple lower latitude limit; may be part of a 2- or 3-dimensional bounding region. geospatial_lat_min specifies the southernmost latitude covered by the dataset.	geospatial_lat_min = -63.1404f ;	ACDD 1.1 ACDD 1.3
geospatial_lat_max	float	Describes a simple upper latitude limit; may be part of a 2- or 3-dimensional bounding region. geospatial_lat_max specifies the northernmost latitude covered by the dataset.	geospatial_lat_max = -36.7432f ;	ACDD 1.1 ACDD 1.3
geospatial_lat_units	string	Units for the latitude axis described in geospatial_lat_min and geospatial_lat_max attributes. These are presumed to be degree_north; other options from udunits may be specified instead.	geospatial_lat_units = "degrees_north" ;	ACDD 1.1 ACDD 1.3
geospatial_lat_resolution	float	Information about the targeted spacing of points in latitude. Recommend describing resolution as a number value followed by the units. Examples: 100 meters, 0.1 degree. For level 1 and 2 swath data this is an approximation of the pixel resolution.	geospatial_lat_resolution = 0.0075f ;	ACDD 1.1 ACDD 1.3
geospatial_lon_min	float	Describes a simple longitude limit; may be part of a 2- or 3-dimensional bounding region. geospatial_lon_min specifies the westernmost longitude covered by the dataset. See also geospatial_lon_max.	geospatial_lon_min = -143.09f ;	ACDD 1.1 ACDD 1.3
geospatial_lon_max	float	Describes a simple longitude limit; may be part of a 2- or 3-dimensional bounding region. geospatial_lon_max specifies the easternmost longitude covered by the dataset. Cases where geospatial_lon_min is greater than geospatial_lon_max indicate the bounding box extends from geospatial_lon_max, through the longitude range discontinuity meridian (either the antimeridian for -180:180 values, or Prime Meridian for 0:360 values), to geospatial_lon_min; for example, geospatial_lon_min=170 and geospatial_lon_max=-175 incorporates 15 degrees of longitude (ranges 170 to 180 and -180 to -175).	geospatial_lon_max = -88.893f ;	ACDD 1.1 ACDD 1.3
geospatial_lon_units	string	Units for the longitude axis described in geospatial_lon_min and geospatial_lon_max attributes. These are presumed to be degree_east; other options from udunits may be specified instead.	geospatial_lon_units = "degrees_east" ;	ACDD 1.1 ACDD 1.3
geospatial_lon_resolution	float	Information about the targeted spacing of points in longitude. Recommend describing resolution as a number value followed by units. Examples: 100 meters, 0.1 degree. For level 1 and 2 swath data this is an approximation of the pixel resolution.	geospatial_lon_resolution = 0.0075f ;	ACDD 1.1 ACDD 1.3
geospatial_vertical_min	float	Describes the numerically smaller vertical limit; may be part of a 2- or 3-dimensional bounding region. See geospatial_vertical_positive and geospatial_vertical_units.	geospatial_vertical_min = 0.00f ;	ACDD 1.1 ACDD 1.3
geospatial_vertical_max	float	Describes the numerically larger vertical limit; may be part of a 2- or 3-dimensional bounding region. See geospatial_vertical_positive and geospatial_vertical_units.	geospatial_vertical_max = 1000.00f ;	ACDD 1.1 ACDD 1.3
geospatial_vertical_resolution	float	Information about the targeted vertical spacing of points. Example: 25 meters	geospatial_vertical_resolution = 25.0f ;	ACDD 1.1 ACDD 1.3
geospatial_vertical_units	string	Units for the vertical axis described in 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_units = 'meters' ;	ACDD 1.1 ACDD 1.3
geospatial_vertical_positive	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.	geospatial_vertical_positive = 'down' ;	ACDD 1.1 ACDD 1.3
geospatial_bounds	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 = "(-143.09, -63.1404, -88.893, -36.7432)" ;	ACDD 1.1 ACDD 1.3
geospatial_bounds_crs	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_crs = "WGS84" ;	ACDD 1.3
geospatial_bounds_vertical_crs	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_bounds_vertical_crs = "EPSG:5831" ;	ACDD 1.3
acknowledgment	string	A place to acknowledge various types of support for the project that produced this data.	acknowledgment = "The VIIRS L2P sea surface temperature data are sponsored by NASA. Data may be freely distributed" ;	ACDD 1.1 ACDD 1.3
creator_name	string	The name of the person (or other creator type, such as a RDAC, specified by the creator_type attribute) principally responsible for creating this data.	creator_name = "JPL PO.DAAC" ;	ACDD 1.1 ACDD 1.3
creator_url	string	The URL of the of the person (or other creator type specified by the creator_type attribute) principally responsible for creating this data.	creator_url = "http://podaac.jpl.nasa.gov" ;	ACDD 1.1 ACDD 1.3
creator_email	string	The email address of the person (or other creator type specified by the creator_type attribute) principally responsible for creating this data.	creator_email = "ghrsst@jpl.nasa.gov" ;	ACDD 1.1 ACDD 1.3
creator_type	string	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. For a RDAC, use here institution.	creator_type = "institution" ;	ACDD 1.3
creator_institution	string	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.	creator_institution = "JPL PO.DAAC/GHRSST";	ACDD 1.3
project	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’.	"Group for High Resolution Sea Surface Temperature” ;	ACDD 1.1 ACDD 1.3
program	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’.	program= " NASA Earth Science Data Information and System (ESDIS)" ;	ACDD 1.3
contributor_name	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).	contributor_name = "PO.DAAC/OBPS/REMAS" ;	ACDD 1.3
contributor_role	string	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.	contributor_role = "PO.DAAC convert the VIIRSS_NPP SST to GDS2 format, OBPS processed the L2P SST, and RSMAS provided the algorithm model ";	ACDD 1.3
publisher_name	string	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.	publisher_name = "The GHRSST Project Office" ;	ACDD 1.1 ACDD 1.3
publisher_url	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.	publisher_url = "http://www.ghrsst.org" ;	ACDD 1.1 ACDD 1.3
publisher_email	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.	publisher_email = "ghrsst-po@nceo.ac.uk" ;	ACDD 1.1 ACDD 1.3
publisher_type	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_type = "institution" ;	ACDD 1.3
publisher_institution	string	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_institution = "PO.DAAC" ;	ACDD 1.3
processing_level	string	A textual description of the processing (or quality control) level of the data. GHRSST definitions are the options: L2P, L3U, L3C, L3S, L4	processing_level = "L2P" ;	ACDD 1.1 ACDD 1.3
cdm_data_type	string	The data type, as derived from Unidata’s Common Data Model Scientific Data types and understood by THREDDS. (This is a THREDDS “dataType”, and is different from the CF NetCDF attribute ‘featureType’, which indicates a Discrete Sampling Geometry file in CF.). swath or grid.	cdm_data_type = "swath" ;	ACDD 1.1 ACDD 1.3

5.3. Variable Attributes

Table 5.2 Variable attributes for GDS-2.1 netCDF data files (blue are mandatory, purple are optional, orange are deprecated attributes from previous GDS versions)

Variable Attribute Name	Format	Description		Source
_FillValue	Must be the same as the packed variable type	Assigned value in the data file designating a null or missing observation. This value must be of the same type as the storage (packed) type; should be set as the minimum value for this type. Note that some netCDF readers are unable to cope with signed bytes and may, in these cases, report fill as 128. Some cases will be reported as unsigned bytes 0 to 255. Required for the majority of variables except mask and l2p_flags. Best practices specifies that for satellite datasets there should not be a _FillVlalue for geolocation or time variables.	_FillValue = -32767s ;	CF 1.7+
units	String	The units of the variable’s data values. This attribute value should be a valid udunits[6] string. The units attribute is recommended by the NetCDF Users Guide, the COARDS convention, and the CF convention. For a given variable (e.g. wind speed), these must be the same for each dataset. Required for the majority of variables except mask, quality_level, and l2p_flags.	units = "K" ;	ACDD 1.1 ACDD 1.3 CF 1.7+
scale_factor	Must be expressed in the unpacked data type	Slope of scaling relationship applied to transform measuement data to appropriate geophysical quantity representations. Should not be used if the scale_factor is ‘1’ and add_offset is ‘0’ To be multiplied by the variable to recover the original value. Defined by the producer. Valid values within value_range should be transformed by scale_factor and add_offset, otherwise skipped to avoid floating point errors.	scale_factor = 0.005f ;	CF 1.7+
add_offset	Must be expressed in the unpacked data type	Intercept of scaling relationship applied to transform measurement data to appropriate geophysical quantity representations. Should not be used if the scale_factor is ‘1’ and add_offset is ‘0’ To be added to the variable after multiplying by the scale factor to recover the original value. If only one of scale_factor or add_offset is needed, then both should be included anyway to avoid ambiguity, with scale_factor defaulting to 1.0 and add_offset defaulting to 0.0. Defined by the producer. Valid values within value_range should be transformed by scale_factor and add_offset, otherwise skipped to avoid floating point errors.	add_offset = 273.15f ;	CF 1.7+
long_name	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.	long_name = "sea surface temperature" ;	ACDD 1.1 ACDD 1.3 CF 1.7+
valid_range	Must be the same as the packed variable type	Comma separated minimum and maximum values of the physical quantity defining the valid measurement range. The fill value should be outside this valid range. Note that some netCDF readers are unable to cope with signed bytes and may, in these cases, report valid min as 129. Some cases as unsigned bytes 0 to 255. Values outside of the valid_range will be treated as missing values. When all values except the one in _FillValue are valid, this attribute is not required. It is therefore not necessary in GDS for variables for which the _FillValue attribute is defined.	valid_range = -32767s, 32767 ;	CF 1.7+
standard_name	String	A long descriptive name for the variable taken from a controlled vocabulary of variable names. We require using the CF convention and the variable names from the CF standard name table[7]. This attribute is recommended by the CF convention. Do not include this attribute if no standard_name exists.	standard_name = "sea_surface_skin_temperature" ;	ACDD 1.1 ACDD 1.3 CF 1.7+
comment	String	Optional attribute field allowing provision of further free-form information about the variable or the methods used to produce it.	comment = "sea surface temperature from 11 and 12 um (thermal IR) channels" ;	CF 1.7+
source	string	For L2P and L3 files: For a data variable with a single source, use the GHRSST unique string if the source is a GHRSST SST product. For other sources, following the best practice described in Section Section 4.9 to create the character string. If the data variable contains multiple sources, set this string to be the relevant “source of” variable name. For example, if multiple wind speed sources are used, set source = source_of_wind_speed. For L4 and GMPE files: follow the source convention used for the global attribute of the same name, but provide in the comma-separated list only the sources relevant to this variable.	source = "ECMWF" ;	CF 1.7+
references	string	Published or web-based references that describe the data or methods used to produce it. Note that while at least one reference is required in the global attributes (See Section 5.2), references to this specific data variable may also be given.		CF 1.7+
axis	String	Corresponding variable axis for plotting (eg. X, Y, Z). For use with coordinate variables only. The attribute axis may be attached to a coordinate variable and given one of the values “X”, “Y”, “Z”, or “T”, which stand for a longitude, latitude, vertical, or time axis respectively[1].	axis = "Y";	CF 1.7+
positive	String	For use with a vertical coordinate variables only. May have the value “up” or “down”. For example, if an oceanographic netCDF file encodes the depth of the surface as 0 and the depth of 1000 meters as 1000 then the axis would set positive to “down”. If a depth of 1000 meters was encoded as -1000, then positive would be set to “up”. See the section on vertical coordinate in CF Convention[1]	positive = "up" ;	CF 1.7+
coordinates	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. See the section on coordinate system in CF Convention[1]. This attribute must be provided if the data are on a non-regular lat/lon grid (map projection or swath data).	coordinates = "time lat lon";	CF 1.7+
grid_mapping	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. That named variable is called a grid mapping variable and is of arbitrary type since it contains no data. Its purpose is to act as a container for the attributes that define the mapping. 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. See the section on mappings-and-projections in CF Convention[1].	grid_mapping = "geostationary";	CF 1.7+
flag_meanings	String	Define the physical meaning of each flag_masks bit field or flag_values value with a single text string.	flag_meanings = "microwave land ice lake river" ;	CF 1.7+
flag_values	Must be the same as the variable type	Its values identify the flagged conditions by performing a bitwise AND of the variable value and each flag masks value. 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””. Used primarily for quality_level and “source_of_xxx” variables.	flag_values = 1b, 5b ;	CF 1.7+
flag_masks	Must be the same as the variable type	A number of independent Boolean conditions using bit field notation by setting unique bits in each flag_masks value. The flag_masks attribute is the same type as the variable to which it is attached, and contains a list of values matching unique bit fields. (CF document, Flags section[1]). Used primarily for l2p_flags variable.	flag_masks = 1b, 2b, 4b, 8b, 16b;	CF 1.7+
depth	String	Use this to indicate the depth for which the SST data are valid.	depth= "1m" ;	GDS
height	String	Use this to indicate the height for which the wind data are specified.	height= "10m" ;	GDS
time_offset	float	Difference in hours between an ancillary field such as wind_speed and the SST observation time	time_offset= 3. ;	GDS
coverage_content_type	String	An ISO 19115-3 code to indicate the source of the data MD_CoverageContentTypeCode [8]. For example, image, thematicClassification, physicalMeasurement, auxiliaryInformation, qualityInformation, referenceInformation, modelResult, or coordinate.	coverage_content_type = "physicalMeasurement" ;	ACDD 1.1 ACDD 1.3

---

[1] (1,2,3,4,5,6)

netCDF Climate and Forecast (CF) Metadata Conventions version 1.7 or later available from http://cfconventions.org

[2]

COARDS Conventions available from https://ferret.pmel.noaa.gov/Ferret/documentation/coards-netcdf-conventions

[3]

Unidata Attribute Conventions for Dataset Discovery (ACDD), available from https://wiki.esipfed.org/Attribute_Convention_for_Data_Discovery_1-3

[4]

UDUNITS-2 package available from https://www.unidata.ucar.edu/software/udunits/

[5]

https://www.earthdata.nasa.gov/data/tools/idn/gcmd-keyword-viewer

[6]

http://www.unidata.ucar.edu/software/udunits/udunits-1/udunits.txt

[7]

http://cfconventions.org/Data/cf-standard-names/current/build/cf-standard-name-table.html

[8]

https://geonetwork-opensource.org/manuals/3.10.x/en/annexes/standards/iso19115-3.2018.html#standard-codelists-coverage-content-mrc-md-coveragecontenttypecode