@JimBiardCics : I'm sorry if I misrepresented your views, but I think I have
understood, I'm just using different words. In the case 2b in your comment [a
few hours
ago](https://github.com/cf-convention/cf-conventions/issues/148#issuecomment-436722293)
you refer to data encoded as if there are
Hello, @JimBiardCics , @ChrisBarker-NOAA ,
Jonathan points out that the timestamp is usually interpreted in the calendar
stated [in a comment added 3 days
ago](https://github.com/cf-convention/cf-conventions/issues/148#issuecomment-435587942).
I think it is the case that all existing
However, calendar formerly known as `gregorian_utc`, as described at the start
of this discussion, is not consistent with use of SI time units, and so could
not be used with standard name `time`. What is described here has no relation
to the concept of calendar as it currently exists in the CF
hi @JimBiardCics .. my previous comment (2 above) was a response to your post 4
above, before I saw your comment addressed to me (3 above) ...
Firstly, in response to your most recent question:
If you add 120 seconds to `2016-12-31T23:59:00Z (UTC)` you get
`2017-01-01T00:00:59Z (UTC)` because
@JimBiardCics : I'm sorry, I don't see how the fact that [you thought about it
two years
ago](https://github.com/cf-convention/cf-conventions/issues/148#issuecomment-436760085)
helps us here. I'm suggesting a means of dealing with your stated use case,
because I can see some merit in dealing
Hi @ChrisBarker-NOAA : thanks ... but my question was slightly different.
Suppose, for instance, that the data records the frequency of some event (e.g.
`frequency_of_lightning_flashes_per_unit_area` which has units of `m-2 s-1`)
and the user wants to know the number of events in the elapsed
Hello Jim, thanks for directing me here from the mail list discussion on [360
day
calendars](http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020620.html).
As you might guess from my latest contribution to that discussion, I have
reservations about relaxing the specification of `time` to
@JimBiardCics Thanks for that detailed reply. I think I understand now. I've
also done a bit more background reading and learned how extensive this problem
is, causing disruption to companies like Google and Amazon, who have both
adopted messy (and mutually inconsistent) work-arounds to the
Here is a CDL illustration of how I think this could work, with separate
variables for the (1) months and years (with each year 12 months, months
variable numbers of days), (2) days, hours, minutes (60 minutes to the hour, 24
hours to the day, variable length minutes) and (3) seconds (SI units
Hello @JimBiardCics , thanks again for a detailed response.
I support the aim of allowing users to place either a UTC or TAI time stamp in
the units statement (so that they can do whatever fits with their existing
processes) and making it possible for them to declare which they are using. The
Hello All,
I accept @ChrisBarker-NOAA that my objection to the solution @JimBiardCics has
called `gregorian_utc` is pedantic, but I still consider it important. My
objection has nothing to do with the name, but is to do with the fact that an
increment of 1 second in the time variable may be
Good idea. I support it as well. Is it worth doing a minor reorganisation of
this repository at the same time, and creating separate folders for the
Conventions and Conformance documents?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view
Hi @JimBiardCics , sorry for the long silence on this discussion.
The [current NUG](https://www.unidata.ucar.edu/software/netcdf/docs/)
(2020-02-26, version 4.7.3) page on [coordinate
Hi Jim,
I agree that the formal approach set out by the [IETF RFC 2119 - Key words for
use in RFCs to Indicate Requirement
Levels](https://tools.ietf.org/html/rfc2119) (SHALL, SHOULD, MAY etc) is very
useful, but, as you say, it is not used in CF or in the NUG, so I'm not sure of
its
@ethanrd : the NUG definitely does allow `string` and `char` coordinate
variables. In NUG, any valid variable can (subject to the constraints which you
have cited) be a coordinate variable. There is an ambiguity around the
requirement for that coordinate variables should be monotonic: the
Hi @ethanrd: [NUG defines coordinate
variables](https://www.unidata.ucar.edu/software/netcdf/docs/netcdf_data_set_components.html#coordinate_variables)
with the statement that "A variable with the same name as a dimension is
called a coordinate variable. It typically defines a physical
owever, this appears to be a matter of taste .. so I'll go with
the majority for this issue,
regards,
Martin
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/174#issuecomment-
Hi Ethan, I support this .. but we need to check other references to "integer".
There are 9 statements in the convention that something "must be type integer"
(e.g. "In this representation, the file contains an index variable , which must
be of type integer, and must have the sample dimension
As Klaus points out, the units need to come from the Udunits list, so the
correct units attribute would be `US_survey_foot`.
When I use the Udunits2 linux command line tool, it gives a conversion factor
of 0.304801, which is significantly less precise. The XML database that comes
with the
@JimBiardCics : thank you for that detailed response.
I certainly agree that we should aim for unambiguous language, and that
ambiguity in the present CF Conventions and NUG are a source of confusion, and
that there is an opportunity here to clear up some of the confusion.
I'm generally in
Once it is defined Jim, once it is defined. Given your proposed logical steps,
how would you suggest assessing whether or not a particular variable is a
dimension coordinate variable?
If you think you see confusion in what I have written, please give some
indication of which part of the text
Dear @ethanrd, @JimBiardCics : thank you for those comments. I'll try to
address both of them, starting with Ethan's post.
I don't fully understand the comments about non-numeric coordinates. The
statement that a CF Coordinate Variable must be numeric has been in the
convention since version
@JimBiardCics : for completeness I'd like to note that in addition to Jonathan
and myself, Karl has expressed opposition to accepting string valued dimension
coordinate variables (repeatedly), and David has expressed reservations.
Do you acknowledge that the current convention, and version
Hello @JimBiardCics ,
I agree that you can parse the cited NUG sentence into either of the logical
constructs you mention
[above](https://github.com/cf-convention/cf-conventions/issues/174#issuecomment-596816563),
but I don't believe it makes sense to parse the sentence in isolation. I
Hi Ethan : that may be true, but the CF convention currently requires that
coordinate variables (excluding auxiliary coordinate variables) must be
monotonic. This requirement has been in the convention since version 1.0. As
Jonathan has noted, it could be changed -- nobody has said that it is
@ethanrd : the restriction to numeric types has always been in CF.
@sethmcg : is there any reason why you can't use auxiliary coordinates for this
use case? Where does the requirement for a string dimension coordinate enter
into this?
@JimBiardCics : reasons have been stated repeatedly in
@ethanrd : I don't understand how it can be that Jim is unaware of reasons
which have been repeatedly stated in response to his questions. It is, I think,
unkind to repeatedly state that you see no reason against your views when
people have offered arguments at length (myself, Karl and Jonathan
I also prefer the first version, and the option of keeping the recommendation
to avoid the form `x(x,l)` as it is.
I would prefer to use "must" rather than "shall". In most cases the existing
text uses "must", and introducing "shall" as a variation in a small number of
places looks confusing
@ethanrd : yes, dropping "assigned" is a good idea and I like your latest
reformulation.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/243#issuecomment-597187583
Thanks David, I believe that would be very helpful. We have agreed to change it
from a `defect` to an `enhancement`, but I don't appear to have the permission
needed to effect that change, so please make that switch if you can.
--
You are receiving this because you are subscribed to this
Hi @cameronsmith1 : I'm asking whether we accept them as defined in `udunits2`.
In `udunits2`, `ppm` and `ppmv` are exactly equivalent and interchangeable. My
opinion is closer to yours: these two units are similar, but not equivalent.
Hence, it might be worth excluding `ppmv` and other
I support this, including the removal of the lines referring to GRIB and PCMDI
tables -- especially as the GRIB 1 codes referred to are now being replaced by
GRIB 2.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Hi @davidhassell : thanks.
There is a use case for providing attributes on bounds variables in the Trac
ticket which you cited ([140](https://cf-trac.llnl.gov/trac/ticket/140)) :
@taylor13 describes a usage where the user needs to know the `units` of the
bounds variable and does not make use
@davidhassell : OK, I'd be happy to treat this as a `defect` issue -- do you
recall where the intention you refer to was discussed? Or who was involved?
@Dave-Allured : I'm not sure why the original choice was made. It would
certainly be simpler to ban these attributes on bounds variables, but
@davidhassell : David A. and Jonathon are both in favour of requiring an exact
string match (my [option
(B)](https://github.com/cf-convention/cf-conventions/issues/265#issuecomment-627193357),
your [option
Hi @davidhassell : the conformance document still states that "The axis
attribute is not allowed for auxiliary coordinate variables", but the CF
checker appears to be updated to accept it in lien with the changes you refer
to, which came into CF-1.6.
--
You are receiving this because you are
# Clarification of requirements on calendar attribute of a bounds variable
# Moderator
None at present
# Moderator Status Review [last updated: 2020/05/07]
Just posted
# Requirement Summary
Express clearly what constitutes a valid value for the `calendar` attribute of
a bounds variable.
#
Dear @Dave-Allured , @JonathanGregory ,
I agree with Jonathan's point that someone may want to encode real world data
from the 16th century (e.g. [weather records from 16th century
diaries](https://link.springer.com/article/10.1023/A:1005505113244)) .. and so
we should maintain the existing
I initially liked Jonathan's idea of introducing a new proleptic calendar(s) to
make it explicit when people care about the interpretation of negative years in
the reference time, but, after thinking over the point discussed below, I would
prefer to use a qualifier, e.g. `proleptic_gregorian
@peterkuma thanks for the detail, I was looking at ISO 8601-2014 (accessed in
2018) ... and the treatment of years - to 0 has clearly be considerably
enhanced in the 2019 version, especially in the extension (8601-2). I've just
downloaded a new version.
The NetCDF Java library has quite
@Dave-Allured : I think this does deserve some further discussion because the
study of climate in the distant past is a very important part of climate
science, even if it is small in scale compared to the study of present day
climate. Our problem is that the distant part is more important for
Hello @Dave-Allured
* I agree on sticking to the format illustrated in [section 4.4 Time
Coordinate](http://cfconventions.org/Data/cf-conventions/cf-conventions-1.8/cf-conventions.html#time-coordinate)
-- in ISO terminology this means accepting the extended format (which has
year, month and
One of the contributors to the CMIP6 archive has contributed data with a
`cell_methods` string of the form: `area: time: mean (interval: 1 month) where
sea_ice`. CF Checker 4.0.0 reports this as an error `ERROR: (7.3): Invalid
syntax for cell_methods attribute`.
The relevant paragraph of the
@Dave-Allured : OK, thanks for the clarification on [data
types](https://github.com/cf-convention/cf-conventions/issues/265#issuecomment-738965653)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
HI @zklaus : good point about the existing rules.
Regarding your use case; wouldn't that use case be covered by setting the
`long_name` to "Temperature time-series from the Umeå station"? The current
convention appears to permit "Umeå_station", but not "Umeå station" (blanks not
allowed).
The
@Dave-Allured : Sorry, I misunderstood that bit about data types. You mean that
the convention should accept having, for instance, `calendar` as a string
variable on the main variable and a character array on the bounds variable?
This looks likely to cause confusion, as some software may
Hi @Dave-Allured , @JonathanGregory : Dave is right, the main motivation for
raising this was to see if something of the form:
```
double time(time) ;
time:bounds = "time_bnds" ;
time: calendar = "noleap" ;
double time_bnds(time,nb) ;
time_bnds: calendar = "365_day" ;
```
should be
The CF Convention does not impose any restrictions on the character set used in
variable and attribute names. I have been, for a long time, working on the
assumption that there were restrictions inherited from NetCDF, but that is no
longer the case. The [current
Just to be clear, I wasn't suggesting that `Temperature (°C)` was something
that I would want to use or encourage others to use, just wondering whether it
should be considered as valid in a CF data file.
I tend to agree with @MaartenSneepKNMI and @taylor13 : the point that inclusion
of spaces
Closed #307.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/307#event-4002392860
This list forwards relevant notifications from Github. It is distinct from
@Dave-Allured : sorry, my mistake. Apologies for a unneeded discussion.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/307#issuecomment-728336204
This list forwards
I agree that some use cases would be helpful. I'm not sure about the specific
proposal that initiated the discussion, but I do agree with the thought behind
it that we should have a considered and reasoned policy on this, rather than
just having a frozen-in rule based on past library
I support Karl's proposal. This is a great improvement, and resolves some
serious issues of ambiguity.
However, I suggest expanding the calendar definitions slightly in section 4.1
and minimise the discussion of different calendars in the introduction of
chapter 4. In Karl's text there are, I
What is meant by "original data" in the definition of the "source" attribute?
The Convention states that this global attribute should be used for "The method
of production of the original data. If it was model-generated, source should
name the model and its version, as specifically as could be
@graybeal , @taylor13 : thank you for those comments. The idea of the
"immediately prior source" certainly makes sense, but it may be undesirable if
taken literally. For instance, global climate simulations which are distributed
for global data exchange will, before being distributed, we
@taylor13 : apologies for the long silence on this issue. With the approach
your approach, would you permit multiple comments, e.g. `mean (in the immediate
vicinity of polar bears) where sea_ice (excluding swimming bears)`?
I can see the attraction of making a mis-placed comment a warning
@davidhassell : this issue is still in need of a moderator -- is your offer
from March 2020 still open? As far as I'm aware, the issues is still
unresolved. I've revised the top comment to note an additional problem with a
broken link in section 1.3 of the convention.
--
You are receiving
@davidhassell , @sethmcg : I think it may be possible to have auxiliary
coordinate bounds for a cell which is missing it's central value, but I don't
think the question if really relevant here in either case. The `missing_value`
and the `_FillValue` should apply to both the auxiliary coordinate
Closed #341.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Thanks @taylor13 : your examples answer my question. I was getting a bit mixed
up between `source` and the related CMIP `source_id` attribute. I'll take the
discussion on `source_id` back to our CMIP document.
--
You are receiving this because you are subscribed to this thread.
Reply to this
@castelao : thanks, I agree with your approach. Following the theme of keeping
things simple unless there is a clear need, I suggest using your listed fields
plus `Description` for now, and more can be added later if needed.
--
Reply to this email directly or view it on GitHub:
@castelao : I like the idea of having a DOI for the CF concept, but I would
like to take this opportunity to clarifying what that concept is. @ethanrd has
suggested, I think, that the concept can be defined, in effect, by pointing to
cfconventions.org, but I feel it would be more in the spirit
Hello, sorry for the very late answer (had a long, long rush at work). I can
see https://cf-trac.llnl.gov/trac/query but can not see how to create a new
issue. I presume that I need to login, but don't see where to create an account.
Note that the "OGC WKT Coordinate System Issues" page seems
The issue is not yet resolved; I still have to request a trac account (thanks
Jonathan for the address) for describing this issue there. Is it still the way
to go, or is there a plan to move on GitHub?
--
You are receiving this because you are subscribed to this thread.
Reply to this email
Done: https://cf-trac.llnl.gov/trac/ticket/172
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/124#issuecomment-380398375
How can I contact Jeff? Did I missed a "contact" link on the issue tracker?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/124#issuecomment-376107040
I'm partly responsible for having the projection coordinates in radians today,
but I support this proposal. I would suggest that the units of the
`projection_x/y_coordinate` would be used in the libs mentionned by @magau to
determine if the values need to be multiplied by the
67 matches
Mail list logo
