Since I've been the only one raising concerns about the proposal, which I'm a bit shame of, I must say that I agree with most of all that has been said by all of you.
Actually, I'm in contradiction with myself activities since, has I've said before, I've been putting some efforts for the radian units, for the geostationary projection, to be supported by other software than the java-netcdf. But what I really think, is that nothing of this wold be necessary if the geostationary coordinates units were defined in meters. Which is, I guess, what Proj library is using, and also GDAL for writing. As most of the projected coordinates systems (safeguarding some exceptions like the equirectangular projection and derived using latitude/longitude...). Like @erget said, and I totally agree, for those who are encoding netcdf files, as data producers, the impact of this changes will be minimum. My concerns goes for those who are, or that may be in future, developing automated processes for making projection transforms and post writing. Maybe It would be good that they have less exceptions to handle with... Any way, I totally agree that what has been discussed here is effectively a defect and it has to be solved. So, it won't be me who'll keep feeding the discussion. I'd also like to thanks to all of you that are participating and are giving their contribute for a better understanding of the implications of this change, in a way that the cf-conventions can keep responding to the CF community needs. -- 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-575898816 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.
