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
<[email protected] <mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>> -----
Date: Thu, 28 Sep 2017 08:44:52 -0400
From: Jim Biard <[email protected] <mailto:[email protected]>>
To: [email protected] <mailto:[email protected]>
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." <[email protected]
<mailto:[email protected]>> -----
Date: Wed, 27 Sep 2017 22:49:20 +0000
From: "Kehoe, Kenneth E." <[email protected] <mailto:[email protected]>>
To: "[email protected] <mailto:[email protected]>"
<[email protected] <mailto:[email protected]>>
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: [email protected]
<mailto:[email protected]><mailto:[email protected]> | Office:
303-497-4754 | Cell: 405-826-0299
_______________________________________________
CF-metadata mailing list
[email protected] <mailto:[email protected]>
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
----- End forwarded message -----
_______________________________________________
CF-metadata mailing list
[email protected] <mailto:[email protected]>
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: [email protected] <mailto:[email protected]>
<mailto:[email protected]>
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 @NOAANCEIclimate
<https://twitter.com/NOAANCEIclimate> and @NOAANCEIocngeo
<https://twitter.com/NOAANCEIocngeo>. /
_______________________________________________
CF-metadata mailing list
[email protected] <mailto:[email protected]>
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
----- End forwarded message -----
_______________________________________________
CF-metadata mailing list
[email protected] <mailto:[email protected]>
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:[email protected] <mailto:[email protected]> | //Office:
303-497-4754 | //Cell: 405-826-0299/
_______________________________________________
CF-metadata mailing list
[email protected]
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: [email protected] <mailto:[email protected]>
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 @NOAANCEIclimate <https://twitter.com/NOAANCEIclimate> and
@NOAANCEIocngeo <https://twitter.com/NOAANCEIocngeo>. /
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
