CF Metadata: Ticket #143: Supplement the definitions of dimensionless vertical coordinates
https://cf-trac.llnl.gov/trac/ticket/143
<h2 id="a1Title">1 Title</h2>
<p>
Supplement the definitions of dimensionless vertical coordinates
</p>
<h2 id="a2Moderator">2 Moderator</h2>
<p>
Rich Signell
</p>
<h2 id="a3Purposes">3 Purposes</h2>
<ol><li>Rename dimensionless coordinates as parameterized coordinates because one of them (hybrid height) is not dimensionless, and dimensionlessness is not their defining characteristic.
</li></ol><ol start="2"><li>Define a new attribute to supply the <tt>standard_name</tt> of the dimensional coordinates computed by the formula. This may depend on the <tt>standard_name</tt> of one or more of the terms. Spell out the possibilities for each case in Appendix D and correct some errors.
</li></ol><ol start="3"><li>Point out that some vertical coordinates refer to a vertical datum surface which is described by <tt>grid_mapping</tt> information.
</li></ol><h2 id="a4Statusquoandbenefits">4 Status quo and benefits</h2>
<p>
At 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.
</p>
<h2 id="a5Detailedproposal">5 Detailed proposal</h2>
<p>
Insert a new section heading "4.3.3 Parameterized Vertical Coordinate" after the sentence "The <tt>units</tt> 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.
</p>
<p>
Amend the existing first paragraph of this new section from the existing text:
</p>
<blockquote>
<p>
For dimensionless vertical coordinates we extend the COARDS standard by making use of the <tt>standard_name</tt> attribute to associate a coordinate with its definition from Appendix D, <em>Dimensionless Vertical Coordinates</em>. The definition provides a mapping between the dimensionless coordinate values and dimensional values that can positively and uniquely indicate the location of the data. A new attribute, <tt>formula_terms</tt>, is used to associate terms in the definitions with variables in a netCDF file. To maintain backwards compatibility with COARDS the use of these attributes is not required, but is strongly recommended.
</p>
</blockquote>
<p>
to read as follows:
</p>
<blockquote>
<p>
In some cases dimensional vertical coordinates are parameterized as a function of horizontal as well as vertical location and therefore cannot be stored in the one-dimensional vertical coordinate variable, which in most of these cases is dimensionless. The <tt>standard_name</tt> of the vertical coordinate variable can be used to find the definition of the associated dimensional vertical coordinate in Appendix D, <em>Parameterized Vertical Coordinates</em>. The definition provides a mapping between the parameterized coordinate values and dimensional values that can positively and uniquely indicate the location of the data. The <tt>formula_terms</tt> attribute can be used to associate terms in the definitions with variables in a netCDF file, and the <tt>computed_standard_name</tt> attribute can be used to supply the <tt>standard_name</tt> of the dimensional vertical coordinate values computed according to the definition. To maintain backwards compatibility with COARDS the use of these attributes is not required, but is strongly recommended. Some of the definitions may be supplemented with information stored in the <tt>grid_mapping</tt> variable about the datum used as a vertical reference (e.g. geoid, other geopotential datum or reference ellipsoid; see Section 5.6, <em>Horizontal Coordinate Reference Systems, Grid Mappings, and Projections</em> and Appendix F, <em>Grid Mappings</em>).
</p>
</blockquote>
<p>
In this section, in the sentence after Example 4.3, change "Appendix D, <em>Dimensionless Vertical Coordinates</em>" to "Appendix D, <em>Parameterized Vertical Coordinates</em>".
</p>
<p>
In section 5.6, replace the existing paragraph
</p>
<blockquote>
<p>
When the coordinate variables for a horizontal grid are longitude and latitude, a grid mapping variable with <tt>grid_mapping_name</tt> of <tt>latitude_longitude</tt> may be used to specify the ellipsoid and prime meridian.
</p>
</blockquote>
<p>
with
</p>
<blockquote>
<p>
The <tt>grid_mapping</tt> variable may identify datums (such as the reference ellipsoid, the geoid or the prime meridian) for horizontal or vertical coordinates. Therefore a grid mapping variable may be needed when the coordinate variables for a horizontal grid are longitude and latitude. The <tt>grid_mapping_name</tt> of <tt>latitude_longitude</tt> should be used in this case.
</p>
</blockquote>
<p>
In Appendix A, between the entries for <tt>compress</tt> and <tt>Conventions</tt>, insert an entry for <tt>computed_standard_name</tt>, 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."
</p>
<p>
In Appendix A, change the Link for <tt>formula_terms</tt> to "Section 4.3.3, Parameterized Vertical Coordinate".
</p>
<p>
Rename Appendix D as "Parameterized vertical coordinates".
</p>
<p>
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."
</p>
<p>
In the first paragraph of Appendix D, change "where <tt>term</tt> is a keyword" to "where <tt>term</tt> is a case-insensitive keyword".
</p>
<p>
Append the following as a third paragraph in the preamble of Appendix D:
</p>
<blockquote>
<p>
The variables containing the terms may optionally have <tt>standard_name</tt> attributes, with values as indicated in this Appendix. The <tt>standard_name</tt> of the dimensional coordinate values which are computed by the formula may optionally be specified by the <tt>computed_standard_name</tt> attribute of the vertical coordinate variable, as indicated in this Appendix. A <tt>computed_standard_name</tt> is uniquely implied by the formula in some cases, while in others it depends on the <tt>standard_name</tt> of one or more of the terms, with which it must be consistent.
</p>
</blockquote>
<p>
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 <tt>formula_terms</tt> attribute. However, <tt>standard_name</tt>s have been proposed below for constants in the formula which don't depend on level e.g. reference air pressure.
</p>
<p>
Append the following paragraph to the definition of "Atmosphere natural log pressure coordinate":
</p>
<blockquote>
<p>
The <tt>standard_name</tt> of <tt>p0</tt> is <tt>reference_air_pressure_for_atmosphere_vertical_coordinate</tt>. The <tt>computed_standard_name</tt> is <tt>air_pressure</tt>.
</p>
</blockquote>
<p>
Append the following paragraph to the definition of "Atmosphere sigma coordinate":
</p>
<blockquote>
<p>
The <tt>standard_name</tt> of <tt>ptop</tt> is <tt>air_pressure_at_top_of_atmosphere_model</tt>, and of <tt>ps</tt> is <tt>surface_air_pressure</tt>. The <tt>computed_standard_name</tt> is <tt>air_pressure</tt>.
</p>
</blockquote>
<p>
Append the following paragraph to the definition of "Atmosphere hybrid sigma pressure coordinate":
</p>
<blockquote>
<p>
The <tt>standard_name</tt> of <tt>p0</tt> is <tt>reference_air_pressure_for_atmosphere_vertical_coordinate</tt>, and of <tt>ps</tt> is <tt>surface_air_pressure</tt>. The <tt>computed_standard_name</tt> is <tt>air_pressure</tt>. No <tt>standard_name</tt> has been defined for <tt>a</tt>, <tt>b</tt> or <tt>ap</tt>.
</p>
</blockquote>
<p>
In the definition of "Atmosphere hybrid height coordinate", change "<tt>z(n,k,j,i)</tt> is the height above the geoid (approximately mean sea level) at gridpoint <tt>(k,j,i)</tt> and time <tt>(n)</tt> , <tt>orog(n,j,i)</tt> is the height of the surface above the geoid" to "<tt>z(n,k,j,i)</tt> is the height above the datum (e.g. the geoid, which is approximately mean sea level) at gridpoint <tt>(k,j,i)</tt> and time <tt>(n)</tt> , <tt>orog(n,j,i)</tt> is the height of the surface above the datum", and replace the final paragraph "There is no dimensionless ..." with the following.
</p>
<blockquote>
<p>
The <tt>standard_name</tt> of <tt>orog</tt> may be <tt>surface_altitude</tt> (i.e. above the geoid) or <tt>surface_height_above_geopotential_datum</tt>. The <tt>computed_standard_name</tt> is <tt>altitude</tt> or <tt>height_above_geopotential_datum</tt> in these cases respectively. No <tt>standard_name</tt> has been defined for <tt>b</tt>. There is no dimensionless coordinate because <tt>a</tt>, which has the <tt>standard_name</tt> of <tt>atmosphere_hybrid_height_coordinate</tt>, is the best choice for a level-dependent but geographically constant coordinate.
</p>
</blockquote>
<p>
In the definition of "Atmosphere smooth level vertical (SLEVE) coordinate", change "<tt>z(n,k,j,i)</tt> is the height above the geoid (approximately mean sea level) at gridpoint <tt>(k,j,i)</tt> and time <tt>(n)</tt>, <tt>ztop</tt> is the height of the top of the model" to "<tt>z(n,k,j,i)</tt> is the height above the datum (e.g. the geoid, which is approximately mean sea level) at gridpoint <tt>(k,j,i)</tt> and time <tt>(n)</tt>, <tt>ztop</tt> 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 <tt>a</tt>, <tt>b1</tt> and <tt>b2</tt> are all functions of the dimensionless SLEVE coordinate" (for the sake of clarification), delete the sentence "The hybrid height coordinate for level <tt>k</tt> is defined as <tt>a(k)*ztop</tt>" (which appears to be in the wrong section) and append the following paragraph:
</p>
<blockquote>
<p>
The <tt>standard_name</tt> of <tt>ztop</tt> may be <tt>altitude_at_top_of_atmosphere_model</tt> (i.e. above the geoid) or <tt>height_above_geopotential_datum_at_top_of_atmosphere_model</tt>. The <tt>computed_standard_name</tt> is <tt>altitude</tt> or <tt>height_above_geopotential_datum</tt> in these cases respectively. No <tt>standard_name</tt> has been defined for <tt>b1</tt>, <tt>zsurf1</tt>, <tt>b2</tt> or <tt>zsurf2</tt>.
</p>
</blockquote>
<p>
In the definition of "Ocean sigma coordinate", replace "<tt>z(n,k,j,i)</tt> is height, positive upwards, relative to ocean datum (e.g. mean sea level) at gridpoint <tt>(n,k,j,i)</tt>, <tt>eta(n,j,i)</tt> is the height of the ocean surface, positive upwards, relative to ocean datum at gridpoint <tt>(n,j,i)</tt>" with "<tt>z(n,k,j,i)</tt> is height (positive upwards) relative to the datum (e.g. mean sea level) at gridpoint <tt>(n,k,j,i)</tt>, <tt>eta(n,j,i)</tt> is the height of the sea surface (positive upwards) relative to the datum at gridpoint <tt>(n,j,i)</tt>", replace "<tt>depth(j,i)</tt> is the distance from ocean datum to sea floor (positive value) at horizontal gridpoint <tt>(j,i)</tt>" with "<tt>depth(j,i)</tt> is the distance (a positive value) from the datum to the sea floor at horizontal gridpoint <tt>(j,i)</tt>", and append the following paragraph:
</p>
<blockquote>
<p>
The <tt>standard_name</tt>s for <tt>eta</tt> and <tt>depth</tt> and the <tt>computed_standard_name</tt> must be one of the consistent sets shown in Table D.1.
</p>
</blockquote>
<p>
In the definition of "Ocean s-coordinate", make the same replacements as for "Ocean sigma coordinate", and append the following paragraph:
</p>
<blockquote>
<p>
The <tt>standard_name</tt>s for <tt>eta</tt> and <tt>depth</tt> and the <tt>computed_standard_name</tt> must be one of the consistent sets shown in Table D.1. No <tt>standard_name</tt> has been defined for <tt>a</tt>, <tt>b</tt> or <tt>depth_c</tt>.
</p>
</blockquote>
<p>
In the definition of "Ocean sigma over z coordinate", make the same replacements as for "Ocean sigma coordinate", after "Above depth <tt>depth_c</tt> there are <tt>nsigma</tt> layers" insert "and below this depth the levels are surfaces of constant height <tt>zlev</tt> (positive upwards) relative to the datum" (this definition is omitted in the current text), and append the following paragraph:
</p>
<blockquote>
<p>
The <tt>standard_name</tt>s for <tt>eta</tt>, <tt>depth</tt>, <tt>zlev</tt> and the <tt>computed_standard_name</tt> must be one of the consistent sets shown in Table D.1. No <tt>standard_name</tt> has been defined for <tt>depth_c</tt> or <tt>nsigma</tt>.
</p>
</blockquote>
<p>
In the definition of "Ocean double sigma coordinate", make the same replacements as for "Ocean sigma coordinate" regarding <tt>z</tt> and <tt>depth</tt> (there is no <tt>eta</tt> in this case), and append the following paragraph:
</p>
<blockquote>
<p>
The <tt>standard_name</tt> for <tt>depth</tt> and the <tt>computed_standard_name</tt> must be one of the consistent sets shown in Table D.1. No <tt>standard_name</tt> has been defined for <tt>z1</tt>, <tt>z2</tt>, <tt>a</tt>, <tt>href</tt> or <tt>k_c</tt>.
</p>
</blockquote>
<p>
At the end of Appendix D, insert the following table:
</p>
<p>
<strong>Table D.1.</strong> Consistent sets of values for <tt>standard_name</tt> and <tt>computed_standard_name</tt> for the formula terms indicated.
</p>
<table class="wiki">
<tr><td><tt>computed_standard_name</tt> of <tt>altitude</tt> with <tt>standard_name</tt> of <tt>altitude</tt> for <tt>zlev</tt>, <tt>sea_surface_height_above_geoid</tt> for <tt>eta</tt> and <tt>sea_floor_depth_below_geoid</tt> for <tt>depth</tt>.
</td></tr><tr><td><tt>computed_standard_name</tt> of <tt>height_above_geopotential_datum</tt> with <tt>standard_name</tt> of <tt>height_above_geopotential_datum</tt> for <tt>zlev</tt>, <tt>sea_surface_height_above_geopotential_datum</tt> for <tt>eta</tt> and <tt>sea_floor_depth_below_geopotential_datum</tt> for <tt>depth</tt>.
</td></tr><tr><td><tt>computed_standard_name</tt> of <tt>height_above_reference_ellipsoid</tt> with <tt>standard_name</tt> of <tt>height_above_reference_ellipsoid</tt> for <tt>zlev</tt>, <tt>sea_surface_height_above_reference_ellipsoid</tt> for <tt>eta</tt> and <tt>sea_floor_depth_below_reference_ellipsoid</tt> for <tt>depth</tt>.
</td></tr><tr><td><tt>computed_standard_name</tt> of <tt>height_above_sea_level</tt> with <tt>standard_name</tt> of <tt>height_above_sea_level</tt> for <tt>zlev</tt>, <tt>sea_surface_height_above_sea_level</tt> for <tt>eta</tt> and <tt>sea_floor_depth_below_sea_level</tt> for <tt>depth</tt>.
</td></tr></table>
<p>
In the conformance document, rename "4.3.2 Dimensionless Vertical Coordinates" to "4.3.3 Parameterized Vertical Coordinate", and append these new requirements:
</p>
<ul><li>Where indicated by the appropriate definition in Appendix D, the <tt>standard_name</tt> attributes of variables named by the <tt>formula_terms</tt> attribute must be consistent with the <tt>standard_name</tt> of the coordinate variable it is attached to, according to the appropriate definition in Appendix D.
</li><li>The <tt>computed_standard_name</tt> attribute is only allowed on a coordinate variable which has a <tt>formula_terms</tt> attribute.
</li><li>The <tt>computed_standard_name</tt> attribute is a string whose value must be consistent with the <tt>standard_name</tt> of the coordinate variable it is attached to, and in some cases also with the <tt>standard_name</tt> attributes of variables named by the <tt>formula_terms</tt> attribute, according to the appropriate definition in Appendix D.
</li></ul><p>
If this ticket is agreed, the following <tt>standard_names</tt> will be proposed:
</p>
<pre class="wiki">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
</pre><p>
Jonathan
</p>
en-usCF Metadatahttps://cf-trac.llnl.gov/trac/chrome/site/cf_logo.png
https://cf-trac.llnl.gov/trac/ticket/143
Trac 1.0.20jonathanTue, 08 Sep 2015 07:42:27 GMT
https://cf-trac.llnl.gov/trac/ticket/143#comment:1
https://cf-trac.llnl.gov/trac/ticket/143#comment:1
<p>
This is an addition to the detailed proposal above.
</p>
<p>
In the CDL of Example 4.3, insert this new attribute:
</p>
<pre class="wiki"> lev:computed_standard_name = "air_pressure" ;
</pre><p>
Modify the reference to "Appendix D, <em>Dimensionless Vertical Coordinates</em>" to read "Appendix D, <em>Parameterized Vertical Coordinates</em>". Append to the text about the example: "The <tt>computed_standard_name</tt> attribute indicates that the values in variable <tt>p</tt> would have a <tt>standard_name</tt> of <tt>air_pressure</tt>.
</p>
<p>
We could add examples of other kinds of parameterized vertical coordinate from Appendix D, perhaps illustrating the use of <tt>grid_mapping</tt> as well for the precise description of the datum. Which ones would be useful?
</p>
<p>
Jonathan
</p>
TicketrsignellTue, 08 Sep 2015 09:54:58 GMT
https://cf-trac.llnl.gov/trac/ticket/143#comment:2
https://cf-trac.llnl.gov/trac/ticket/143#comment:2
<p>
Jonathan,
Thanks for proposing this needed functionality for CF.
</p>
<p>
Do you think we could say "derived vertical coordinate", "computed vertical coordinate" or "calculated vertical coordinate" rather than "parameterized coordinate"?
</p>
<p>
Maybe it's just my modeling background, but "parameterized" sounds like we are estimating something that we don't fully know how to calculate.
</p>
TicketjonathanTue, 08 Sep 2015 16:57:44 GMT
https://cf-trac.llnl.gov/trac/ticket/143#comment:3
https://cf-trac.llnl.gov/trac/ticket/143#comment:3
<p>
Dear Rich
</p>
<p>
Thanks for commenting on this ticket and 118.
</p>
<p>
Yes, I agree that "parameterized" has that drawback. By that word I meant "parametric" in the mathematical sense of "parametric formulae". Would "parametric" be any good? Your alternatives are good; of them, I think "computed" would be best, because it's consistent with my suggestion of <tt>computed_standard_name</tt>. I chose "computed" there because it was the best word I could think of for the output of the formula.
</p>
<p>
Cheers
</p>
<p>
Jonathan
</p>
TicketrsignellTue, 08 Sep 2015 18:18:47 GMT
https://cf-trac.llnl.gov/trac/ticket/143#comment:4
https://cf-trac.llnl.gov/trac/ticket/143#comment:4
<p>
I prefer <tt>computed_vertical_coordinate</tt> over <tt>parametric_vertical_coordinate</tt> but both are better than <tt>parameterized_vertical_coordinate</tt>
</p>
TicketjonathanThu, 10 Sep 2015 13:02:28 GMT
https://cf-trac.llnl.gov/trac/ticket/143#comment:5
https://cf-trac.llnl.gov/trac/ticket/143#comment:5
<p>
OK. Let's say <em>Computed vertical coordinate</em> rather than <em>Parameterized vertical coordinate</em> throughout the proposal, which is otherwise unaltered.
</p>
<p>
Following David's comment on ticket 118, I note here that, if this proposal is agreed, I will include in the related proposal to be made on the email list for standard names the suggestion that the definitions of the relevant height/depth coordinates should point out that <tt>grid_mapping</tt> can be used to specify the geoid, geopotential datum or reference ellipsoid which is used as the reference surface.
</p>
<p>
Jonathan
</p>
TicketdavidhassellWed, 23 Sep 2015 08:10:57 GMT
https://cf-trac.llnl.gov/trac/ticket/143#comment:6
https://cf-trac.llnl.gov/trac/ticket/143#comment:6
<p>
Replying to <a class="ticket" href="https://cf-trac.llnl.gov/trac/ticket/143#comment:5" title="Comment 5">jonathan</a>:
</p>
<p>
Dear Jonathan and Rich,
</p>
<blockquote class="citation">
<p>
OK. Let's say <em>Computed vertical coordinate</em> rather than <em>Parameterized vertical coordinate</em> throughout the proposal, which is otherwise unaltered.
</p>
</blockquote>
<p>
I'm confused now! The original proposal talks about parametric vertical coordinates (e.g. sigma) and computed vertical coordinates (e.g. air_pressure, which are non-parametric). I don't understand the most recent suggestion to call (e.g.) sigma a computed vertical coordinate. Apologies if I have misunderstood.
</p>
<p>
I like "parametric vertical coordinate" in place of "dimensionless vertical coordinate", but am less keen on the attribute <tt>computed_standard_name</tt>. I would prefer <tt>derived_standard_name</tt> or <tt>nonparametric_standard_name</tt>, but I wouldn't object to <tt>computed_standard_name</tt> if that was the general view point.
</p>
<p>
All the best,
</p>
<p>
David
</p>
TicketrsignellWed, 23 Sep 2015 11:53:04 GMT
https://cf-trac.llnl.gov/trac/ticket/143#comment:7
https://cf-trac.llnl.gov/trac/ticket/143#comment:7
<p>
It's not <tt>sigma</tt> that is the computed vertical coordinate, but the z coordinate values computed from the formula terms. Since you use a formula to compute the vertical coordinate for all these dimensionless coordinates, it seemed natural to call them all "computed" although "derived" would be okay by me as well.
</p>
TicketjonathanWed, 23 Sep 2015 13:32:09 GMT
https://cf-trac.llnl.gov/trac/ticket/143#comment:8
https://cf-trac.llnl.gov/trac/ticket/143#comment:8
<p>
Dear David and Rich
</p>
<p>
I didn't mean that "dimensionless vertical coordinates" are being renamed "computed vertical coordinates". I agree, that wouldn't be right. If we say "computed" or "derived" in renaming the section and appendix which deals with them, we shift the emphasis from the input (the usually dimensionless coordinate, like sigma) to the output (the computed dimensional coordinate, like air pressure). However, I didn't consider the text carefully enough. Sorry about that. We still do need a name for the input. It's not right to call it "dimensionless "(since they aren't all dimensionless), and Rich didn't like "parameterized". However, "parametric" seems acceptable. In that case, the section should read
</p>
<blockquote>
<p>
In some cases dimensional vertical coordinates are a function of horizontal location as well as parameters which depend on vertical location, and therefore cannot be stored in the one-dimensional vertical coordinate variable, which is in most of these cases is dimensionless. The <tt>standard_name</tt> of the parametric (usually dimensionless) vertical coordinate variable can be used to find the definition of the associated dimensional vertical coordinate in Appendix D, <em>Computed Vertical Coordinates</em>. The definition provides a mapping between the parametric vertical coordinate values and dimensional values that can positively and uniquely indicate the location of the data. The <tt>formula_terms</tt> attribute can be used to associate terms in the definitions with variables in a netCDF file, and the <tt>computed_standard_name</tt> attribute can be used to supply the <tt>standard_name</tt> of the dimensional vertical coordinate values computed according to the definition. To maintain backwards compatibility with COARDS the use of these attributes is not required, but is strongly recommended. Some of the definitions may be supplemented with information stored in the <tt>grid_mapping</tt> variable about the datum used as a vertical reference (e.g. geoid, other geopotential datum or reference ellipsoid; see Section 5.6, <em>Horizontal Coordinate Reference Systems, Grid Mappings, and Projections</em> and Appendix F, <em>Grid Mappings</em>).
</p>
</blockquote>
<p>
and the first sentence of Appendix D should change 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 parametric vertical coordinate values (usually dimensionless) and associated variables."
</p>
<p>
Does that help? Have I missed any other places where we should say "parametric"?
</p>
<p>
I don't mind whether we say "computed" or "derived", though I think "computed" is more obvious. If we say "derived", for consistency the attribute should be <tt>derived_standard_name</tt>, which would also be OK, I think.
</p>
<p>
What do you think?
</p>
<p>
Cheers
</p>
<p>
Jonathan
</p>
TicketdavidhassellThu, 24 Sep 2015 14:19:53 GMT
https://cf-trac.llnl.gov/trac/ticket/143#comment:9
https://cf-trac.llnl.gov/trac/ticket/143#comment:9
<p>
Dear Jonathan and Rich,
</p>
<p>
I'm all on board with this, except for the repeated use of the phrase "dimensional vertical coordinate values" to mean "computed vertical coordinate values". My objection is that, as you rightly point out, the parametric coordinate values may also be dimensional and so "dimensional" as a label for "computed" could be confusing.
</p>
<p>
Could they simply be called "computed coordinate values" (suggested changes in <strong>bold</strong>):
</p>
<blockquote>
<p>
In some cases dimensional vertical coordinates are a function of horizontal location as well as parameters which depend on vertical location, and therefore cannot be stored in the one-dimensional vertical coordinate variable, which is in most of these cases is dimensionless. The <tt>standard_name</tt> of the parametric (usually dimensionless) vertical coordinate variable can be used to find the definition of the associated <strong>computed (always dimensional)</strong> vertical coordinate in Appendix D, Computed Vertical Coordinates. The definition provides a mapping between the parametric vertical coordinate values and <strong>computed</strong> values that can positively and uniquely indicate the location of the data. The <tt>formula_terms</tt> attribute can be used to associate terms in the definitions with variables in a netCDF file, and the <tt>computed_standard_name</tt> attribute can be used to supply the standard_name of the <strong>computed</strong> vertical coordinate values computed according to the definition. To maintain backwards compatibility with COARDS the use of these attributes is not required, but is strongly recommended. Some of the definitions may be supplemented with information stored in the <tt>grid_mapping variable</tt> about the datum used as a vertical reference (e.g. geoid, other geopotential datum or reference ellipsoid; see Section 5.6, Horizontal Coordinate Reference Systems, Grid Mappings, and Projections and Appendix F, Grid Mappings).
</p>
</blockquote>
<p>
On reflection, I might prefer <tt>computed_standard_name</tt> to <tt>derived_standard_name</tt>, afterall.
</p>
<p>
All the best,
</p>
<p>
David
</p>
TicketjonathanThu, 24 Sep 2015 14:56:54 GMT
https://cf-trac.llnl.gov/trac/ticket/143#comment:10
https://cf-trac.llnl.gov/trac/ticket/143#comment:10
<p>
Dear David
</p>
<p>
Thank you for thinking about it. I am happy with your proposed text.
</p>
<p>
Is it OK for you, Rich?
</p>
<p>
Cheers
</p>
<p>
Jonathan
</p>
TicketrsignellWed, 30 Sep 2015 08:45:28 GMT
https://cf-trac.llnl.gov/trac/ticket/143#comment:11
https://cf-trac.llnl.gov/trac/ticket/143#comment:11
<p>
Yes, I'm okay with this slight modification.
</p>
TicketrsignellTue, 20 Oct 2015 19:11:07 GMT
https://cf-trac.llnl.gov/trac/ticket/143#comment:12
https://cf-trac.llnl.gov/trac/ticket/143#comment:12
<p>
Since Jonathan, David and I support this and no-one has commented for more than three weeks, this proposal should be marked as accepted for the next version of CF.
</p>
<p>
Rich (Moderator)
</p>
TicketrhattersleyWed, 20 Jan 2016 22:05:22 GMT
https://cf-trac.llnl.gov/trac/ticket/143#comment:13
https://cf-trac.llnl.gov/trac/ticket/143#comment:13
<p>
Applied via <a class="ext-link" href="https://github.com/cf-convention/cf-conventions/pull/69"><span class="icon"></span>https://github.com/cf-convention/cf-conventions/pull/69</a>
</p>
TicketdavidhassellWed, 04 Jan 2017 14:36:10 GMTowner, status changed
https://cf-trac.llnl.gov/trac/ticket/143#comment:14
https://cf-trac.llnl.gov/trac/ticket/143#comment:14
<ul>
<li><strong>owner</strong>
changed from <em>cf-conventions@…</em> to <em>davidhassell</em>
</li>
<li><strong>status</strong>
changed from <em>new</em> to <em>accepted</em>
</li>
</ul>
Ticketpainter1Thu, 09 Mar 2017 22:35:12 GMT
https://cf-trac.llnl.gov/trac/ticket/143#comment:15
https://cf-trac.llnl.gov/trac/ticket/143#comment:15
<p>
All necessary changes have been made in the CF Conventions document. This ticket cannot yet be closed because it also requires changes in the conformance document and new standard names.
</p>
TicketjonathanThu, 16 Mar 2017 15:06:46 GMT
https://cf-trac.llnl.gov/trac/ticket/143#comment:16
https://cf-trac.llnl.gov/trac/ticket/143#comment:16
<p>
I think that the changes in the conventions document for this ticket may not be quite right yet. Please see <a class="ext-link" href="https://github.com/cf-convention/cf-conventions/pull/69#issuecomment-287085962"><span class="icon"></span>https://github.com/cf-convention/cf-conventions/pull/69#issuecomment-287085962</a>.
</p>
Ticketpainter1Thu, 16 Mar 2017 19:49:17 GMT
https://cf-trac.llnl.gov/trac/ticket/143#comment:17
https://cf-trac.llnl.gov/trac/ticket/143#comment:17
<p>
It is fixed now.
</p>
Ticketpainter1Thu, 11 May 2017 19:54:31 GMTstatus changed; resolution set
https://cf-trac.llnl.gov/trac/ticket/143#comment:18
https://cf-trac.llnl.gov/trac/ticket/143#comment:18
<ul>
<li><strong>status</strong>
changed from <em>accepted</em> to <em>closed</em>
</li>
<li><strong>resolution</strong>
set to <em>fixed</em>
</li>
</ul>
Ticket