I agree that both the standard name table and the conventions document would
probably need separate DOIs.
We've gotten a DOI for the most recent version of the OceanSITES Data Format
Manual. I believe that implies that we'll have to keep this version available
in perpetuity, since new
Can this issue be closed now? We've agreed that the proposed new standard names
are not needed. Thank you - Nan
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> Great questions. Let me answer them in reverse order.
> ...
> Does this help?
Yes, thanks very much, this answers all of my querstions!
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
This looks very good, I appreciate all the work that went into it. I DO have a
question (or 3) about how this could be applied to vectors (e.g.
northward/eastward_sea_water_velocity or northward/eastward_wind), where there
are uncertainties in both speed and direction, and the units for the
I also agree with Karl, however I was struck by the descriptions, e.g. 'Wind
speed measured at 10 meter height'.
Working with observational data, I'd be very interested to know if there's a
standard way to indicate that a variable represents wind speed that was
measured at 2 m and then
This is all an improvement. I like Roy's change to the definition of the
aggregate flag, 'an algorithmic combination of the results of all relevant
quality tests', in place of 'set to the highest-level (worst case) flag found'.
I DO have an issue with the term 'related ancillary parent data
Thank you Alison, this is all good. I DO have a couple of issues with this
paragraph:
'This flag is a summary of all quality tests **run for another data variable**,
which have standard names of the form X_quality_flag, and is **set to the
highest-level (worst case) flag found**. Information
> @taylor13 Your code would have to parse the variable name into code. Until
> you did something like that, it is just a string.
Not everyone writes their own netCDF translators, and some packages no doubt
take the variable and attribute names from the netCDF variable and attribute
names.
I'm afraid I'm the odd man out here - I don't think the list of benefits in the
original issue stacks up against the costs; in fact some of them don't seem to
BE benefits. Maybe some use cases would be helpful ... Could you elaborate on
how this change would support international usage?
Is
The external files are fine, but there's one problem with using the
'references' attribute; that term is defined as a global attribute in CF. Most
netCDF software does not handle a situation where a term is used as a global
and a variable attribute the way you might expect - that's apparently
I personally think including this level of detail (number of standard
deviations, upper/lower limits, gap length, name of climatology used, distance
to 'neighbor' data, etc) is beyond the scope of CF; there are just too many
details. Every test has its own inputs, and these may vary with
I think this is fine. It seems clear, and limits the number of new standard
names that will be needed.
Of course, if people use these without specifying the vocabulary and/or some
reference to a description of the tests, they lose a lot of their meaning. My
aggregate_quality_flag might
Without wanting to belabor this point, since it's clearly been decided, I'd
like to point out that the DOI can in no way replace the description of CF in
the Conventions attribute: 'files that follow these conventions indicate this
by setting the NUG defined global attribute Conventions to the
13 matches
Mail list logo
