I agree with John that the contents of the standard name string will be
easier to parse and therefore more accessible as:
"my_standard_name my_ancillary_variable" such as
"wind_from_direction standard_error"
This would mean that your software can process the variable name from the
standard name list and then move onto the ancillary information. It will
also raise less errors when new ancillary variable types have been added but
have not been plumbed into all the CF-compliant software out there.
Ag
> -----Original Message-----
> From: John Evans [mailto:johnevans at acm.org]
> Sent: 17 April 2003 22:18
> To: cf-metadata at cgd.ucar.edu
> Subject: Re: [CF-metadata] Encoding Errors on variables in CF
>
>
> 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
>
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
Received on Tue Apr 22 2003 - 02:08:53 BST
