This seems mostly to be about making the CF Metadata Conventions consistent. @JimBiardCics provided an [excellent summary](https://github.com/cf-convention/cf-conventions/issues/230#issuecomment-575788782).
With this proposal, it appears the units used by the variable containing the map coordinates remains the same before and after the change (both use radians), and none of the projection math changes. That's a win in terms of "not much work", I think. This proposal isn't suggesting we start allowing the map coordinate variable to use meters in addition to radians, is it? One might get that impression (see https://github.com/cf-convention/cf-conventions/pull/232/files#r368206817). That kind of change could might add up to some work. But assuming that's not the case, we're basically looking at a change in value of the `standard_name` attribute to prevent the CF document from becoming CF-ish. In this specific case (`standard_name` of a coordinate variable containing map coordinates), what practically, is the `standard_name` attributes use? Already TL;DR;? Ok, I'll cut to the chase - I'm in favor of this change (for what it's worth). I'll say up front that being consistent is a good thing on its own, even if adds to my own pile of work :-) So again, the question is, what kind of work would be created by this change. There are two perspectives from which we can look at this: reading vs writing. And to make things painful, I'll bring up netCDF-Java in particular, because that's the implementation I know (I think). Your mileage may vary. ## Impact on reading For reading purposes, I'm not sure what the `standard_name` and its specific value it would be used for outside of compliance checking. I guess it could be used to identify a potential coordinate variables (hello there, strawman). However, CF does not appear to suggest that coordinate variables should ever be identified in using the `standard_name` attribute, but through either: 1. the NUG definition (names of a 1D variable and dimension match), or 2. the variable name appearing in the `coordinates` attribute. This is what netCDF-Java does when it encounters a global attribute `Conventions` with string value partially matching `CF-1.` (and others cases, but for sure CF). Because of the Geostationary projection definition in the CF document, we (netCDF-Java) assume the map coordinates are some in form of radians and we run with it (scissors in hand). We never look at the `standard_name` attribute in this case. Since that assumption does not change with this proposal, the netCDF-Java library is good to go. Now, code might be looking at the `standard_name` attribute as an attempt to be flexible (a worthy effort, except for a compliance checker, for sure), but that's outside of the CF specification as far as I can tell. So, for reading purposes (outside of a compliance checker use case), the question is, what does the `standard_name` actually provide in practice? That is: ~~~bash if (standard_name == "projection_x_coordinate": // then what? ~~~ Honest question, and any insights would be helpful to the discussion, I believe. As as Billy the Kid (played by Emilio Estavez) said in the movie Young Guns, "[t]here's many a slip twixt the convention and the implementation" (I think that's how it goes...), and I'm only looking from the point of view of one implementation. ## Impact on writing For writing, then it becomes a little more tricky, but only if you want to write a file with a global attribute `Conventions` whose string value is `CF-1.9` or above. At that point, you've already updated the code to bump the CF version being written out, so might as well update the `standard_name` attribute on the variable holding the map coordinate data to use the newer `_angular_` flavor. The actual data in the array does not change, the unit does not change, just the value of the `standard_name` attribute attached to the variable. This will impact netCDF-Java directly, but only slightly. When we write data to CF compliant netCDF files, we try to make sure the required CF attributes are attached to the variables holding the map coordinate data. Currently, we check to see if we are dealing with a coordinate variable holding map coordinate data, and if so, we make sure it has a `standard_name` attribute with a value of `projection_x_coordinate` or `projection_y_coordinate`. After this change, we will need to add a few lines to check what the Conventions attribute says, and if 1.9 or greater, check the units on the variable. If the units are compatible with meters, then use `projection_x_coordinate`, if compatible with radians, use the new `projection_<x|y>_angular_coordinate` values. We could get more picky and only allow the `_angular_` version for geostationary projections - we'll see as the discussion on this issue continues. As far as I can tell, nothing else changes on my end. Again, for what it's worth, at this point I'm +1 on this change. -- 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-575868782 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.
