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

Reply via email to