Jonathan,
I must have suffered narcolepsy while reading Kenneth's original post
(not because it was badly written!), because I managed to completely
miss the request to expand the usage of the 'positive' attribute.
Kenneth,
Feel free to specify your own attribute to use within your community.
Perhaps 'directionality' is a good name, with a controlled vocabulary
such as 'positive_up', 'positive_down', etc. It's fine to have non-CF
attributes in your file. You are right that this is much easier to
handle than trying to parse standard names, comments, etc. If it catches
on, it might even end up in CF one day!
Grace and peace,
Jim
On 9/28/17 11:46 AM, Kehoe, Kenneth E. wrote:
> Jonathan and Jim,
>
> Thanks for your replies. As Jonathan stated I was only trying to
> expand the current use of an existing reserved attribute so the CF
> standard would not need to reserve further attributes. I understand
> and agree that putting information in two locations is a bad idea
> (positive attribute and standard_name), but my problem is that we can
> not reasonably expect our users to have software to look up positive
> direction in an external standard name table. We need the basic
> information to be contained in the netCDF file. I don?t see us parsing
> the standard_name description or looking up information in an
> ancillary column in the standard_name table as that would require work
> beyond what my users are willing to do. We currently put direction in
> multiple locations (long_name, comment, variable name) and I was
> trying to find a solution to have one place and allow it to be machine
> readable. For now I?ll continue to encourage the direction information
> to be placed in a comment attribute and continue to look for a more
> machine readable way to parse the direction information.
>
> Thanks,
>
> Ken
>
>
>> On Sep 28, 2017, at 7:48 AM, Jonathan Gregory
>> <j.m.gregory at reading.ac.uk <mailto:j.m.gregory at reading.ac.uk>> wrote:
>>
>> Dear Jim
>>
>> Yes, that's right, the positive attribute is currently supported only for
>> vertical coordinate variables. Following the COARDS rules, it can be used
>> to identify a variable as a vertical coordinate variable. If other
>> kinds of
>> coordinate variable than vertical were allowed to have a positive
>> attribute,
>> it's likely that existing software would be confused. However, that's not
>> the issue I was writing about.
>>
>> If I understood Ken's email correctly, he was asking about the
>> possibility
>> of using the positive attribute on data variables as well, instead of
>> or as
>> well as the sign convention indicated in the standard name. As I wrote, I
>> think this is problematic, though I do understand the reason for
>> making the
>> suggestion.
>>
>> Best wishes
>>
>> Jonathan
>>
>> ----- Forwarded message from Jim Biard <jbiard at cicsnc.org
>> <mailto:jbiard at cicsnc.org>> -----
>>
>>> Date: Thu, 28 Sep 2017 08:44:52 -0400
>>> From: Jim Biard <jbiard at cicsnc.org <mailto:jbiard at cicsnc.org>>
>>> To: cf-metadata at cgd.ucar.edu <mailto:cf-metadata at cgd.ucar.edu>
>>> Subject: Re: [CF-metadata] positive attribute expansion of use and
>>> reserved
>>> values
>>> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0)
>>> Gecko/20100101 Thunderbird/52.3.0
>>>
>>> Jonathan,
>>>
>>> I am confused by your answer to Kenneth. As you know, we already
>>> have a CF attribute named positive that derives from COARDS. CF 1.7
>>> states in Section 1.3
>>>
>>> ??Vertical coordinates with units of pressure may also be identified
>>> ??by the*|units|*attribute. Other vertical coordinates must use the
>>> ??attribute*|positive|*which determines whether the direction of
>>> ??increasing coordinate value is up or down.
>>>
>>> I don't see Kenneth asking for anything new other than an expanded
>>> vocabulary for the attribute, but in your answer I get the
>>> impression that you feel he is asking for something fundamentally
>>> different from what we currently have. Are you suggesting that we
>>> should deprecate the use of the 'positive' attribute? Your response
>>> doesn't seem to reflect the scope of his request.
>>>
>>> Grace and peace,
>>>
>>> Jim
>>>
>>> On 9/27/17 7:45 PM, Jonathan Gregory wrote:
>>>> Dear Ken
>>>>
>>>> Thanks for your email. I sympathise with the problem, but I don't
>>>> agree with
>>>> the proposal. Actually similar suggestions have been made before.
>>>>
>>>> It's an important principle with the standard names that they
>>>> always indicate
>>>> their sign convention. This is so that, if a standard name is
>>>> provided, the
>>>> sign convention is unavoidably specified; if the sign convention
>>>> were not in
>>>> the standard name, but in another attribute e.g. positive, it is
>>>> certain that
>>>> it would be omitted sometimes by mistake. If the sign convention
>>>> were specified
>>>> in the standard name *and* another attribute, it is certain that
>>>> they would
>>>> sometimes be inconsistent by mistake. Either mistake would make the
>>>> data less
>>>> usable. You mention cases where the wrong standard name is given. I
>>>> agree, that
>>>> makes the data less usable too, but I'd say the solution to that is
>>>> to fix the
>>>> data, when the problem has been identified; we should not have to
>>>> modify the
>>>> convention in a way which would make it generally more error-prone.
>>>> You also
>>>> mention cases where you don't have a standard name but you do need
>>>> a direction.
>>>> Presumably you must have some other information in that case about
>>>> what the
>>>> quantity is - which attribute are you using? If it's the long name,
>>>> you could
>>>> put the sign convention in there, for example, as for standard
>>>> names. New
>>>> standard names can also be requested for instrumental quantities,
>>>> and the
>>>> direction doesn't have to be "up" or "down" in standard names. As
>>>> you probably
>>>> know, there are already standard names containing away_from to
>>>> indicate their
>>>> sign convention, just as you suggest.
>>>>
>>>> I agree that there is sometimes a need to know how to relate
>>>> quantities with
>>>> opposite sign conventions in their standard names. The standard
>>>> names are
>>>> mostly systematically constructed, but for use by humans; they
>>>> aren't designed
>>>> to be parsed by machines. If there is a need for some means to deal
>>>> with this,
>>>> I would favour recording the sign convention as a machine-readable
>>>> extra piece
>>>> of information in the standard name table. If we put it in the
>>>> table, it must
>>>> be consistent with the standard name; you'd just have to look it
>>>> up, instead of
>>>> trying to extract it from the standard name.
>>>>
>>>> Best wishes
>>>>
>>>> Jonathan
>>>>
>>>> ----- Forwarded message from "Kehoe, Kenneth E." <kkehoe at ou.edu
>>>> <mailto:kkehoe at ou.edu>> -----
>>>>
>>>>> Date: Wed, 27 Sep 2017 22:49:20 +0000
>>>>> From: "Kehoe, Kenneth E." <kkehoe at ou.edu <mailto:kkehoe at ou.edu>>
>>>>> To: "CF-metadata at cgd.ucar.edu <mailto:CF-metadata at cgd.ucar.edu>"
>>>>> <CF-metadata at cgd.ucar.edu <mailto:CF-metadata at cgd.ucar.edu>>
>>>>> Subject: [CF-metadata] positive attribute expansion of use and
>>>>> reserved
>>>>> values
>>>>>
>>>>> CF-metadata,
>>>>>
>>>>> I would like to propose an expansion of the use and reserved
>>>>> values for the ?positive? attribute (section 4.3), specifically to
>>>>> include values in addition to the two reserved values of ?up? and
>>>>> ?down? to include ?towards? and ?away?.
>>>>>
>>>>> Most variables define direction in the standard_name, but with
>>>>> instrumentation a standard name is often not available or the
>>>>> correct definition of the name exists with the wrong positive
>>>>> direction. Also, needing to understand or extract direction from
>>>>> the standard_name can be difficult for a simple tool not wanting
>>>>> to review the standard_name definition just to see if a
>>>>> transformation is needed. Expanding the use of the ?positive?
>>>>> attribute would reduce the number of standard names by not needing
>>>>> to include positive direction in the definition. This would also
>>>>> follow the recommendation of being consistent with the definition
>>>>> between the standard_name and positive attribute. The ?positive?
>>>>> attribute is currently reserved for use with coordinate dimensions
>>>>> only, but the same logic can be used with data variables to
>>>>> indicate direction. For example rate of speed for vertical
>>>>> velocities could be described by indicating positive = ?up? when
>>>>> vertical velocities are positive when moving away from the surface.
>>>>>
>>>>> Instruments are also often not installed perpendicular to the
>>>>> surface, and the coordinate system is better described as towards
>>>>> or away from the instrument. Specifically for radial instruments.
>>>>> Errors in misunderstanding direction with radial velocities or
>>>>> accelerations are comment when not specifically defined. There is
>>>>> no vendor standard.
>>>>>
>>>>> I?ll leave my suggestion at towards and away, but this could also
>>>>> be expanded to include cardinal direction for
>>>>> East-West/North-South directions.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Ken
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Kenneth E. Kehoe
>>>>> ?Research Associate - University of Oklahoma
>>>>> ?Cooperative Institute for Mesoscale Meteorological Studies
>>>>> ?ARM Climate Research Facility - Data Quality Office
>>>>> ?e-mail: kkehoe at ou.edu
>>>>> <mailto:kkehoe at ou.edu><mailto:kkehoe at ou.edu> | Office:
>>>>> 303-497-4754 | Cell: 405-826-0299
>>>>>
>>>>> _______________________________________________
>>>>> CF-metadata mailing list
>>>>> CF-metadata at cgd.ucar.edu <mailto:CF-metadata at cgd.ucar.edu>
>>>>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>>>>
>>>> ----- End forwarded message -----
>>>> _______________________________________________
>>>> CF-metadata mailing list
>>>> CF-metadata at cgd.ucar.edu <mailto:CF-metadata at cgd.ucar.edu>
>>>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>>>
>>> --
>>> CICS-NC <http://www.cicsnc.org/> Visit us on
>>> Facebook <http://www.facebook.com/cicsnc> *Jim Biard*
>>> *Research Scholar*
>>> Cooperative Institute for Climate and Satellites NC <http://cicsnc.org/>
>>> North Carolina State University <http://ncsu.edu/>
>>> NOAA National Centers for Environmental Information
>>> <http://ncdc.noaa.gov/>
>>> /formerly NOAA?s National Climatic Data Center/
>>> 151 Patton Ave, Asheville, NC 28801
>>> e: jbiard at cicsnc.org <mailto:jbiard at cicsnc.org>
>>> <mailto:jbiard at cicsnc.org>
>>> o: +1 828 271 4900
>>>
>>> /Connect with us on Facebook for climate
>>> <https://www.facebook.com/NOAANCEIclimate> and ocean and geophysics
>>> <https://www.facebook.com/NOAANCEIoceangeo> information, and follow
>>> us on Twitter at _at_NOAANCEIclimate
>>> <https://twitter.com/NOAANCEIclimate> and _at_NOAANCEIocngeo
>>> <https://twitter.com/NOAANCEIocngeo>. /
>>>
>>>
>>
>>> _______________________________________________
>>> CF-metadata mailing list
>>> CF-metadata at cgd.ucar.edu <mailto:CF-metadata at cgd.ucar.edu>
>>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>>
>>
>> ----- End forwarded message -----
>> _______________________________________________
>> CF-metadata mailing list
>> CF-metadata at cgd.ucar.edu <mailto:CF-metadata at cgd.ucar.edu>
>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
>
>
> /Kenneth E. Kehoe/
> /? Research Associate - University of Oklahoma/
> /? Cooperative Institute for Mesoscale Meteorological Studies/
> /? ARM Climate Research Facility - Data Quality Office/
> /? e-mail:kkehoe at ou.edu <mailto:kkehoe at ou.edu>?| //Office:
> 303-497-4754 | //Cell: 405-826-0299/
>
>
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
CICS-NC <http://www.cicsnc.org/> Visit us on
Facebook <http://www.facebook.com/cicsnc> *Jim Biard*
*Research Scholar*
Cooperative Institute for Climate and Satellites NC <http://cicsnc.org/>
North Carolina State University <http://ncsu.edu/>
NOAA National Centers for Environmental Information <http://ncdc.noaa.gov/>
/formerly NOAA?s National Climatic Data Center/
151 Patton Ave, Asheville, NC 28801
e: jbiard at cicsnc.org <mailto:jbiard at cicsnc.org>
o: +1 828 271 4900
/Connect with us on Facebook for climate
<https://www.facebook.com/NOAANCEIclimate> and ocean and geophysics
<https://www.facebook.com/NOAANCEIoceangeo> information, and follow us
on Twitter at _at_NOAANCEIclimate <https://twitter.com/NOAANCEIclimate> and
_at_NOAANCEIocngeo <https://twitter.com/NOAANCEIocngeo>. /
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20170928/ae76908b/attachment.html>
Received on Thu Sep 28 2017 - 10:59:54 BST
