I broadly agree with @rmendels (https://github.com/cf-convention/cf-conventions/issues/222#issuecomment-572780372) and @JonathanGregory three points (https://github.com/cf-convention/cf-conventions/issues/222#issuecomment-569325165). This is not a bad idea, but it is also not one that has a trivial implementation, and so would need some work before it should be accepted. My interest is a general one, but also as developer of CF-compliant software: `cfdm` and `cf-python`. These libraries currently ignore WKT. I would be happy to so extend them so that they did, but that is probably not a 5-minute job, as there first need to exist the well-defined mapping between those parts of WKT that correspond to CF parameters.
Expanding on one of the aforementioned points: - _We would have to revise (or consider revising) CF whenever the definition of WKT was amended_. On the face of it, this is the same issue that incorporating UGRID into CF has (https://github.com/cf-convention/cf-conventions/issues/153). However, the UGRID and CF communities overlap considerably, and it will be a **rule** that the UGRID experts consider CF when making changes, and also consider UGRID when CF changes. WKT will, I presume, evolve with no such reference CF. Thanks, David -- 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-572940491 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].
