I also agree with (1) and (4), and as I read it, it seems that Jonathan's
tentative suggestion removes the need for (3). And that would seem to
leave stating (2) as either
wind_dir_uv_stddev:standard_name="wind_from_direction standard_error" ;
or Brian's preference of
wind_dir_uv_stddev:standard_name="standard_error_of_wind_from_direction" ;
Is that correct? I would prefer the 1st just for the ease of parsing. I've
actually been doing the 2nd for a somewhat related purpose for a while, and
the parsing always became a mess, although I have to take the blame for that.
Jonathan, as to your previous query about "wind_direction_uv" and
"wind_direction_ve", I didn't explain "wind_direction_ve" very well.
It's a true vector average taking into account the wind strength for
the directional computation, rather than just a unit vector average.
As I understand it, NDBC reports the unit vector average as the
true wind direction (see "
http://www.ndbc.noaa.gov/wndav.shtml"), but we
measure both anyway. And to think that after doing this for a couple of
years, it's just now occured to me that my putting the "_uv" suffix for
"unit vector" on "wind_direction_uv" probably wasn't the brightest thing
to do for a directional quantity...
On Thursday 17 April 2003 19:58, Brian Eaton wrote:
> Hi All,
>
> I agree with Jonathan's items (1) and (4).
>
> I think backward links provided by an attribute such as "for_variables"
> add convenience but no new functionality. As Jonathan noted all
> the links between file variables can be determined by parsing all
> variable's forward link attributes. The added convenience of a backward
> link must be weighed against the disadvantages of adding complexity to the
> convention. I this case I vote against providing backward links.
>
> I think identifying the error types by the standard name is the right
> approach rather than by adding a new "intent" attribute. I'm not in favor
> of the standard_name prefix "ancillary_data_for_" as it adds no new
> information. But standard name prefixes like "standard_error_of_" do add
> information. We currently require all standard_name values to be
> explicitly listed in the table. As Jonathan has suggested we could specify
> a set of prefixes that could be added to any standard name in the table
> with the result being a valid standard name that is not explicitly listed
> in the table. The prefix definition would include information about the
> appropriate units for the quantity, for example it might say that the units
> are the same as those of the quantity to which the prefix is attached.
>
> I prefer the use of standard name prefixes to Jonathan's proposal for
> "ready-parsed" standard names with intents. In that proposal the standard
> name part of standard_name's value is actually the standard name of the
> data with which this variable is associated. I think the standard
> name should describe the quantity that the attribute attached to.
>
> It has previously been pointed out that it will be difficult to describe
> the error types using standard names due to the variety of definitions that
> are used for errors. I think we can start by defining names for the most
> commonly used errors (or other data quality measures) and expand the list
> by request. This is how we've dealt with similar issues related to
> standard names and projections for example. Also, if a certain type of
> error is easily parameterized, as for example with the number of standard
> deviations being reported in a standard error, then new attributes that
> give these parameter values can be defined and used in conjunction with the
> standard name to precisely define the quantity. That would be analogous to
> how we define projections.
>
> Brian
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
John Evans
johnevans at acm.org
Received on Thu Apr 17 2003 - 15:17:55 BST
