Dear @JimBiardCics I appreciate the point and I agree that we should not spend our time doing a less good job of something which is already available elsewhere. However I don't think that CF is fairly described as "reinventing the wheel" in this case. I can suggest a few reasons why we have our own set of `grid_mapping` definitions rather than relying on `proj4` for example.
* An external resource might not include all the cases we need. Does `proj4` include rotated pole and vertical perspective, for instance? (If it does that is not noted in our App F). If it's not our own resource, we can't necessarily add to it, and if it's not comprehensive, users of CF might have to mix different conventions in their files, which would be less satisfactory. * An external resource might change in a way which didn't suit CF, meaning we'd have to do extra work in a hurry to replace it with something else, with the further penalty of backwards-incompatibility for CF. * An external resource might not present the information in a way which is easily usable in CF, because it's not organised in a similar fashion or doesn't match well to the CF data model. Therefore instead of "handing over" something to an external authority, I feel that in most cases it is better to import the external information to CF. This isn't an absolute rule, of course, but it seems fine for `grid_mapping` to me. However, your point is a good reason why we should make the choice of attributes as similar as we can to `proj4`. If we do that, it should be easy to import more of them, like new standard names on existing patterns, and it improves interoperability between conventions. If we find there is a use case which is *not* trivial to import, there's probably a good reason for that which will require some thought, like new standard names which propose new patterns. Best wishes 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-589614662 This list forwards relevant notifications from Github. It is distinct from [email protected], 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 [email protected].
