Re: [CF-metadata] [cf-convention/cf-conventions] Allow CRS WKT to represent the CRS without requiring reader to compare with grid mapping parameters (#222)
Oh, I just saw that the crossed out "is". Sorry. -- 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-656300980 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] Allow CRS WKT to represent the CRS without requiring reader to compare with grid mapping parameters (#222)
@snowman2 My poor brain can't seem to detect what exactly was tweaked. Could you please point to the specific change made? -- 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-656300687 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] Allow CRS WKT to represent the CRS without requiring reader to compare with grid mapping parameters (#222)
Minor tweak: For example, if the semi-major axis length of the ellipsoid ~~is~~ defined by the grid mapping attribute semi_major_axis **disagrees with** the crs_wkt attribute (via the WKT SPHEROID[…] element), the value of this attribute cannot be interpreted accurately. -- 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-656297951 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] Allow CRS WKT to represent the CRS without requiring reader to compare with grid mapping parameters (#222)
Yes, I think the intent of this is fine. I don't recall the text that precedes the revised text, but should the first sentence read: "If, *for a given property,* both crs_wkt and grid mapping attributes exist, the attributes must be the same and grid mapping parameters should always be completed as fully as possible" Also, is the second clause dependent on the first clause, or in general is it true that "grid mapping parameters should always be completed as fully as possible." If it is generally true, I think the second clause should be its own sentence (and maybe it should appear elsewhere?). -- 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-656287914 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] Allow CRS WKT to represent the CRS without requiring reader to compare with grid mapping parameters (#222)
This issue doesn't have a moderator - I think that's why it's not progressed. I will moderate it. @snowman2's current proposal (https://github.com/cf-convention/cf-conventions/pull/282) is to replace However, in those situations where two values of a given property are different, then the value specified by the single-property attribute shall take precedence. For example, if the semi-major axis length of the ellipsoid is defined by the grid mapping attribute semi_major_axis and also by the crs_wkt attribute (via the WKT SPHEROID[…] element) then the former, being the more specific attribute, takes precedence. with If both crs_wkt and grid mapping attributes exist, the attributes must be the same and grid mapping parameters should always be completed as fully as possible. As such, information from either one (or both) may be read in by the user without needing to check both. However, in those situations where the two values of a given property are different, the CRS information cannot be interpreted accurately and users should inform the provider so the issue can be addressed. For example, if the semi-major axis length of the ellipsoid is defined by the grid mapping attribute semi_major_axis and also by the crs_wkt attribute (via the WKT SPHEROID[…] element), the value of this attribute cannot be interpreted accurately. I think this is OK, except for the last sentence, which I think should be For example, if the semi-major axis length of the ellipsoid is defined by the grid mapping attribute semi_major_axis **disagrees with** the crs_wkt attribute (via the WKT SPHEROID[…] element), the value of this attribute cannot be interpreted accurately. That leads naturally to the unaltered final sentence, "Naturally if the two values are equal then no ambiguity arises." Philip @cameronsmith1 and Karl @taylor13, are you content with this? Alan @snowman2, is my amendment OK with you? Jonathan -- 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-656272355 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] Broken link to NUG Definition of Coordinate Variables (#283)
Hello all, While searching for defining characteristics of a _coordinate variable_ versus a _geospatial variable_, I found this issue. I marked it as a defect. My search also brought me to related issue #174, which seems to not have been resolved yet. # Hyperlink to the NetCDF Users Guide (NUG) Definition of _coordinate variable_ is broken # Technical Proposal Summary The aforementioned broken link, http://www.unidata.ucar.edu/software/netcdf/docs/netcdf_data_set_components.html#coordinate_variables should be replaced with the working link https://www.unidata.ucar.edu/software/netcdf/documentation/NUG/_best_practices.html#bp_Conventions # Benefits Removal of broken link # Status Quo The current stable CF Document, version 1.8, [section 1.2](http://cfconventions.org/Data/cf-conventions/cf-conventions-1.8/cf-conventions.html#terminology) defines a _coordinate variable_ and provides a hyperlink to the NetCDF Users Guide (NUG) definition of a _coordinate variable_ in the following block: > __coordinate variable__ > We use this term precisely as it is defined in the [NUG section on coordinate > variables](http://www.unidata.ucar.edu/software/netcdf/docs/netcdf_data_set_components.html#coordinate_variables). > It is a one-dimensional variable with the same name as its dimension [e.g., > time(time) ], and it is defined as a numeric data type with values that are > ordered monotonically. Missing values are not allowed in coordinate variables. Said link is broken and returns a 404 error. # Detailed Proposal Replace broken link with working link as detailed 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/283 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.