Work In Progress
--
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/pull/259#issuecomment-617325722
This list forwards relevant notifications from Github. It is distinct from
Then we'll start the countdown. Three weeks, right?
--
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/241#issuecomment-613502854
This list forwards relevant notifications
@neumannd Thanks for taking the time to clarify.
This sounds a lot like satellite swath data. It seems to me that there must be
a frame in which you have physical axes of a sort embedded in there somewhere,
but if that information isn't available, it isn't. You also may not have any
control
@neumannd Do your dimensional coordinate axes **`i`** and **`j`** have any
physical representation?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Ah, well then, I totally approve.
--
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/241#issuecomment-607868287
This list forwards relevant notifications from Github. It
This proposed change is to make the generic statement
> The attributes which describe the ellipsoid and prime the final section.
meridian may be included, when applicable, with any grid mapping.
to
> The attributes which describe the ellipsoid and prime meridian may be
> included, when
As moderator I guess I can't approve of the change, so we need others to come
and say so or give reason why not.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@erget This sounds like an excellent change to me.
--
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/258#issuecomment-607297080
This list forwards relevant notifications
@erget I'll moderate.
--
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/241#issuecomment-607290717
This list forwards relevant notifications from Github. It is distinct
@snowman2 I've got no problem with using **`unknown`**, but I think missing
should be considered equivalent.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@davidhassell I was trying to find the discussion that led to the new language
about the axis attribute. I vaguely remember it, but I can't find it anywhere.
Is the intent to allow application to auxiliary coordinate variables that
aren't 1D?
--
You are receiving this because you are
@hrajagers The axis is identified on a dimension coordinate variable using the
axis attribute. In your case, the X axis is the projection_x_axis.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@DocOtak @zklaus Sorry if I've pulled the discussion off track. The question of
exactly why NUG worded things the way they did is intriguing, but I think Klaus
is right that we shouldn't get wrapped around that particular axle in this
issue — particularly if we are going to split encoding off
I missed the regex. Yep, that's what it says. 0x7F is the "del" char, so it's
non-printing. I think the characters from 0xC0 - 0xFF are out because they
would all be interpreted in UTF-8 as signaling the start of a multi-byte
character. 0x80 - 0xBF can all be interpreted as trailing elements of
@DocOtak I couldn't find the direct restriction on the 0x80 to 0xFF characters.
Is this a side effect of utf-8 using the high bit to signal multibyte
characters? Or is it a more general prohibition against using the characters in
latin-1 that fall in that range?
--
You are receiving this
@ChrisBarker-NOAA
* The sub-issues haven't been split off.
* This issue is about attributes only.
* The difference between CHAR and STRING for an attribute is, essentially,
which type you pick when you create the attribute. With CHAR you can't specify
arrays for the value (because it already
@ChrisBarker-NOAA My original observation was that we can absolutely split off
some of these issues. I see two issues being peeled off from the base issue.
* Define a convention for attributes with multiple strings (string array
attributes).
* Determine what to do (or not do) regarding different
Chris,
Python 3 is not the same as python 2. In Python 2 there were two types — str
(ASCII) and unicode (by default UTF-8). In Python 3 there is only str, and by
default it holds UTF-8 unicode (there's lots of subtly that I'm glossing over
here, but this is what it boils down to). It bit me
@Dave-Allured I approve of your proposal. I think we pretty much have no choice
but to allow UTF-8 as a baseline to start with, but there clearly are larger
issues to be resolved. (I say "no choice" because, for example, constraining to
ASCII in python 3 is a bit complicated.)
--
You are
@martinjuckes wrote:
> Do you acknowledge that the current convention, and version 1.0, contain the
> statement that a coordinate variable " is defined as a numeric data type",
> and that this would appear to rule out string coordinate variables?
Yes, absolutely. The language in versions of CF
@JonathanGregory If "string front_type(front_type)" could be considered a valid
auxiliary coordinate variable, I'd be fine with that. In fact, I think that is
a great approach.
The message I have gotten repeatedly from this discussion is that there were
strong feelings that this should not be
@JonathanGregory Respectfully, we don't all agree that a 1-D string-valued
coordinate variable should not have the same name as its dimension. But I
acknowledge that you and Martin have that view.
@ethanrd indicates that there is a general reason use case, in that netCDF-Java
supports
@martinjuckes You and I seem to be talking past one another. I started with a
conceptual definition, then proceeded to a technical definition. I did this for
dimension coordinate variables and auxiliary coordinate variables. I am quite
confident that anyone who was given that text could figure
@martinjuckes It seems to me that there is a confusion in what you are saying
between techniques for recognizing a dimension coordinate variable by
inspection and the definition of a coordinate variable. Once the concept of
dimension coordinate variable is defined, which includes intention and
@martinjuckes I'm fine with must as opposed to shall.
Regarding the logical structure, Here's how I see the logical structure of the
paragraphs for dimension coordinate variables and auxiliary coordinate
variables. (I'm using the first version.)
As logic statements:
* IF dimension coordinate
@JonathanGregory I don't view the statement
> A one-dimensional auxiliary coordinate variable shall not have the same name
> as its dimension.
as a new requirement.
It is redundant to the statement in the previous paragraph
> A one-dimensional variable that is not a dimension coordinate variable
We need to be careful to consider the auxiliary coordinate variable case as
well as the dimension coordinate variable case. It's quite true that one
person's coordinate may be another person's data. Time is a good example of
this. I have done work where I did analysis of the contents of the
If you don't want to wade through my previous post (and I don't blame you for
not wanting to), here's an abbreviated form of my position. If we don't want to
allow data variables of the form "x(x)", can we please add something like the
sentence below to CF?
If a one-dimensional variable is not
@martinjuckes This comment is long and dry, but perhaps it will help make my
reasoning more understandable. On the other hand, it may prove that my mind is
a weird place to hang out!
As I see it, there are two ways to parse the NUG sentence into a logic
statement. They are
`IF dimensional
@martinjuckes I have seen, read, and considered your opposition to data
variables of the form "x(x)". Also your opposition to allowing the form "string
x(x)" as an auxiliary coordinate variable. I understand fully that you don't
want them to be allowed. I believe and agree that the intention
@martinjuckes Is my view that there is currently no prohibition on the form
'x(x)' when the variable is not intended as a coordinate. Is this what you feel
is unkind?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@JonathanGregory @martinjuckes @ethanrd I don't think there is a reliable way
to apply the mathematical axis concept to strings, so I'm fine with saying
**`string x(x)`** and **`char x(x,l)`** cannot be a dimension coordinate
variable, but I see no reason to say those forms can't be valid
I believe that we should allow variables of the form **`string x(x)`** as
auxiliary coordinate variables. They are the conceptual equivalent of **`char
x(x,l)`**.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Regarding the form 'x(x)': I stand by my assertion that neither NUG nor CF
prohibit such a construction for a variable that is not intended to be a
coordinate variable. Such a form is not recommended, but it is not prohibited.
I fully believe and agree that this was the intention in CF (I don't
Regarding "generic coordinate variable" versus "coordinate variable" — I would
prefer to avoid the word generic. The problem is that we have been using
"coordinate variable" in a specific sense, so it would be confusing to start
using it in a general sense at this point. As a result we need
The association of X and Y with latitude and longitude is a complicated and
difficult topic. Here's a good article about the issue.
https://wiki.osgeo.org/wiki/Axis_Order_Confusion
Here's a summary and recap as I see it.
Geodesy uses a left-hand mathematical coordinate system so that the
@snowman2 I don't think we can make that assumption, at least not in your
example and as you've expressed it. There is no direct connection in your
example between the lats and lons and the Xs and Ys. The connection of X with
projection_x_coordinate and Y with projection_y_coordinate is pretty
@martinjuckes My point is that we are a standard, and we need to use standards
language. Many of our problems in this and other areas are the direct result of
**not** using such language.
As an example, I do not read the statement in the NUG as being prescriptive or
proscriptive. It is
@ethanrd I like your verbiage. I think you could simplify it a bit by saying
In many situations, any integer type may be used.
When the phrase "integer type" is used in this document, it should be
understood to mean **`byte`**, **`unsigned byte`**, **`short`**, **`unsigned
short`**, **`int`**,
As far as the temporal axis goes, CF is quite strongly "future positive". It
would take a lot of work to change this. I expect that the paleoclimate people
would appreciate the ability to do "past positive" time coordinates that would
use a (currently non-existent) calendar appropriate to their
@snowman2 I am generally opposed to this proposal as it stands.
If we want to adopt some sort of convention about this sort of thing, I suggest
it be something like what I've written below.
For spatial coordinate systems, add an attribute named "fluffy" (this is a
placeholder name — I'm unable
@snowman2 It seems pretty clear that this is a UDUNITS issue, not a CF issue.
--
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/248#issuecomment-593486026
This list
@martinjuckes The NUG section does not make statements that take the form of
requirements. It is a subtle and strange component of English language usage in
standards and requirements documents. There are quite specific meanings applied
to certain words. They are:
* shall - It must be done or
@JonathanGregory Am I right in understanding that back in the day the whole
grid_mapping scheme in CF was added to annotate the relationship between lat
and lon variables (which were always required) and X and Y variables? If the
purpose was annotation and that annotation was itself optional,
@snowman2 There is a long-standing use of the units 'degrees_north' and
'degrees_east' within CF that I think precludes making a change to using units
of 'degrees' for latitude and longitude. It is used by some as a way to
determine that a given variable is a latitude or longitude coordinate
@JonathanGregory Most all projected coordinate systems are east-north aligned.
The main questions are which component is which and which direction is
positive. But your question points out the more difficult case of swath data
where X and Y are not aligned to east and north.
--
You are
@JonathanGregory said
> If you have use cases for actual datasets that you want to put in CF but the
> required projections are not supported in grid_mapping, it would be useful to
> propose adding them to CF.
I personally have a number of cases where CF doesn't provide the projection
used. I
@erget I believe it is. I was out of town.
--
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/230#issuecomment-589097492
This list forwards relevant notifications from Github. It is distinct
@ethanrd The CF documentation regarding constants of various types references
the NUG, which gives some examples of CDL syntax, but which is by no means a
rigorous description of how to represent each data type in an attribute. The
**ncgen** man page has a discussion of this, but that sure
@martinjuckes Notice that the examples where **`flag_values`** are given as 1b,
2b, etc, have the 'b' indicator because the variables in the examples are of
type **`byte`**. It would be good to change an example to use a different
integer type so that this is clearer. We should also make sure
I wholeheartedly approve of this proposal. @martinjuckes makes an excellent
point regarding "must have an integer type".
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I've got no objection. We just didn't want to hold up 1.8.
--
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/223#issuecomment-579837467
This list forwards relevant
@taylor13 Your code would have to parse the variable name into code. Until you
did something like that, it is just a string.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@marqh I like the overall suggestion of RFC3986. I think we should not adopt
the "% encoding" concept of RFC3986. And, again, I think we should reserve
leading "_" characters (per NUG) and multiple sequential "_" characters (per
netCDF-LD). Are there any other special character sequences in the
It appears that there is enough support for this proposal to start the
countdown clock for acceptance of change #232. If there are no substantive
modifications or objections, it can be merged in three weeks (February 13,
2020) for inclusion in CF 1.9 per the [contribution
@snowman2 I can relate to your desire and I like the idea of the attribute on
the coordinate variable. I don't think this issue is the place for this
proposal. If you'd like to open a new issue for this, I think that would be
worthwhile.
--
You are receiving this because you are subscribed to
@snowman2 I read the definitions at your link. It seems to me that this is out
of scope. Could you please explain what is gained by specifying direction (by
some as yet unknown means) with the coordinate name tuple? I would assume that
the directionality is implicit in the particular coordinate
JimBiardCics commented on this pull request.
> @@ -79,17 +79,30 @@ __Map parameters:__::
* **`sweep_angle_axis`**
* **`fixed_angle_axis`**
-__Map coordinates:__:: The x (abscissa) and y (ordinate) rectangular
coordinates are identified by the **`standard_name`** attribute val
that the reservations, while valid, should not prevent
correction of the defect, as it would not invalidate files claiming adherence
to CF 1.7 (or 1.8), and it should not be difficult for software to support the
new standard names.
People indicating approval so far are:
@iso
@JimBiardCics
@steingod
Deferred to v1.9? That's probably a good plan.
--
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/230#issuecomment-575708106
This list forwards relevant notifications from Github. It is
@erget I'd moderate.
--
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/230#issuecomment-575706288
This list forwards relevant notifications from Github. It is distinct from
I'll moderate if you like.
--
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/231#issuecomment-575646746
This list forwards relevant notifications from Github. It is
I also support the proposal.
--
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/230#issuecomment-574215701
This list forwards relevant notifications from Github. It is
Sounds great to me.
--
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/pull/229#issuecomment-574214547
This list forwards relevant notifications from Github. It is distinct from
GDAL is one more than I was aware of. I'm not aware of any others.
--
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/222#issuecomment-572632771
This list forwards
@snowman2 Are there any applications that actively read in and use the CF grid
mapping parameters?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@marqh You could use CamelCasing. In my own work, I tend to use the
construction to indicate a placeholder.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@marqh I wondered at the use case where a grid mapping would have a single
coordinate variable associated with it, but then I thought of the example of
zonal data that had latitudes but no longitudes. It's a somewhat odd case, but
it represents a valid identification.
--
You are receiving
The use of underscores like that can be problematic, for sure. Fixing that
overall would be a long-term project. What about some markup like this?
In the second format, it is a blank-separated list of words "**`grid mapping
variable`**: **`associated variable`** [**`associated variable`** …]
@davidhassell I think there is some level on which the checker needs to get
involved. It needs to check consistency in the **`grid_mapping`** attribute
string - verifying that the CRS (grid mapping) variables exist and the variable
names associated with each CRS variable exist and have matching
@marqh Is there an actual attribute named **`coordinates_variable`**? If not, I
would avoid this usage.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@davidhassell It seems to me that the issue is figuring out which variable maps
to which part. The rotated pole projection is a particularly thorny example. If
the goal is to allow for automated ordering, I think we'd have to lay out some
pretty specific syntax rules if we aren't depending on
If you dig into the WKT string to find the axes, shouldn't there be a pretty
clean mapping between the WKT axis names and the coordinate variable standard
names? What is the particular reason why people feel that this is insufficient?
--
You are receiving this because you are subscribed to
I want to make sure of the reason for this proposed change. This change is
being made to provide a way for software to automatically order the coordinate
variables correctly when handing a WKT string and coordinate values to a
function that would do coordinate transformation. We are mapping
@marqh That makes much better sense. I think we need to make sure that we
provide clear examples, as this can get confusing quickly.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@marqh It might be useful to provide an example that used a projected CRS WKT.
--
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/223#issuecomment-570287996
This list
@davidhassell If I am understanding @marqh's proposal correctly, you should
have only x and y for the coordinates associated with crs in the grid_mapping
attribute in your example. The implication of the coordinate variables x and y
in your example is that the coordinate system is a projected
@graybeal I read and understand the sentence in question this way:
A file that is compliant with a particular version of CF and contains a
declaration of the CF version used is not made invalid by any later change to
CF that would make the same file non-compliant if it was declared to use that
A few comments on the discussion to this point. I think the discussion is
moving in the overall right direction. If seems to me that there was confusion
at first between implementations and uses on the one hand and design and
conventions on the other. I think we need to seriously consider how
@dblodgett-usgs I think we've been managing OK so far. I don't care who wears
which hat.
--
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/148#issuecomment-437376121
@martinjuckes I started out with a similar idea a few years ago. ;-)
--
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/148#issuecomment-436760085
@ChrisBarker-NOAA If the UTC time stamps they start with are valid, then the
round-trip recovered time stamps will be valid UTC. (With all the standard
caveats about any instances where time measurements fell with leap second
spans.) The epoch time stamp does not have to be acquired for it to
@ChrisBarker-NOAA I think you got your case 2b correct the first time. The
epoch time stamp in the **`units`** attribute is correct UTC. The time stamps
that went into creating the time variable contents are all correct UTC, and
(except for time stamps falling with the span of a leap second
@martinjuckes I disagree with your characterization of what I am advocating
for, but I'm not sure how to reframe my argument. I am specifically excluding
modelers from the topic. It is only relevant for real-world time values.
Regarding the epoch time stamp, I agree that we need to be careful
@martinjuckes Where do you find that BIPM does this? I couldn't find it.
--
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/148#issuecomment-436709271
@JonathanGregory I'm thinking of existing files (built pre - CF-1.8) that have
time variables marked by the **`gregorian`** calendar. They may well not match
the new definition, but people won't likely look back to CF-1.7 or earlier to
see the difference between the old and new definitions.
@JonathanGregory I think we can likely leave LORAN-C off for now. There was the
original request for GPS time, I have, myself wished there was a TAI time when
I was building a dataset that depends on it.
I still think we should provide a path for data producers to clearly signal to
their users
Regarding the "broken" data. It's only broken from a purist compliance
perspective. It works quite well from a practical perspective.
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
I can't find a way to remove 'cf-metadata' as a contributor on this issue, so I
don't have a way to stop emails from this issue going to the CF-Metadata list,
if they are getting in there that way. @davidhassell do you know of a way? (I'm
not getting any emails on this issue from cf-metadata,
@ChrisBarker-NOAA @JonathanGregory Again, please back up a step or two and stop
thinking in terms of UTC and TAI and don't focus on the time stamps. What we
have in a time variable containing fully metric elapsed times is, in essence,
TAI with an offset subtracted. It is elapsed time since an
@ChrisBarker-NOAA UTC is, in practical terms, a specification for how to turn
TAI (a count of SI seconds since the TAI epoch) into time stamps that are
synchronized with the motions of the earth. It uses a combination of the
Gregorian calendar and leap seconds to achieve this goal. It does not,
@ChrisBarker-NOAA I love your name proposals!
I think your proposal to allow binary time stamps is a good one. Or even string
time stamps. It could have a standard name of **`time_stamp`**. For example, if
you organize a binary time stamp in 4-bit fields (which can be marked up using
@martinjuckes I appreciate your concerns. I think that the two new calendars I
have proposed provide a clear path for anyone who needs to do metric math with
time.
**`new calendar a`** signals to a user just how they should go about getting to
metric times from the time variable contents if
@jswhit I expect they well might. We aren't limiting the resolution by anything
we are doing here, are we?
--
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/148#issuecomment-435444196
Here's a good compendium of information about time systems.
https://www.ucolick.org/~sla/leapsecs/timescales.html
--
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/148#issuecomment-435417475
@jswhit There are no leap seconds prior to - depending on your viewpoint -
somewhere between 1958 to 1970, so **`gregorian_utc`** (**`new calendar a`**)
collapses to **`gregorian`** for dates prior to that range. I have no
preference over where that should be considered proleptic or not. I tend
Here's a bit of comic relief on this topic, courtesy of XKCD.
https://xkcd.com/2050/
--
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/148#issuecomment-435411435
@JonathanGregory
I think the new calendars, as you have described them, are not what I am
proposing, and I don't think it is the direction we should go. I think the
names were causing confusion in the discussion, and I get the impression that
it has influenced your thinking too. This is why I
@martinjuckes
Providing concrete examples like you did is quite useful. I should probably
have done so myself well before this. My apologies.
Let's say I am acquiring data once every 10 seconds using a GPS receiver to get
UTC time stamps. Around the last leap second I will have:
-
@martinjuckes How is the calendar formerly known as **`gregorian_utc`** not
consistent with use of SI time units?
--
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/148#issuecomment-435087156
1 - 100 of 132 matches
Mail list logo
