I read both [#69](https://cf-trac.llnl.gov/trac/ticket/69) and [#80](https://cf-pcmdi.llnl.gov/trac/ticket/80), and was startled by the sudden acceptance of these tickets after such long discussion of possible issues. (Credit here to Jonathan for flexibility!) Many of those issues are raised in this context, but this ticket proposes WKT be dominant in a much narrower sense (see detailed item (b) below).
I agree strongly with @margh's recent points, including the large value of data consumers being able to simply parse the WKT directly. It's key to recognize this is an augmentation, not a restriction. My detailed reasons follow, but first, I think the phrasing at the beginning of the proposal is creating unneeded alarm. Despite the misleading title, the proposal doesn't make WKT dominant, it just makes it directly usable (but still secondary, because the WKT is not required). I offer this as an equivalent rewrite of the proposal's first paragraph: > I propose that if a CRS WKT is present and can be used by the software > program, that the WKT should be allowed to stand alone as an official CRS of > the file by CF standards (thus, implicitly ignoring non-WKT CRS parameters). > However, non-WKT CRS parameters still must be present to serve as an official > representation of the CRS, in the event the software program cannot read in > the CRS WKT or chooses not to use it. In the text you wouldn't say anything like this of course. The text already describes how WKT is an optional augmentation, and that the non-WKT CF must be as complete as possible. I'd only tweak one line, just before the paragraph marqh highlighted, by replacing "as well as by crs_wkt" with "even if a crs_wkt is present", so now it reads: > Therefore the CRS should be described as thoroughly as possible with the > single-property attributes, even if a crs_wkt is present. With the [proposed precedence deletion of marqh](https://github.com/cf-convention/cf-conventions/issues/222#issuecomment-569938096) (item (c) below), I believe this fully captures the intent of the proposal. Detailed responses to a few points: (a) Yes ideally CF could be equally capable. On the other hand, WKT will continue to improve and many tools are and will be built around it. Does CF want to take on the job of "keeping up with WKT" and expect tool developers to "keep up with the CF version of WKT"? Even if we want that to happen, who in CF wants to volunteer to make it happen for CF? And in the tool community? (b) This seems to be a graceful co-habitation strategy. I don't see how this "breaks everything in the CF world"—it is adding a capability to CF, not breaking anything that exists. If the data creator doesn't add WKT, it doesn't apply. If the tool reading the file doesn't support WKT, it doesn't apply. Everything presented in CF will continue to work with all the tools written for CF. If I'm trying to create CF-compliant data, even if my WKT adds critical value I will want to make my CF as complete and accurate as I can for non-WKT applications, and the CF parameters are still required by the convention. (c) Supporting [the proposed precedence deletion of marqh](https://github.com/cf-convention/cf-conventions/issues/222#issuecomment-569938096): If the added WKT does not align with the CF, the data creator has introduced a bug. This can be corrected by social pressure (as is usually the case for any mistakes in the data) and does not require custom text in CF defining the "true meaning" (independent of the originator's intent). The tool creator is motivated to make their tool maximally useful given available time, including whether to favor the WKT expression and whether to cross-check the two expressions. Co-existence works here also and does not damage CF (because the CF parameters still have to be there). I'm assuming positive assessments of the prevalence of WKT, its features, and its community support for upgrades. If you agree these are favorable indicators, then there are two ways to consider the options. (1) How good will this be for existing CF users going forward? Although maybe not many of them need WKT yet, it will be favorable on balance, with little or no downside that I can see. And more broadly, (2) How much will this encourage/allow the geospatial community to easily adopt and use CF? I think it will be quite encouraging. -- 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-569989482 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].
