Re: [CF-metadata] [cf-convention/cf-conventions] Add unit_conversion_factor for units in coordinate axis to represent the number of SI standard units per unit (i.e. meters). (#248)
@snowman2, I'm the UDUNITS developer. I've never heard of these units. Do you have a reference for them (other than the GitHub repository)? -- 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-593453925 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Updating definition of coordinate variable to account for NUG changes (#174)
@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 must be true. This is the only word that defines a hard requirement. * should - It is desired, but it is not required. * may - It is allowed, but it is not required. The word "must" is a synonym for shall. The word "can" is a synonym for may. We have not adhered to precise language in the past, but that is part of the reason we are having a problem now. We regularly encounter situations where people say, "What we meant by that sentence was ...". Part of what I'm trying to achieve here is writing precise declarative statements using words in a way that leave (ideally) no room for doubt. The NUG doesn't do that. Neither, in many cases, does CF. -- 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-593454952 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Add unit_conversion_factor for units in coordinate axis to represent the number of SI standard units per unit (i.e. meters). (#248)
@semmerson, you can go to http://www.epsg-registry.org/ and filter by the unit of measure type. For example:  -- 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-593459434 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
[CF-metadata] [cf-convention/cf-conventions] Proposal: Example for Independent Latitude, Longitude, Non-spatiotemporal Variable, and Time Axes (#249)
# Title Example for Independent Latitude, Longitude, Non-spatiotemporal Variable, and Time Axes # Moderator @GeyerB # Moderator Status Review [last updated: 20/03/02] no update yet # Requirement Summary Analogue to chapter `5.1. Independent Latitude, Longitude, Vertical, and Time Axes`, where the use of spatiotemporal dimensions is explained we should explain how to structure data with `Independent Latitude, Longitude, Non-spatiotemporal Variable, and Time Axes`. The new class of standard_names starting with `probability_distribution_of` belongs to that group. We could have a new subchapter of chapter 5 or an annex with additional examples for all sorts of such examples coming in future. # Technical Proposal Summary **Independent Latitude, Longitude, Non-spatiotemporal Variable, and Time Axes** For probability distributions of variables, dimensions are used to locate data values in time and space and in the range of the variable itself. **Example: Independent coordinate variables with non-spatiotemporal variables** ``` dimensions: time = UNLIMITED; // (5 currently) nbin = 36; nv = 2; variables: double time(time); time: standard_name = "time"; time: long_name = "time" ; time: units = "days since 1970-01-01 00:00:00" ; time: bounds = "time_bnds"; double time_bnds(time,nv); float class(nbin); class: standard_name = "wind_from_direction" class: long_name = "wind sector"; class: units = "degree"; class: bounds = "class_bnds"; float class_bnds(nbin,nv); float WDIR_freq(time,lat,lon,class); WDIR_freq: standard_name = "probability_distribution_of_wind_from_direction_over_time"; WDIR_freq: units = "1"; WDIR_freq: coordinates = "lon lat class" WDIR_freq: cell_methods = "time: sum (interval: 40s)" ``` # Benefits Users of the new category of standard_names starting with probability_distribution get a roadmap how to construct such data files. # Status Quo No example available. # Detailed Proposal see above -- 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/249 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Add direction attribute for coordinate axis (#247)
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 work, but I think that is wholly out of scope here. -- 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/247#issuecomment-593505538 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Add unit_conversion_factor for units in coordinate axis to represent the number of SI standard units per unit (i.e. meters). (#248)
@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 forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Add new integer types to CF (#243)
@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`**, **`unsigned int`**, **`int64`**, or **`unsigned int64`**. This covers both "an integer type" and "any integer type". -- 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-593511337 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Proposal: Example for Independent Latitude, Longitude, Non-spatiotemporal Variable, and Time Axes (#249)
I agree that it would be a good idea to add such an example. Thanks. -- 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/249#issuecomment-593550945 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Add unit_conversion_factor for units in coordinate axis to represent the number of SI standard units per unit (i.e. meters). (#248)
I think that is all I have to offer for clarifying information on this issue. I will close it now since it seems that :-1: is the consensus here on 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/248#issuecomment-593517283 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Add direction attribute for coordinate axis (#247)
For horizontal coordinates, the CF `axis` attribute should be used to indicate which axis is `X` and which `Y`, where `X` is "like" longitude and `Y` "like" latitude. This correspondence can't really be more than a rough guide, for reasons mentioned above. Doesn't the `axis` attribute meet the need? I don't think we need to introduce anything new to describe a CRS. We know that CF metadata isn't arranged the same way as OGC metadata, since the data model is different, but so long as we can translate, I think that should be OK. -- 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/247#issuecomment-593550091 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Add direction attribute for coordinate axis (#247)
@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 to think of a good name yet) that will be added to each dimensional or auxiliary coordinate variable that declares the handedness of the coordinate system and declares which mathematical coordinate axis the variable is expressing. For a lat/lon/height coordinate reference system (CRS), the information contained in each attribute would be: * lat.fluffy - left-handed X * lon.fluffy - left-handed Y * height.fluffy - left-handed Z For a polar stereographic CRS, the information would be: * x.fluffy - right-handed X * y.fluffy - right-handed Y * height.fluffy - right-handed Z For a lat/lon/depth CRS, the information would be: * lat.fluffy - right-handed X * lon.fluffy - right-handed Y * depth.fluffy - right-handed Z The values of the attribute "fluffy" above are not intended as the actual words. I'm trying to express the information that is required, but I haven't thought of what precise words should be used. If the use of X, Y, and Z above is bothersome, feel free to refer to i, j, and k or first, second, and third instead. Some of the information may seem wrong at first glance. I was surprised when I discovered a few years ago that the lat/lon/height coordinate system is formally a left-handed coordinate system. I had just assumed that putting latitude first was "merely" a historical practice that wasn't prescriptive. -- 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/247#issuecomment-593503888 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Add unit_conversion_factor for units in coordinate axis to represent the number of SI standard units per unit (i.e. meters). (#248)
Closed #248. -- 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#event-3088905534 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
