Custom Query (124 matches)
Results (40 - 42 of 124)
Ticket | Resolution | Summary | Owner | Reporter | ||||
---|---|---|---|---|---|---|---|---|
#46 | fixed | Support for thematic data? | cf-standard-names@… | kfoley | ||||
Description |
I am working with scientists that generate data on various aspects of climate conditions that occurred during the Pliocene. The data is used as input for climate models. I use netCDF format to distribute data and conform to CF metatdata standards when possible. One dataset we produce is a lat/lon grid of cells, each containing an integer that indicates the nature of ground cover that is predominate in that cell. There exists no continuity between these values -- 7 does not indicate an intermediate form between 6 and 8. Is there support for this thematic data in the CF standards that I have missed or is there some possibility of including it? Thank you, Kevin Foley USGS |
|||||||
#143 | fixed | Supplement the definitions of dimensionless vertical coordinates | davidhassell | jonathan | ||||
Description |
1 TitleSupplement the definitions of dimensionless vertical coordinates 2 ModeratorRich Signell 3 Purposes
4 Status quo and benefitsAt the moment it is difficult for a data user to know exactly what the computed vertical coordinate is. For example, does the ocean sigma coordinate give you a height with respect to a geopotential surface or a reference ellipsoid, and precisely what is that datum e.g. NAVD88? These changes are intended to make it easier. 5 Detailed proposalInsert a new section heading "4.3.3 Parameterized Vertical Coordinate" after the sentence "The units attribute is not required ..." in section 4.3.2. Thus, the remainder of that section, about formula terms etc., will become a new section under the new heading. Amend the existing first paragraph of this new section from the existing text:
to read as follows:
In this section, in the sentence after Example 4.3, change "Appendix D, Dimensionless Vertical Coordinates" to "Appendix D, Parameterized Vertical Coordinates". In section 5.6, replace the existing paragraph
with
In Appendix A, between the entries for compress and Conventions, insert an entry for computed_standard_name, Type S, Use C, Link "Section 4.3.3, Parameterized Vertical Coordinate", Description "Indicates the standard name, from the standard name table, of the parameterized dimensional vertical coordinate values computed according to the formula in the definition." In Appendix A, change the Link for formula_terms to "Section 4.3.3, Parameterized Vertical Coordinate". Rename Appendix D as "Parameterized vertical coordinates". Change the first sentence of Appendix D from "The definitions given here allow an application to compute dimensional coordinate values from the dimensionless ones and associated variables." to "The definitions given here allow an application to compute dimensional coordinate values from the parameterized (usually dimensionless) ones and associated variables." In the first paragraph of Appendix D, change "where term is a keyword" to "where term is a case-insensitive keyword". Append the following as a third paragraph in the preamble of Appendix D:
In the following, it will be noticed that some formula terms do not have defined standard names at the moment. Of course, names could be defined, but it is not essential because their purpose is identifiable from the formula_terms attribute. However, standard_names have been proposed below for constants in the formula which don't depend on level e.g. reference air pressure. Append the following paragraph to the definition of "Atmosphere natural log pressure coordinate":
Append the following paragraph to the definition of "Atmosphere sigma coordinate":
Append the following paragraph to the definition of "Atmosphere hybrid sigma pressure coordinate":
In the definition of "Atmosphere hybrid height coordinate", change "z(n,k,j,i) is the height above the geoid (approximately mean sea level) at gridpoint (k,j,i) and time (n) , orog(n,j,i) is the height of the surface above the geoid" to "z(n,k,j,i) is the height above the datum (e.g. the geoid, which is approximately mean sea level) at gridpoint (k,j,i) and time (n) , orog(n,j,i) is the height of the surface above the datum", and replace the final paragraph "There is no dimensionless ..." with the following.
In the definition of "Atmosphere smooth level vertical (SLEVE) coordinate", change "z(n,k,j,i) is the height above the geoid (approximately mean sea level) at gridpoint (k,j,i) and time (n), ztop is the height of the top of the model" to "z(n,k,j,i) is the height above the datum (e.g. the geoid, which is approximately mean sea level) at gridpoint (k,j,i) and time (n), ztop is the height of the top of the model above the datum", change "the large and small parts of the topography" to "the large-scale and small-scale components of the topography, and a, b1 and b2 are all functions of the dimensionless SLEVE coordinate" (for the sake of clarification), delete the sentence "The hybrid height coordinate for level k is defined as a(k)*ztop" (which appears to be in the wrong section) and append the following paragraph:
In the definition of "Ocean sigma coordinate", replace "z(n,k,j,i) is height, positive upwards, relative to ocean datum (e.g. mean sea level) at gridpoint (n,k,j,i), eta(n,j,i) is the height of the ocean surface, positive upwards, relative to ocean datum at gridpoint (n,j,i)" with "z(n,k,j,i) is height (positive upwards) relative to the datum (e.g. mean sea level) at gridpoint (n,k,j,i), eta(n,j,i) is the height of the sea surface (positive upwards) relative to the datum at gridpoint (n,j,i)", replace "depth(j,i) is the distance from ocean datum to sea floor (positive value) at horizontal gridpoint (j,i)" with "depth(j,i) is the distance (a positive value) from the datum to the sea floor at horizontal gridpoint (j,i)", and append the following paragraph:
In the definition of "Ocean s-coordinate", make the same replacements as for "Ocean sigma coordinate", and append the following paragraph:
In the definition of "Ocean sigma over z coordinate", make the same replacements as for "Ocean sigma coordinate", after "Above depth depth_c there are nsigma layers" insert "and below this depth the levels are surfaces of constant height zlev (positive upwards) relative to the datum" (this definition is omitted in the current text), and append the following paragraph:
In the definition of "Ocean double sigma coordinate", make the same replacements as for "Ocean sigma coordinate" regarding z and depth (there is no eta in this case), and append the following paragraph:
At the end of Appendix D, insert the following table: Table D.1. Consistent sets of values for standard_name and computed_standard_name for the formula terms indicated.
In the conformance document, rename "4.3.2 Dimensionless Vertical Coordinates" to "4.3.3 Parameterized Vertical Coordinate", and append these new requirements:
If this ticket is agreed, the following standard_names will be proposed: air_pressure_at_top_of_atmosphere_model altitude_at_top_of_atmosphere_model reference_air_pressure_for_atmosphere_vertical_coordinate height_above_geopotential_datum_at_top_of_atmosphere_model height_above_geopotential_datum surface_height_above_geopotential_datum sea_surface_height_above_geopotential_datum sea_floor_depth_below_geopotential_datum sea_floor_depth_below_reference_ellipsoid height_above_sea_level Jonathan |
|||||||
#144 | fixed | Subconvention for associated files, proposed for use in CMIP6 | cf-conventions@… | jonathan | ||||
Description |
1 TitleSubconvention for associated files 2 ModeratorBalaji 3 PurposesCMIP6, like CMIP5, will store cell_measures variables in a different file from the data variables to which they belong. This is to save storage space, but it is not legal in CF, which is a convention that so far applies only to individual self-contained netCDF files. To relax that restriction requires regarding two or more files as though they were a single dataset. Rules for aggregating files are needed. In this ticket a simple mechanism is proposed which is sufficient for CMIP6 to allow one file to refer to another file. Note that the file referred to is not necessarily identified by name, because this is fragile and caused some difficulties in CMIP5. This proposal does not say exactly how the file should be found. A further convention specifically for CMIP6, and not part of CF, will be needed for that, and other users of this subconvention would similarly have to adopt their own rule. 4 Status quo and benefitsCMIP6 files will not be CF-conforming without this change. Legalising them is a benefit, and the mechanism will probably be useful in other situations. This proposal arose from email discussions involving Balaji, Jonathan, Steve Griffies and others in September 2014 during discussions about the Ocean Model Development Panel recommendations of diagnostics for CMIP6. 5 Detailed proposalThe proposal is to introduce a subconvention of CF i.e. conventions which are not part of CF, but intended to be used in combination with CF. It is proposed to insert the following text as a named (but not numbered) section of the CF standard document, before Appendix A. The title of the section will be Subconvention for associated files and the text is below. In addition to the following new section, in Table A.1 of Appendix A insert an entry for associated_files, type S, use G, link "Associated files subconvention", description "Indicates where files containing metadata variables can be found". CF is a convention for individual netCDF files, which implies that if a data variable refers to another variable containing metadata, the variables must be in the same file. This subconvention provides a mechanism to allow data variables in one file to refer to metadata variables in another file or files. When this subconvention is used, the netCDF file containing the data variable should contain CF-n/associated-files in its global Conventions attribute, where n is the CF version number to which it conforms. The optional global attribute associated_files of the file containing the data variable indicates where the files containing metadata variables can be found. This attribute is a string whose syntax is not standardised. For instance, it could the path to a file, a URL of a file, or a URL of a website where the required file could be found (thus requiring human intervention). Applications which use this subconvention may define their own rules for the syntax and the interpretation of the associated_files attribute. The metadata variables to which this subconvention applies are those identified by the coordinates, formula_terms, grid_mapping and cell_measures attributes. These metadata variables are identified by name. The named variables may be stored in either the same file as the data variable which refers to them, as usual, or in other files, provided that
Example A file containing a data variable: dimensions: lat=73; lon=96; level=20; variables: float temperature(level,lat,lon); temperature:cell_measures="area: areacell"; temperature:standard_name="air_temperature"; temperature:standard_name="degC"; // global attributes: :Conventions="CF-1.7/associated-files" ; :associated_files="http://some.web.site/areacell.nc"; In this example, the associated_files attribute gives the URL of this file, which contains a metadata variable: dimensions: lat=73; lon=96; variables: float areacell(lat,lon); areacell:units="m2"; // global attributes: :Conventions="CF-1.7" ; The variable areacell would need to be in the same file as temperature according to standard CF. This subconvention allows it to be stored in a different file. It would be an error if there was a variable called areacell in both files, since it would be ambiguous which should be used. It would be an error if the latitude and longitude dimensions had names other than lat and lon, or different sizes e.g. lat=180, in the second file, because they must correspond to dimensions of the data variable in the first file. |