Author: Bob Simons (bob.simons@noaa.gov)
Date created: 2005-09-20
Last edited: 2008-10-27

To Do:
   * Include what is defined by COARDS on the first line of each paragraph.
   * Be specific about the data type of each attribute.

References: 
   [COARDS] refers to http://ferret.wrc.noaa.gov/noaa_coop/coop_cdf_profile.html 
   [CDC COARDS] refers to http://www.cdc.noaa.gov/cdc/conventions/cdc_netcdf_standard.shtml 
   [NUG] refers to http://www.unidata.ucar.edu/software/netcdf/guidef/
      "NetCDF User's Guide for FORTRAN: An Access Interface for Self-Describing,
      Portable Data; version 3", 
      Russ Rew, Glenn Davis, Steve Emmerson, and Harvey Davies, June 1997.
   [CF-1.0] refers to 
     http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.0/cf-conventions.html
     (was at http://www.cgd.ucar.edu/cms/eaton/cf-metadata/CF-1.0.html) .
     1.1 is at http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.1/cf-conventions.html
     1.2 is at http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.2/cf-conventions.html
     1.4 ...
   [ACDD] refers to 
     http://www.unidata.ucar.edu/software/netcdf-java/formats/DataDiscoveryAttConvention.html
     which is used by the THREDDS data server.
     (Ethan agreed to the ACDD acronym.)
   [UDUNITS] refers to http://www.unidata.ucar.edu/software/udunits/index.html
     and the data file http://www.unidata.ucar.edu/software/udunits/udunits.txt 
   [CWHDF] refers to the CoastWatch HDF Metadata Specification
      http://coastwatch.noaa.gov/cw_form_hdf_metadata.html (incomplete, out-of-date)
      Bob has this locally as C:/programs/cwutilities/doc/Metadata.html .
   [UODC] refers to 
      http://www.unidata.ucar.edu/software/netcdf-java/formats/UnidataObsConvention.html .
   "[Lynn's File]" refers to http://oceanwatch.pfeg.noaa.gov/cgi-bin/nph-dods/data/ATdata/AT8day_wcs.nc.info 
     Bob has this locally as C:/programs/netcdf/AT8day_wcs.nc.htm .
   [GCMD] refers to GCMD Science Keywords
     http://gcmd.gsfc.nasa.gov/Resources/valids/gcmd_parameters.html
     2008, see http://gcmd.gsfc.nasa.gov/Resources/valids/archives/GCMD_Science_Keywords.pdf
   [CF Standard Names]   //note that version, e.g., /10/, changes often
     http://cf-pcmdi.llnl.gov/documents/cf-standard-names/10/cf-standard-name-table.html 
   [NETCDF] refers to 
     http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions

   Note that netCDF4 hopes to unite netCDF 3 and 4, and HDF 4 and 5.

   "Dave" is Dave Foley (dave.foley@noaa.gov) who is the manager of the West Coast Regional Node of CoastWatch.
   "Lynn" is Lynn DeWitt (Lynn.Dewitt@noaa.gov) who maintained the OPeNDAP servers 
      (before we switched to THREDDS) at NOAA NMFS SWFSC ERD.
   "John" is John Caron (caron@unidata.ucar.edu) who created THREDDS.
   "Ethan" is Ethan Davis (edavis@unidata.ucar.edu) who authored [ACDD].
   "Bob" is Bob Simons (bob.simons@noaa.gov), author of this document.
   "Peter" is Peter Hollemans (Peter.Hollemans@noaa.gov), who authored [CWHDF].

**************************************************************************
GLOBAL ATTRIBUTES
The global attributes are for the entire file. 

"Conventions" is in both [CF-1.0], [NETCDF] and [ACDD]. 
"Conventions" is defined as a [ACDD] required attribute, saying 
"When following multiple conventions, list them with a comma separator".
[CF-1.0] defines "Conventions" similarly, and requests the use of "CF-1.0".
[ACDD] and [CF-1.0] are consistent with the way [COARDS] defines 
"Conventions". [COARDS] requests the use of "COARDS".
Example from [ACDD]: Conventions = CF-1.0, Unidata Dataset Discovery v1.0
Bob's example: Conventions = COARDS, CF-1.0, Unidata Dataset Discovery v1.0, CWHDF
Grid.saveAsNetCDF: this is a constant

"title" is in both [CF-1.0], [NETCDF] and [ACDD]. 
"title" is defined in the [ACDD] Highly Recommended table as 
"a sentence describing the dataset." 
Ethan said OK to Bob's suggestion: I don't think it needs to be a sentence.
    How about "A brief description of the dataset (i.e., usually with fewer than 50 characters)"?
Later it says "The 'title' attribute gives a brief description of the dataset.  
Its use is highly recommended and its value will be used by THREDDS as the 
name of the dataset. It therefore should be human readable and reasonable to 
display in a list of such names."
"title" is defined in [CF-1.0] as "A succinct description of what is in the dataset."
Example from [Lynn's File]: title = POES AVHRR HRPT 1.25 km SST
Bob's example: title = SST, NOAA POES AVHRR, LAC, 0.0125 degrees, West US, Day and Night

"summary" is in [ACDD] but not [CF-1.0]. 
"summary" is defined in the [ACDD] Highly Recommended table as
"A paragraph describing the dataset."    
In [ACDD]:  "In many discovery systems, the title and the summary will 
be displayed in the results list from a search. It should therefore capture
the essence of the dataset it describes. For instance, we recommend this field 
include information on the type of data contained in the dataset, how the data 
was created (e.g., instrument X; or model X, run Y), the creator of the 
dataset, the project for which the data was created, the geospatial coverage 
of the data, and the temporal coverage of the data. This should just be a 
summary of this information, more detail should be provided in the recommended 
creator attributes, the recommended geospatial attributes, and the recommended 
temporal attributes."
I got Bob's example from FGDC tag: <metadata><idinfo><descript><abstract> .
Bob: should I include geospatial and temporal coverage as requested? How differentiate summary and actual values?
   Decision: In general, no. Keep it as a general description of the dataset, not specifics.
Bob's example: summary = NOAA CoastWatch provides sea surface temperature (SST) products derived from NOAA's Polar Operational Environmental Satellites (POES).  This data is provided at high resolution (1.47km) for the North Pacific Ocean.  Measurements are gathered by the Advanced Very High Resolution Radiometer (AVHRR) instrument, a multiband radiance sensor carried aboard the NOAA POES satellites.
Grid.saveAsNetCDF: this will be generated on the fly from fgcd metadata (&abstract;)
    
"keywords" is in [ACDD] but not [CF-1.0]. 
"keywords" is defined in the [ACDD] Highly Recommended table as
"A semicolon separated list of key words and phrases."
CoastWatch West Coast is using "GCMD Science Keywords" (use the words from
the relevant line of 
http://gcmd.gsfc.nasa.gov/Resources/valids/gcmd_parameters.html ). 
Can we / should we generate additional keywords, e.g., satellite, sensor, ... ? For now, no.
Ethan, since the vocabulary is controlled, can I include other keywords, e.g., NOAA, POES, CoastWatch, ...
   or should these words use an attribute like "keyword_category"
   and free form key words use "keywords"?
   Bob has keywords from fgdc data, too.
   Ethan's answer: "Yeah, this may need some work. It isn't clear how to deal 
       with multiple controlled vocabularies in a single attribute. For now, 
       if you are going to combine controlled and uncontrolled vocabularies, 
       I would suggest not specifying the controlled vocabulary. If you only 
       use a single controlled vocabulary, document that."
       And he said to use ">" within GCMD keywords as the whole thing
       constitutes one keyword. 
Other problem: GCMD keywords seem tied to one variable. If >1 variable, do what?
Bob's example: keywords = EARTH SCIENCE > Oceans > Ocean Temperature > Sea Surface Temperature
Grid.saveAsNetCDF: For now, use keyworks below 
   (generated keywords by finding the relevant line in gcmd_parameters.html)

"keywords_vocabulary" is in [ACDD] but not [CF-1.0]. 
"keywords_vocabulary" is defined in the [ACDD] Recommended table as
"If you are following a guideline for the words/phrases in your 'keywords' 
attribute, put the name of that guideline here."
One of the suggested vocabularies is "GCMD Science Keywords" (
http://gcmd.gsfc.nasa.gov/Resources/valids/gcmd_parameters.html ). 
Bob's example: keywords_vocabulary = GCMD Science Keywords
Grid.saveAsNetCDF: this is a constant

"id" is in [ACDD] but not [CF-1.0]. 
"id" is defined in the [ACDD] Recommended table as
"The combination of the 'naming authority' and the 'id' should be a globally 
unique identifier for the dataset."
Later it says "The 'id' value should attempt to uniquely identify the dataset. 
The naming authority allows a further refinement of the 'id'. The combination 
of the two should be globally unique for all time. We recommend using 
reverse-DNS naming for the naming authority. For example, 
naming_authority='edu.ucar.unidata' and id='NCEP/NAM_211_2005-05-24_12Z'."
CoastWatch WestCoast uses the CWBrowser custom file name as the id because it is unique.
Bob's example: id = LATsstaS1day_20030304_W-135E-113S30N50
   (but the exact format has varied)
Grid.saveAsNetCDF: these will be generated on the fly (custom file name)

"naming_authority" is in [ACDD] but not [CF-1.0]. 
"naming_authority" is defined in the [ACDD] Recommended table as
"The combination of the 'naming authority' and the 'id' should be a globally 
unique identifier for the dataset."
Bob's example: naming_authority = gov.noaa.pfel.coastwatch
That follows the Java system for unique identification of Java classes.
Grid.saveAsNetCDF: this is a constant

"cdm_data_type" is in [ACDD] but not [CF-1.0]. 
"cdm_data_type" is a [ACDD] recommended attribute with a limited vocabulary
("Grid", "Image", "Station", "Trajectory", "Radial"). 
Example from [Lynn's File]: cdm_data_type = Grid
Bob's example: cdm_data_type = Grid
Grid.saveAsNetCDF: this is a constant
???But if you extract a time series from Gridded data, what type is it now if no longer in a grid?

"history" is in [ACDD], [NETCDF] and [CF-1.0]. 
"history" is defined in the [ACDD] Recommended table as
"The 'history' attribute provides an audit trail for modifications to the 
original data. It should contain a separate line for each modification with
each line including a timestamp, user name,  modification name, and 
modification arguments."
[CF-1.0] section 2.6.2 defines it as "Provides an audit trail for modifications 
to the original data. Well-behaved generic netCDF filters will automatically 
append their name and the parameters with which they were invoked to the 
global history attribute of an input netCDF file. We recommend that each 
line begin with a timestamp indicating the date and time of day that the 
program was executed."
[ACDD] and [CF-1.0] are consistent with the way [COARDS] defines 
"history".
"history" is a required CHAR8 [CWHDF] attribute defined as
"A newline-separated list of utilities and command line parameters 
used to create the file and perform processing."
Bob points out: this is required for [CWHDF] but optional elsewhere.
Bob says see DataHelper.addBrowserToHistory
Bob's example: history = <courtesy>\n2006-04-07T19:02:34 NOAA NESDIS Coastwatch WCRN
    
"date_created" is in [ACDD] but not [CF-1.0]. 
"date_created" is defined in the [ACDD] Recommended table as
"the date on which the data was created."
Bob's example: date_created = 2003-03-05
Grid.saveAsNetCDF: this will be generated on the fly (the day after the end date)

"creator_name", "creator_url", and "creator_email" are in [ACDD] 
but not [CF-1.0]. 
"creator_name", "creator_url", "creator_email" are defined in the 
[ACDD] Recommended table as
"The data creator's name, URL, and email. The 'institution' attribute will be 
used if the 'creator_name' attribute does not exist."
Dave, says we are almost always the "creator" (even by compositing the data)
and not just the "publisher". 
Example from [Lynn's File]: creator_name = West Coast Regional CoastWatch Node
Bob's example: 
  In Grid files and most Point files:
      creator_name = NOAA NESDIS CoastWatch WCRN
  In some Point Files    
      creator_name = NOAA NMFS SWFSC ERD
Grid.saveAsNetCDF: this is a constant

"creator_url" wasn't in [Lynn's File].
Bob's example: creator_url = http://coastwatch.pfel.noaa.gov
  or  http://www.pfel.noaa.gov
Grid.saveAsNetCDF: this is a constant

"creator_email" wasn't in [Lynn's File].
Dave, do we have a generic email account? Answer: no, NOAA said we can't do that.
Bob's example: 
   in all grid files and most Point files: creator_email = dave.foley@noaa.gov
   or in some point files:  Roy.Mendelssohn@noaa.gov
Grid.saveAsNetCDF: this is a constant

"institution" is in [ACDD] and [CF-1.0]. 
"institution" is listed in the [ACDD] Recommended table, but is
not defined.
"institution" is defined in [CF-1.0] section 2.6.2 as
"Specifies where the original data was produced."
pre 2008-02-21, Bob used the "courtesy" of information.
2008-02-21 Roy and Dave decided Bob should use creator_name
  ("NOAA CoastWatch, West Coast Node") for "institution" for the
  satellite and hfradar datasets Dave works with.
Bob's example : 
  institution = NOAA CoastWatch, West Coast Node

"project" is in [ACDD] but not [CF-1.0]. 
"project" is a [ACDD] recommended attribute:
"The 'project' attribute provides the name of the scientific project for 
which the data was created."
Later it says "Kind of one level above creator/institution. More of a 'why was
this dataset created' rather than 'where was it created'.".
Bob's example: project = CoastWatch (http://coastwatch.noaa.gov/)
Grid.saveAsNetCDF: this is a constant
    
"processing_level" is in [ACDD] but not [CF-1.0]. 
"processing_level" is defined in the [ACDD] Recommended table as
"A textual description of the processing (or quality control) level of the data."
Later, it says "this is a bit vague. However, some places have specific 
processing level terminology. Do we want to allow for specifying controlled 
lists of values?"
For CoastWatch, "Basic Processing Levels" 
  (http://www.faqs.org/faqs/sci/Satellite-Imagery-FAQ/part3/section-4.html and
   http://earth.esa.int/rtd/Projects/HiProGen/index.html )
  indicates most of our data is level 3 (projected (e.g., to geographic projection),
  and often composited).
  We sometimes deal with level 4 (model)
Bob's example for Grid data: processing_level = 3
   but for Point data this isn't used.
Grid.saveAsNetCDF: this is a constant
    
"acknowledgement" is in [ACDD] but not [CF-1.0]. 
"acknowledgement" is defined in the [ACDD] Highly Recommended table as
"A place to acknowledge various type of support for the 
  project that produced this data."
Bob takes this to mean e.g., funding sources, as opposed to contributors
(see contributor_name below).
Bob's example: acknowledgement = NOAA NESDIS
  since our funding comes from NESDIS.
Grid.saveAsNetCDF: this is a constant
    
"geospatial" man and max are in [ACDD] but not [CF-1.0]. 
The "geospatial" min and max attributes are defined in the 
[ACDD] Recommended table. 
The other "geospatial" attributes are defined in the 
[ACDD] Suggested tables. 
[ACDD] says 
"Use the min and max attributes to describe a simple latitude, longitude, 
vertical bounding box. If none of the other attributes are used, latitude is 
assumed to be in decimal degrees north, longitude is assumed to be in decimal 
degrees east, and vertical is assumed to be in meters above ground. The use of 
these min/max geospatial attributes is highly recommended.
Further refinement of the geospatial bounding box can be provided by using the 
units and resolution attributes. The geospatial_vertical_positive 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)."
[COARDS] defines a variable attribute "positive" which is consistent with this.
Ethan said OK to Bob's suggestion:
  "The use of these min/max geospatial attributes is highly recommended.",
  but they are listed in the Recommended table.
Ethan said OK to Bob's suggestion:
  "The use of these further geospatial attributes is recommended.",
  but they are listed in the Suggested table.
Example from [Lynn's File]: geospatial_lat_min = 22.
Bob's example: geospatial_lat_min = 22.0
Grid.saveAsNetCDF: this is generated on-the-fly

Example from [Lynn's File]: geospatial_lat_max = 50.
Bob's example: geospatial_lat_max = 50.0
Grid.saveAsNetCDF: this is generated on-the-fly

Example from [Lynn's File] (I think she meant 225): geospatial_lon_min = 215.
Bob's example: geospatial_lon_min = -135.0
Grid.saveAsNetCDF: this is generated on-the-fly

Example from [Lynn's File]: geospatial_lon_max = 255.
Bob's example: geospatial_lon_max = -105.
Grid.saveAsNetCDF: this is generated on-the-fly

Example from [Lynn's File]: geospatial_lat_units = "degrees_north"
Bob's example: geospatial_lat_units = degrees_north
Grid.saveAsNetCDF: this is a constant

Example from [Lynn's File]: geospatial_lat_resolution =  0.01250000019
Bob objected to Lynn about displaying bruised values. 
Bob's example: geospatial_lat_resolution = 0.0125
Grid.saveAsNetCDF: this is generated on-the-fly

Example from [Lynn's File]: geospatial_lon_units = degrees_east
Bob's example: geospatial_lon_units = degrees_east
Grid.saveAsNetCDF: this is a constant

Example from [Lynn's File]: geospatial_lon_resolution = 0.01250000019
Bob's example: geospatial_lon_resolution = 0.0125
Grid.saveAsNetCDF: this is generated on-the-fly

We currently only deal with information at the sea surface.
geospatial_vertical_min =
geospatial_vertical_max =
geospatial_vertical_units =
geospatial_vertical_resolution =
geospatial_vertical_positive =

Dave says Google Earth can read .nc files if they have
(terms originally from GDAL? see http://gdal.maptools.org/frmt_dods.html) 
(Bob has never tested this): 
Southernmost_Northing = <minLat>
Northernmost_Northing = <maxLat>
Westernmost_Easting = <minLon +/-180>
Easternmost_Easting = <maxLon +/-180>

"time_coverage_start" is in [ACDD] but not [CF-1.0]. 
"time_coverage_start", "time_coverage_end", "time_coverage_duration" , and
"time_coverage_resolution" are
defined in the [ACDD] Recommended table as 
"Describes the temporal coverage of the data as a time range." 
Later, it says "These attributes are used to describe the temporal coverage 
of the data. The temporal coverage of the data can be described with any of 
the following pairs of values: start/end, start/duration, or end/duration. 
The start and end values should be a date string like an ISO8601 date 
(e.g., '1999-07-04T22:30'), a [UDUNITS] date (e.g., '25 days since 1970-01-01'),
or the string 'present'. The duration value should be an ISO8601 duration 
string (e.g., 'P10D'). The resolution provides an idea of the density of 
the data inside the time range and should also be an ISO8601 duration string."
Information about ISO8601 is at http://en.wikipedia.org/wiki/ISO_8601 .
Bob's example: time_coverage_start = 2003-03-04T00:00:00Z
Bob's example: time_coverage_end = 2003-03-05T00:00:00Z  (until 12/2006, was 2003-03-04T23:59:59)
Bob doesn't need time_coverage_duration, since he uses start and end.
Example from [Lynn's File]: time_coverage_resolution = P01D
Bob's example (P1H for GOES composites, P12H? for POES composites) : time_coverage_resolution = P12H
Grid.saveAsNetCDF: this is optional, let's just not support it for now

"standard_name_vocabulary" is in [ACDD] but not [CF-1.0]. 
"standard_name_vocabulary" is defined in the [ACDD] Recommended table as
"The name of the controlled vocabulary from which variable standard names are 
taken."
Later, it says to use [CF-1.0] for CF name (see [CF Standard Names]
for CF standard names).
Bob's example: standard_name_vocabulary = CF-1.0
Grid.saveAsNetCDF: this is a constant

"license" is in [ACDD] but not [CF-1.0]. 
"license" is defined in the [ACDD] Recommend table as
"Describe the restrictions to data access and distribution."
Bob's example: license = The data may be used and redistributed for free but is not intended for legal use, since it may contain inaccuracies. Neither CoastWatch, NOAA, nor the United States Government, nor any of their employees or contractors, makes any warranty, express or implied, including warranties of merchantability and fitness for a particular purpose, or assumes any legal liability for the accuracy, completeness, or usefulness, of this information.
  This is modified slightly from a NOAA NMFS SWFSC web page.
Grid.saveAsNetCDF: this is a constant

"contributor_name" and "contributor_role" is in [ACDD] but not [CF-1.0]. 
"contributor_name" and "contributor_role" are defined in the [ACDD] 
Suggested table as
"The name and role of any individuals or institutions that contributed to the 
creation of this data."
Bob's example: contributor_name = NOAA NWS Monterey and NOAA CoastWatch
Bob's example: contributor_role = Source of level 2 data.
Grid.saveAsNetCDF: contributor_name is generated on-the-fly ("<courtesy1> <courtesy2>")
Grid.saveAsNetCDF: contributor_role is a constant

"publisher_name", "publisher_url", and "publisher_email" are in [ACDD]
but not [CF-1.0]. 
"publisher_name", "publisher_url", and "publisher_email" are defined in the
[ACDD] Suggested table as "The data publisher's name, URL, and email. 
The publisher may be an individual or an institution."
Dave, says we are almost always the "creator" (even by compositing the data)
and not just the "publisher". 
Leave sources (e.g., NOAA NESDIS) as "contributors" and "institution".
Bob isn't using these since we are the creators.

"date_issued" is in [ACDD] but not [CF-1.0]. 
"date_issued" is defined in the [ACDD] Suggested table as
"The 'date_issued' attribute provides the date on which this data was formally 
issued. Use of this attribute is suggested when relevant to the data and 
distinct from other dates used for this data."
Bob's example: date_issued = 2003-03-05
Grid.saveAsNetCDF: this will be generated on the fly (the day after the end date,
which is probably when we processed the data).

"date_modified" is in [ACDD] but not [CF-1.0]. 
"date_modified" is defined in the [ACDD] Suggested table as
"The 'date_modified' attribute provides the date on which the data was last
modified. Use of this attribute is suggested if the data has been modified 
since the date of creation."
Bob says it is not relevant to us.

"comment" is in [CF-1.0] but not [ACDD]. 
"comment" is defined in [CF-1.0] section 2.6.2 as
"Miscellaneous information about the data or methods used to produce it." 
This is being considered for addition to [ACDD].
???Bob's [not yet] example: 
Luke don't use this: it is not required and the information is in 'summary' and other fields.
    
"references" is in [CF-1.0] but not [ACDD]. 
"references" is defined in [CF-1.0] section 2.6.2 as 
"Published or web-based references that describe the data or methods used to 
produce it."
This is being considered for addition to [ACDD].
Bob's example: references = NOAA POES satellites information: http://coastwatch.noaa.gov/poes_sst_overview.html . Processing information: http://www.osdpd.noaa.gov/PSB/EPS/CW/coastwatch.html . Processing reference: Walton C. C., W. G. Pichel, J. F. Sapper, D. A. May, The development and operational application of nonlinear algorithms for the measurement of sea surface temperatures with the NOAA polar-orbiting environmental satellites, J.G.R., 103: (C12) 27999-28012, 1998. Cloudmask reference: Stowe, L. L., P. A. Davis, and E. P. McClain.  Scientific basis and initial evaluation of the CLAVR-1 global clear/cloud classification algorithm for the advanced very high resolution radiometer. J. Atmos. Oceanic Technol., 16, 656-681. 1999. Calibration and Validation: Li, X., W. Pichel, E. Maturi, P. Clemente-Coln, and J. Sapper, Deriving the operational nonlinear multi-channel sea surface temperature algorithm coefficients for NOAA-15 AVHRR/3, International Journal of Remote Sensing,  Volume 22, No. 4, 699 - 704, March 2001a. Calibration and Validation: Li, X, W. Pichel, P. Clemente-Coln, V. Krasnopolsky, and J. Sapper, Validation of coastal sea and lake surface temperature measurements derived from NOAA/AVHRR Data, International Journal of Remote Sensing, Vol. 22, No. 7, 1285-1303, 2001b.
Bob says the length info below is from Luke, the short info is from Bob.

"source" is in [CF-1.0] but not [ACDD]. 
"source" is defined in [CF-1.0] section 2.6.2 as
"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')."
This is being considered for addition to [ACDD].
Sample from [Lynn's File]: source = "NWS and NESDIS" //this is probably inappropriate
Bob's example (Dave okayed): source = satellite observation: POES AVHRR HRPT
Bob's example:               source = observation from High Frequency Radar
Grid.saveAsNetCDF: generate as: source = satellite observation: <satellite> <sensor>
   or, if no satellite:         source = observation from <sensor>

"flag_values" and "flag_meanings" are defined in [CF-1.0].
These apply to enumerated values.
It is unclear to me if these can also be used for bit-flags.
Bob says: we don't use these because we don't have this kind of data.
  But some new data sets do?  Use these?

"cwhdf_version" is in [CWHDF] but not in [ACDD] or [CF-1.0].
"cwhdf_version" is a required Char8 [CWHDF] attribute, defined as
"The metadata version."
Bob says this is a constant, but changes occasionally.
Bob's example: cwhdf_version = 3.4

"satellite" is in [CWHDF] but not in [ACDD] or [CF-1.0].
"satellite" is a required CHAR8 [CWHDF] attribute for satellite data, defined as
"If data is from a satellite, the satellite name, for example 'noaa-16', 
'goes-8', 'orbview-2'."
Bob says: see CWBrowser.properities info: satellite
Bob's example: satellite = POES
  Since a dataset spans a long period of time, there may be more than
  one individual satellite involved.

"sensor" is in [CWHDF] but not in [ACDD] or [CF-1.0].
"sensor" is a required CHAR8 [CWHDF] attribute for satellite data, defined as
"If data is from a satellite, the satellite sensor name, for example 'avhrr', 
'seawifs'."
Bob says: see CWBrowser.properities info: sensor
Bob's example: sensor = AVHRR HRPT

"data_source" is in [CWHDF] but not in [ACDD] or [CF-1.0].
"data_source" is a required CHAR8 [CWHDF] attribute for non-satellite data, 
defined as "If data is not from a satellite, the data source, for example the 
instrument used to collect the data or the model used to generate the data."
Bob says: we now have some non-satellite data, so start using it.  

"composite" is in [CWHDF] but not in [ACDD] or [CF-1.0].
"composite" is an optional CHAR8 [CWHDF] attribute defined as
"The composite flag, 'true' if the data is derived from multiple datasets, 
or 'false' if not. If true, then the pass_date, start_time, and temporal_extent
attributes may contain arrays of values, and the satellite, sensor, data_source,
orbit_type, pass_type, and origin attributes may have multiple 
newline-separated values. If absent, it is assumed that the data is not a
composite."
Bob says: <startTime> != <endTime>
Bob's example: composite = true

"pass_date" is in [CWHDF] but not in [ACDD] or [CF-1.0].
"pass_date" is a required INT32 [CWHDF] attribute defined as
int32 "The date of data recording in days since January 1, 1970."
Or as int32[] "If the data is a composite, the dates of data recording in 
days since January 1, 1970. Date and time data must be stored in sorted order 
from least recent to most recent."
Bob says: this examples below probably don't match the sample file name above
Bob's example: pass_date = 12806                    //for non-composite  
Bob's example: pass_date = 12806, 12807, 12808      //for composite

"start_time" is in [CWHDF] but not in [ACDD] or [CF-1.0].
"start_time" is a required [CWHDF] attribute defined as
FLOAT64 "The start time of the data recording in seconds since 00:00:00 UTC."
Or FLOAT64[] "If the data is a composite, the start times of data recording in 
seconds since 00:00:00 UTC."
Thus, it is related to pass_date: it is the number of seconds
since 00:00:00 for the start_time for each of the pass_dates.
Bob's example: start_time = 43104        //for non-composite
Bob's example: start_time = 0, 0, 0   // for composite

"temporal_extent" is in [CWHDF] but not in [ACDD] or [CF-1.0].
"temporal_extent" is an optional [CWHDF] attribute defined as 
FLOAT64[] "The time duration in seconds between the start of data recording 
and the end of data recording."
Bob says: since we don't have this info, we'll ignore it.

"pass_type" is in [CWHDF] but not in [ACDD] or [CF-1.0].
"pass_type" is an optional CHAR8 [CWHDF] attribute defined as
"The satellite pass temporal type: 'day', 'night', 'day/night'."
Bob says: since this is optional and we don't have the data, let's ignore it.

"orbit_type" is in [CWHDF] but not in [ACDD] or [CF-1.0].
"orbit_type" is an optional CHAR8	[CWHDF] attribute defined as
"If the data is from an orbiting satellite that crosses the equator in a 
northward or southward direction, the orbit type as 'ascending' or 
'descending' respectively."
Bob says: since this is optional and we don't have the data, let's ignore it.

"origin" is in [CWHDF] but not in [ACDD] or [CF-1.0].
"origin" is a required CHAR8 [CWHDF]	attribute defined as
"The original data source as an agency or organization name, for example 
'USDOC/NOAA/NESDIS CoastWatch'."
Bob says: see CWBrowser.properities info: <courtesy1> <courtesy2>
Bob's example: data_source = NOAA NWS Monterey and NOAA CoastWatch

"projection_type" is in [CWHDF] but not in [ACDD] or [CF-1.0].
"projection_type" is a required CHAR8 [CWHDF] attribute defined as
"The projection type: 'mapped', 'swath', or 'sensor_scan'. 
Mapped data is formatted to a well-known map projection and accompanied by 
GCTP map projection parameters. Swath data is data that is not in a standard 
map projection, but is accompanied by Earth location data for each pixel 
(see the section on Swath data). Sensor scan data is similar to swath..."
Bob says we always use "mapped".
Bob's example: projection_type = mapped

"projection" is in [CWHDF] but not in [ACDD] or [CF-1.0].
"projection" is a required CHAR8 [CWHDF] attribute defined as
"For mapped data, a descriptive projection name, for example 'mercator', 
'geographic', 'polar stereographic'."
Bob says we always use "geographic"
Bob's example: projection = geographic

"gctp_sys" is in [CWHDF] but not in [ACDD] or [CF-1.0].
"gctp_sys" is a required INT32 [CWHDF] attribute defined as
"For mapped data, the GCTP projection system code."
Bob says we always use 0;
Bob's example: gctp_sys = 0

"gctp_zone" is in [CWHDF] but not in [ACDD] or [CF-1.0].
"gctp_zone" is a required INT32 [CWHDF] attribute defined as
"For mapped data, the GCTP zone for UTM projections."
Bob says we always use 0
Bob's example: gctp_zone = 0

"gctp_parm" is in [CWHDF] but not in [ACDD] or [CF-1.0].
"gctp_parm" is a required FLOAT64[] [CWHDF] attribute defined as
"For mapped data, the GCTP projection parameters."
Bob says we always use 15 0's.
Bob's example: gctp_parm = 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0

"gctp_datum" is in [CWHDF] but not in [ACDD] or [CF-1.0].
"gctp_datum" is a required INT32 [CWHDF] attribute defined as
"For mapped data, the GCTP spheroid code."
Bob says we always use 12=WGS84
Bob's example: gctp_datum = 12

"et_affine" is in [CWHDF] but not in [ACDD] or [CF-1.0].
"et_affine" is a required FLOAT64[] [CWHDF] attribute defined as
"For mapped data, the map affine transform (6)."
lon = a*row + c*col + e
lat = b*row + d*col + f
float64[] {a, b, c, d, e, f}
See [CWHDF] for more information.
Bob says, our minimalist transformation is double matrix[] = {
   0, -latSpacing, lonSpacing, 
   0, lon[0], lat[lat.length-1]};
Bob's example: et_affine = 0, -.0125, .0125, 0, -135, 50        

"sensor_code" is in [CWHDF] but not in [ACDD] or [CF-1.0].
"sensor_code" is a required INT32 [CWHDF] attribute for sensor data, defined as
"For sensor scan data, the sensor code. The only code currently available is 0,
which indicates a geostationary satellite."
Bob says he is unclear about this.

"sensor_parm" is in [CWHDF] but not in [ACDD] or [CF-1.0].
"sensor_parm" is a required FLOAT64[] [CWHDF] attribute for sensor data, defined as
"For sensor scan data, the sensor parameters. ..."
Bob says ignore this since we (I) don't have the information.

"rows" is in [CWHDF] but not in [ACDD] or [CF-1.0].
"rows" is a required INT32 [CWHDF] attribute defined as
"The number of rows of data."
Bob says use lat.length
Bob's example: rows = 2241

"cols" is in [CWHDF] but not in [ACDD] or [CF-1.0].
"cols" is a required INT32 [CWHDF] attribute defined as
"The number of columns of data."
Bob says use lon.length
Bob's example: cols = 2401

"polygon_latitude" is in [CWHDF] but not in [ACDD] or [CF-1.0].
"polygon_latitude" is an optional FLOAT64[] [CWHDF] attribute defined as
"	Latitude components of the bounding polygon with initial element repeated."
Bob says we always use: polygon_latitude = <minY>, <maxY>, <maxY>, <minY>, <minY>
Bob's example: polygon_latitude = 22, 50, 50, 22, 22

"polygon_longitude" is in [CWHDF] but not in [ACDD] or [CF-1.0].
"polygon_longitude" is an optional FLOAT64[] [CWHDF] attribute defined as
"Longitude components of the bounding polygon with initial element repeated."
Bob says we always use: polygon_longitude = <minX>, <minX>, <maxX>, <maxX>, <minX>
Bob's example: polygon_longitude = -135, -135, -105, -105, -135

"raster_type" is in [CWHDF] but not in [ACDD] or [CF-1.0].
"raster_type" is an optional CHAR8 [CWHDF] attribute defined as
"One of 'RasterPixelIsArea' or 'RasterPixelIsPoint' to capture the same 
distinction as the GeoTIFF global attribute 'GTRasterTypeGeoKey'. 
If pixels represent point data, then extra SDS variables 'latitude' and 
'longitude' in the dataset localize the point within the pixel area which 
otherwise default to the pixel center. If absent, pixels are assumed to 
represent area data."
Bob says we always use "RasterPixelIsArea"
Bob's example: raster_type = RasterPixelIsArea

"region_code" is in [CWHDF] but not in [ACDD] or [CF-1.0].
"region_code" is an optional CHAR8 [CWHDF] attribute defined as
"The data processing region code as a short abbreviation."
There is no indication of what the valid values are.
Bob says: this is optional and we don't have enough info, so ignore it.

"region_name" is in [CWHDF] but not in [ACDD] or [CF-1.0].
"region_name" is an optional CHAR8 [CWHDF] attribute defined as
"The data processing region name in full."
There is no indication of what the valid values are.
Bob says: this is optional and we don't have enough info, so ignore it.

"station_code" is in [CWHDF] but not in [ACDD] or [CF-1.0].
"station_code" is an optional CHAR8 [CWHDF] attribute defined as
"The data capture ground station as a short abbreviation."
There is no indication of what the valid values are.
Bob says: this is optional and we don't have enough info, so ignore it.

"station_name" is in [CWHDF] but not in [ACDD] or [CF-1.0].
"station_name" is an optional CHAR8 [CWHDF] attribute defined as
"The data capture ground station name in full."
There is no indication of what the valid values are.
Bob says: this is optional and we don't have enough info, so ignore it.

"latitude_coordinate"
"longitude_coordinate"
"zaxis_coordinate"
"time_coordinate"
The Unidata Observation Dataset Conventions lists these as an optional
way to identify the geotime variables. I don't like this. If you
hava a file with these variables, then remove some of the variables,
the program has to consciously remove these attributes. That is
unnecessary trouble. Better to just use the other ways to identify
the geotime variables.


**************************************************************************
VARIABLE ATTRIBUTES

Order of data in the .nc file:
  [CF-1.0] says "If any or all of the dimensions of a variable have the 
  interpretations of 'date or time' (T), 'height or depth' (Z), 'latitude' (Y),
  or 'longitude' (X) then we recommend, but do not require (see section 1.4),
  those dimensions to appear in the relative order T, then Z, then Y, then X 
  in the CDL definition corresponding to the file. All other dimensions should, 
  whenever possible, be placed to the left of the spatiotemporal dimensions."
  [COARDS] defines "order of dimensions" in the same way.

For each variable, the following attributes are defined:

For all variables:
"long_name" is in [ACDD], [CF-1.0], [NETCDF], and [CWHDF].
"long_name" is defined in the [ACDD] Highly Recommended variable
attributes table as "A long descriptive name for the variable (not necessarily 
from a controlled vocabulary)."
[CF-1.0] section 3.2 says "The long_name attribute is defined by the NUG 
to contain a long descriptive name which may, for example, be used for 
labeling plots."
[COARDS] defines "long_name" in a compatible way.
[CWHDF] defines the required CHAR8 "long_name" in a compatible way.
Example in [Lynn's File]: long_name = Longitude 
 
For all variables:
"standard_name" is in [ACDD], and [CF-1.0], but not [CWHDF].
"standard_name" is defined in the [ACDD] Highly Recommended variable
attributes table as 
Later it says, "The value is from a controlled vocabulary of variable names. 
We recommend using the CF convention and the variable names from the CF 
standard name table."
Ethan said OK to Bob's suggestion: 
  later it says "The 'standard_name' variable attribute provides a 
  long descriptive name for the variable." which sounds like it was cut 
  and pasted from long_name but not modified.
[CF-1.0] section 3.3 says "A standard name is associated with a variable via 
the attribute standard_name which takes a string value comprised of a 
standard name optionally followed by one or more blanks and a standard name 
modifier (a string value from appendix C)."
See [CF Standard Names] for CF standard names.
Example in [Lynn's File]: standard_name = longitude
 
For all variables:
"units" is in [ACDD], [CF-1.0], [NETCDF], and [CWHDF].
"units" is defined in the [ACDD] Highly Recommended variable attributes 
table as "The units of the variables data values. This attributes value should
be a valid udunits string."
"units" is defined in [CF-1.0] section 3.1 as 
"The units attribute is required for all variables that represent dimensional 
quantities .... The value of the units attribute is a string that can be 
recognized by UNIDATA's Udunits package [UDUNITS], with a few exceptions that 
are given below. ...  Note that case is significant..." 
(There is a lot more information there.)
[COARDS] defines "units" in a compatible way. For coordinate variables,
"units" is required: 
"If a coordinate variable contains longitude, latitude, depth, elevation, 
date, or time values then the units attribute is mandatory; it is used to 
determine the orientation of the coordinate variable."
[CWHDF] defines the required CHAR8 "units" in a compatible way.
As of version [CWHDF]3.4, these must be Udunits compatible.
Example from [Lynn's File]: units = degrees Celsius
  (not UDUnits compatible?)
Bob's example: units = degree_C

For all variables:
"format" is in [CWHDF], but not [ACDD] or [CF-1.0].
"format" is a required CHAR8 [CWHDF] attribute, defined as 
"A FORTRAN-77 style format string, for example 'F7.2'.
Bob says we got by ignoring this, but supplying 'fraction_digits'.
 
For all variables:
"C_format" is in [CWHDF], but not [ACDD] or [CF-1.0].
"C_format" is a required CHAR8 [CWHDF] attribute, defined as 
"A C style format string, for example '%7.2f'.
Bob says we got by ignoring this, but supplying 'fraction_digits'.
 
For all variables:
"fraction_digits" is in [CWHDF], but not [ACDD] or [CF-1.0].
"fraction_digits" is a required INT32 [CWHDF] attribute, defined as 
"This is an alternative to the C or FORTRAN notation for value formatting
and is independent of the programming language."
Bob's example: fraction_digits = 2

For all variables:
"coordsys" is in [CWHDF], but not [ACDD] or [CF-1.0].
"coordsys" is a required CHAR8 [CWHDF] attribute, defined as
"A descriptive coordinate system name, the same as the global 'projection' 
attribute."
Bob says we always use "geographic"
Bob's example: coordsys = geographic


For all variables:
"scale_factor" and "add_offset" are in [CWHDF], [ACDD], [NETCDF] and [CF-1.0].
[COARDS], [CF-1.0], [ACDD], and [CWHDF]
support two attributes: 
"scale_factor" (default 1) and "add_offset" (default 0), 
where value = valueInFile * scale_factor + add_offset. 
[CWHDF] requires both or neither (FLOAT64) for calibrated data 
and also FLOAT64 "scale_factor_err" (defined as "the calibration scale error"), 
FLOAT64 "add_offset_err" (defined as "the calibration offset error") , and 
INT32 "calibrated_nt" (defined as "The HDF data type code for uncalibrated data").
Bob: is calibrated_nt = 0 appropriate?  There is no DFNT_xxx = 0 in hdf/HdfConstants.java.
Bob says we don't use these:
scale_factor = 1         //float64
scale_factor_err = 0     //float64   
add_offset = 0           //float64
add_offset_err = 0       //float64
calibrated_nt = 0        //int 32   //Better to use 6 for Float64?

For all variables:
"nav_affine" is in [CWHDF], but not [ACDD] or [CF-1.0].
"nav_affine" is an optional FLOAT64[] [CWHDF] attribute, defined as
"The navigational correction affine transform. If absent, an identity
transform is assumed."
Bob says, the identity transform is fine, so don't use this.

For vector magnitude variable:
"direction_variable" is in [CWHDF], but not [ACDD] or [CF-1.0].
"direction_variable" is an optional CHAR8 [CWHDF] attribute, 
defined as "The name of the associated SDS variable for vector direction. 
Any variable with this attribute is assumed to be the magnitude component 
of a vector field, for which the named variable is the direction component. 
The direction component is encoded as degrees clockwise from north."
Bob says, we don't provide vector data in this format, so don't use this.

"quality_flag" is in [CWHDF], but not [ACDD] or [CF-1.0].
"quality_flag" is an optional CHAR8 [CWHDF] attribute, defined as
"The name of the associated SDS variable that contains quality flag information."
Bob says, we don't provide this information, so don't use this.

"quality_mask" is in [CWHDF], but not [ACDD] or [CF-1.0].
"quality_mask" is an optional INT64 [CWHDF] attribute, defined as
"The value to use as a mask in a bitwise AND operation to isolate the quality 
bits in the SDS variable named by the 'quality_flag' attribute."
Bob says, we don't provide this information, so don't use this.

"flag_bits" is in [CWHDF], but not [ACDD] or [CF-1.0].
"flag_bits" is an optional CHAR8 [CWHDF] attribute, defined as
"The newline-separated list of flag descriptions for each bit from least 
significant to most significant. This is generally only required if this 
SDS variable contains quality flag information for another SDS variable.
Any unused bits are denoted by 'Unused'."
Bob says, we don't provide this information, so don't use this.


For coordinate variables:
"axis" is in [CF-1.0], but not [ACDD] or [CWHDF].
"axis" is not defined by [ACDD].
"axis" is defined by [CF-1.0] section 4 as 
"Because identification of a coordinate type by its units is complicated by
requiring the use of an external software package [UDUNITS], we provide two 
optional methods that yield a direct identification. 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. 
Alternatively the standard_name attribute may be used for direct identification."
"axis" is used for the coordinate variables.
LAS/Ferret seems to require it: http://ferret.wrc.noaa.gov/Ferret/LAS/README.html .
Incorrect Example in [Lynn's File]: AXIS = Y
Bob said to Lynn: it should be "axis", not "AXIS", and it is redundant (rely on standard_name?)
   ([CF-1.0] Section 2.3 says "Case is significant in netCDF names,".)
Bob now thinks: support it; some programs like it; it can't hurt.
Example: axis = X

For coordinate variables (but could/should be for all variables):
"actual_range" is in [CDC COARDS], but not [CF-1.0], [ACDD], [COARDS], or [CWHDF].
"actual_range" is defined in [CDC COARDS] as
"actual data range for variable. Same type as unpacked values."
Later, it says "The range values are used to indicate order of storage 
(e.g., 90,-90 would indicate the latitudes started with 90 and ended with -90)."
It says it is an array of length 2.
The data type is: grid=same as the grid, lat=float, lon=float, 
  time=double.
The values are in the same units as the data.
It is a standard attribute in GMT .grd netcdf files:
http://www.soest.hawaii.edu/GMT/gmt/doc/html/GMT_Docs/node147.html
It appears in netcdf/opendap examples used in this way, e.g.,
http://www.unidata.ucar.edu/software/netcdf-java/v2.2.13/javadocAll/dods/dap/DAS.html
Note that actual_range is different from valid_range, valid_min, and valid_max [CF-1.0],
but actual_range's use parallels valid_range (e.g., array of length 2).
Bob says: It is useful for the client to be able to determine the range of 
values without downloading all of them, just by looking at the metadata.
But I also see that this information can get out-of-date if the
file is subsetted by a program that is unaware of this metadata.
So it probably isn't a good idea.
Example in [Lynn's File]: actual_range = 22., 51.

For coordinate variables:
Lynn uses "point_spacing". It is not in [ACDD], [COARDS], or [CWHDF].
I don't know which standard it is from, or if it is from a standard.
It is useful for the client to be able to determine if the coordinate values
are evenly spaced without inspecting each value.
Valid values are "even" and "uneven"(?).
If the attribute is not present, the spacing of the values is indeterminate.
Example in [Lynn's File]: point_spacing = even


**************************************************************************
Time special attributes.

Sample from [Lynn's File]: long_name = "reference time"
[COARDS] gives this example from [UDUNITS] for time units: 
  "seconds since 1992-10-8 15:15:42.5 -6:00"
[COARDS] says "A time coordinate variable is identifiable from its units 
  string, alone. "
Sample from [Lynn's File]: units = "days since 1985-01-01"
Sample from [Lynn's File]: actual_range = 7540., 7549.
Sample from [Lynn's File]: point_spacing = "even"
Bob didn't use this in the old 2D netcdf files.
Bob does use these in the new 4D netcdf files (which include a time axis).

"origin" is from the LAS Intermediate NetCDF File convention
(see http://ferret.wrc.noaa.gov/LASdoc/serve/cache/90.html ).
It is the base time for the time values (the time to which
the time values are added), in the form "01-Jan-1977 00:00:00".
Bob says: for my files, always use: origin = 01-JAN-1970 00:00:00
   since I always use that origin.

**************************************************************************
Altitude/Depth special attributes.

[COARDS] defines a vertical coordinate and with a "positive" attribute.
[COARDS] says "A vertical coordinate variable will be identifiable by 
  A) units of pressure; or B) the presence of the positive attribute with a 
  value of 'up' or 'down' (case insensitive)."
Bob says: use this.
Bob's example: positive = up

**************************************************************************
Latitude attributes. 

Example in [Lynn's File]: long_name = Latitude
Bob's example: long_name = Latitude
Grid.saveAsNetCDF: this is a constant

Bob's example: standard_name = latitude
Grid.saveAsNetCDF: this is a constant

[COARDS] also requires using "degrees_north" (or an alternate spelling)
[COARDS] says "A latitude coordinate variable is identifiable from its units 
string, alone."
[CWHDF] requires [UDUNITS]-compatible units as of Version 3.4.
"degrees_north" is a valid [UDUNITS] unit.
Example in [Lynn's File]: units = degrees_north
Bob's example: units = degrees_north
Grid.saveAsNetCDF: this is a constant

coordsys = geographic

fraction_digits = &latLonFractionDigits; //int32
(The &; tags are part of Bob's FGDC system.)

Example in [Lynn's File]: point_spacing = even
Bob's example: point_spacing = even
Grid.saveAsNetCDF: this is a constant

Example in [Lynn's File]: AXIS = Y
Bob says, this is useful (LAS?) so use it. 

Example in [Lynn's File]: actual_range = 22., 51.
Bob's example: actual_range = 22.0, 51.0
Grid.saveAsNetCDF: this generated on the fly

**************************************************************************
Longitude attributes. 

Example in [Lynn's File]: long_name = Longitude
Bob's example: long_name = Longitude
Grid.saveAsNetCDF: this is a constant

Bob's example: standard_name = longitude
Grid.saveAsNetCDF: this is a constant

[COARDS] also requires using "degrees_east" (or an alternate spelling).
[COARDS] says "A longitude coordinate variable is identifiable from its units 
string, alone."
[CWHDF] requires [UDUNITS]-compatible units as of Version 3.4.
"degrees_east" is a valid [UDUNITS] unit.
Example in [Lynn's File]: units = degrees_east
Bob's example: units = degrees_east
Grid.saveAsNetCDF: this is a constant

coordsys = geographic

fraction_digits = &latLonFractionDigits; //int32
(The &; tags are part of Bob's FGDC system.)

Example in [Lynn's File]: point_spacing = even
Bob's example: point_spacing = even
Grid.saveAsNetCDF: this is a constant

Example in [Lynn's File]: AXIS = X
Bob says, don't use it. Rely on standard_name

Example in [Lynn's File] (I think she meant 225, not 215): actual_range = 215., 255.
Bob's example: actual_range = 225.0, 255.0
Grid.saveAsNetCDF: this is generated on the fly


**************************************************************************
For the actual grid data variable: 

Example from [Lynn's File]: long_name = Sea Surface Temperature mixed night and day
Bob's example: long_name = Sea Surface Temperature mixed night and day
Grid.saveAsNetCDF: &title;

See [CF Standard Names] for CF standard names.
Bob's example: standard_name = sea_surface_temperature
???Bob is in trouble: there aren't standard names for many of our datasets (see properties file).
Grid.saveAsNetCDF: 

???What about unitless data? Some web sites indicate to use "unitless".
Bob does want a placeholder; leaving it blank leaves user wondering.
Example in [Lynn's File]: units = degrees Celsius   //not UDUnits compatible
Bob's example: units = degree_Celsius
Grid.saveAsNetCDF: this is generated on the fly (<units>)


"_FillValue" is in [COARDS], [CF-1.0], [NETCDF] and [CWHDF], but not [ACDD].
"_FillValue" is defined in [CF-1.0] as 
"The scalar attribute with the name _FillValue and of the same type as its 
variable is recognized by the netCDF library as the value used to pre-fill 
disk space allocated to the 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. The _FillValue should be outside the range 
specified by valid_range (if used) for a variable. The netCDF library defines 
a default fill value for each data type (NUG section 7.16)."
[COARDS] defines "_FillValue" in a compatible way.
[COARDS] says "Since coordinate variables may not contain missing values the 
attributes _FillValue and missing_value may not be used with coordinate variables."
[CWHDF] defines this in a compatible way, but requires this for ALL variables.
Bob wrote to Peter requesting a change: [COARDS] forbids this for coordinate variables, but
  [CWHDF] requires it for all variables. 
  Can you please not require it for coordinate variables?
  Bob notes that CDAT already accepts files without "_FillValue" for coordinate variables.
  9/21/05 Peter agreed to changing it to be optional for all variables.
Bob said to Lynn: can't something be done about the round-off problem in LAS? 
  It is hard for a program to deal with automatically.
8/10/06 Bob thinks you can use NaN as missing/fill value in .nc and with opendap, 
   but just don't use the _FillValue and missing_value attributes. 
   I.e., NaN is the default missing/fill value for Float and Double data types.
   And the attributes are to be used if you want to supply finite alternatives
   to NaN.
   But in practice some programs have trouble with NaN, so don't use it.
Example from [Lynn's File]: _FillValue = -9.99999979e+33
Bob's old example: _FillValue = -1e+32  //same type as data
Bob's new example (we switched in late 2006):  _FillValue = -9999999  //same type as data
  This value is useful because it is represented exactly as a double, float, or int.
  So it is much easier for processing programs to find _FillValues in the data.

"missing_value" is in [COARDS], [CF-1.0], [NETCDF] and [CWHDF], but not [ACDD].
"missing_value" is defined in [CF-1.0] as 
"The missing_value attribute is considered deprecated by the NUG and we do not 
recommend its use. However for backwards compatibility with COARDS this 
standard continues to recognize the use of the missing_value attribute to 
indicate undefined or missing data."
[COARDS] defines "missing_value" in a compatible way (but not deprecated).
[COARDS] says "Since coordinate variables may not contain missing values the 
attributes _FillValue and missing_value may not be used with coordinate variables."
"The netCDF data type of the missing_value attribute should match the netCDF 
  data type of the data variable that it describes."
[CWHDF] defines this in a compatible way, but requires this for ALL variables.
***"In cases where the data variable is packed via the scale_value attribute, this 
  implies that the missing_value flag is likewise packed."[COARDS]
** PREFER? ** Bob considers _FillValue to be preferred over missing_value (because of deprecation).
Bob wrote to Peter requesting a change: [COARDS] forbids this for coordinate variables, but
  [CWHDF] requires it for all variables.
  Can you please not require it for coordinate variables?
  Bob notes that CDAT already accepts files without "missing_value" for coordinate variables.
  9/21/05 Peter agreed to changing it to be optional for all variables.
Bob said to Lynn, can't something be done about the round-off problem in LAS? 
  It is hard for a program to deal with automatically.
Example from [Lynn's File]: missing_value = -9.99999979e+33
Bob's old example: missing_value = -1e+32  //same type as data
Bob's new example (we switched in late 2006):  missing_value = -9999999  //same type as data
  This value is useful because it is represented exactly as a double, float, or int.
  So it is much easier for processing programs to find missing_value in the data.

"numberOfObservations" is the number of valid data points (pixels) in a give time slice.
I think this was a Lynn and Bob creation. It is not from a standard.
In Lynn's files, this is a global variable which is an array of Integer.
Bob thinks this is more appropriate as a data variable attribute,
  but I see that this information becomes inappropriate when aggregated in thredds
  and because the one value doesn't apply to all (cumulative or separate) time points.
  Future: move it to me a time-axis related variable?
Bob's example: numberOfObservations = 20376;
Grid.setStatsAttributes: this is generated on the fly (Grid.calculateStats().

"percentCoverage" is the number of valid data points (pixels) in a give time slice.
[9/28/06 I calculate it without giving land any special treatment -- I now see that Dave
would probably like it to calculate percentCoverage over water, but that is
difficult/time consuming to calculate, so I have avoided it.]
This is Bob's creation on 2006-07-12 at Dave's request. It is not from a standard.
  Future: move it to me a time-axis related variable?
Bob's example: percentCoverage = 37.654; (double)
Grid.setStatsAttributes: this is generated on the fly.

"data_min" and "data_max" are OPTIONAL attributes defined in the 
World Ocean Circulation metadata description 
(http://woce.nodc.noaa.gov/wdiu/utils/netcdf/woce_conventions/report_nov_01_v3_mtg.htm).
If present, they are of the same data type as variable,
representing the minimum and maximum of data in the data fle.

These metadata attributes are commonly seen in .nc files. 
I think the netcdf-java library adds them when writing .nc file
(http://www.unidata.ucar.edu/software/netcdf-java/tutorial/CoordinateAttributes.html)
"_CoordinateAxisType" - used by coordinate variables (e.g., "Lat", "Lon", "Height", "Time").
    I added "_CoordinateAxisType" to grids made by my code 2007-05-15.
"_CoordinateZisPositive", "up"  "down"
    I added "_CoordinateZisPositive" "up" to grids made by my code 2007-05-15.
    I added "_CoordinateZisPositive" "down" to tables made by my code 2007-05-15.    
"_coordinateSystem" - global metadata.   This seems to be the old version of _CoordinateAxes.
"_CoordinateAxes" - global metadata. This seems to be the new version (Jan 2007) of _coordinateSystem.

end of file
