Dear all,
I am wary of a "slippery slope" if every calculation performed on a
quantity results in a new standard name for that quantity. We have
tried to avoid that in most cases by use of the cell methods, bounds,
and climatology attributes. Isn't there some way to accommodate this in
a more general way? I agree that use of non-controlled vocabulary is
not ideal, but I would be interested in the kind of use case you
envision where you would have to parse it? How does definition of a new
standard name satisfy your use case of machine interpretation?
best regards,
Karl
On 4/13/18 8:22 AM, Sebastien Villaume wrote:
Dear Jonathan, Roy and Karl,
thank you for your valuable inputs.
I am not very fond of the cell_method solution: I am already very reluctant
using it because it is not controlled vocabulary and it is a nightmare to parse
to extract valuable metadata automatically. Now that I am discovering that one
can use a standard_name with no attached bounds instead of a proper variable
name with associated bounds makes me even more reluctant to use it!
But I am not in a favour of encoding huge values of depth either...
... which leaves me being in favour of proposing new standard names by prefixing existing
standard names with "ocean_" !
/Sébastien
----- Original Message -----
From: "Karl Taylor" <[email protected]>
To: [email protected]
Sent: Wednesday, 11 April, 2018 18:45:07
Subject: Re: [CF-metadata] use of
integral_wrt_depth_of_sea_water_practical_salinity
Dear Sebastien,
One option would be to include in cell_methods the following:
cell_methods = "depth: mean (from surface to sea floor)"
where depth is the standard name for the vertical coordinate, as
provided for in
http://cfconventions.org/Data/cf-conventions/cf-conventions-1.7/cf-conventions.html#cell-methods-no-coordinates
, and the information in parentheses is non-standard, as provided for in
http://cfconventions.org/Data/cf-conventions/cf-conventions-1.7/cf-conventions.html#recording-spacing-original-data
.
I, for one, wouldn't like to see every integral over an entire domain to
require a new standard_name. the standard_names should name the
variable itself and not indicate "method".
best wishes,
Karl
On 4/11/18 10:28 AM, Jonathan Gregory wrote:
Dear Sebastien
There is an existing standard name of
ocean_integral_wrt_depth_of_sea_water_temperature
and the one you propose has the same pattern, so it would seem all right to me,
and appropriate for your purpose. Otherwise you could set a very large lower
depth boundary with the understanding that integrating below the sea floor
added nothing, but that's a bit ugly.
Best wishes
Jonathan
----- Forwarded message from Sebastien Villaume <[email protected]>
-----
Date: Wed, 11 Apr 2018 13:57:48 +0000
From: Sebastien Villaume <[email protected]>
To: [email protected]
Subject: [CF-metadata] use of
integral_wrt_depth_of_sea_water_practical_salinity
X-Mailer: Zimbra 8.6.0_GA_1200 (ZimbraWebClient - FF57 (Linux)/8.6.0_GA_1200)
Dear list,
In 2016/2017, a list of new standard names for NEMO output has been proposed and
accepted : http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2016/058964.html
from that initial list of standard names and after many iterations, one of the
accepted standard name was:
standard name: integral_wrt_depth_of_sea_water_practical_salinity
units: m
But the initial list of proposed standard names had actually 2 entries for this
standard name:
- one entry which is the one that eventually made it to the list (the standard
name above)
- a second entry for the case where the depth is the total depth, from surface
to sea floor: ocean_integral_wrt_depth_of_sea_water_practical_salinity
During the discussion:
- Alison argued that the 2 entries were actually identical, the second one
being simply a special case of the first one, i.e. when the depth corresponds
to the total depth. She proposed later on to simply dropped the second entry.
- Antonio Cofino argued that in this case the reference to Axis and to
bounds
should be removed from the description because in the case of the total
depth,
the bounds are not a constant (but function of lat and lon)
In the published description the reference to an axis and to bounds is still
there.
My immediate problem is that I want to produce a parameter that is the integral
wrt the whole depth of the salinity and I don't know how to do this.
for a fixed depth of 500m for instance, the metadata for the parameter would be:
float salinity500(t, y, x) ;
salinity500:standard_name =
"integral_wrt_depth_of_sea_water_practical_salinity"
;
salinity500:units = "m" ;
salinity500:coordinates = "time dpt500 latitude longitude" ;
float dpt500 ;
dpt500:standard_name = "depth_below_geoid" ;
dpt500:units = "m" ;
dpt500:axis = "Z" ;
dpt500:positive = "down" ;
dpt500:bounds = dpt500_bnds ;
float dpt500_bnds(bnds) ;
and in the dpt500_bnds array, I have : [0., 500.]
for the total depth, I can't use the same mechanism, because the second value of
the bounds is not a constant, it is a function of lat and lon: [0., f(lat,lon)]
How can I solve this?
Is it possible to reconsider the standard name
ocean_integral_wrt_depth_of_sea_water_practical_salinity (or a variation of
it)?
Another approach could be to keep the existing standard name, add a new standard
name that represents the total water column and use it as an auxiliary
coordinate.
thanks,
____________________________________
Dr. Sébastien Villaume
M.A.R.S. Analyst
ECMWF Data Governance facilitator
ECMWF
Shinfield Park,
Reading RG2 9AX, UK
+44 (0)118 949 9301
+44 (0)7825 521592
[email protected]
____________________________________
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
----- End forwarded message -----
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
