There are two perspectives in this thread (and the original WKT discussions) about what it means for optional 'containers' like WKT to be acknowledged as 'valid' in CF. In one view, the acknowledgement puts some or all of the responsibility for validating the container's content on CF, the CF validation software, and the CF tool developers. In the other view, it can be treated as a black box, with the responsibility for correctly including WKT content, verifying WKT content, and using WKT content relegated to the actual WKT providers and users.
I think the acceptance of WKT as an 'allowed' container in those original proposals implicitly adopted the second view. To my understanding no tests for WKT content validity have been added, and tools have not been required to change anything. The gist of the proposal seemed in line with that view, because WKTs would still be optional and the CF attributes would still be required to the maximum extent possible. Therefore, I think the best approach is to modify the proposal to make it fully consistent with the second view, because that lets CF dynamically and quickly adapt to advanced needs of an important community. > _If the CRS cannot be represented using the grid mapping parameters, using > only the crs_wkt attribute is considered valid._ > > Sorry, but to my untrained eyes this essentially means software that purports > to be CF compliant will have to be able to deal with WKT. It is very simple, > I have a transformation that can't be represented by present grid mapping > parameters, I use the crs_wkt attribute, based on the standard that says the > file is CF-compliant but a lot of software that has been the basis for > CF-compliance will not be able to properly read that file. I must be missing > something here because I don't see anyway around this. It will create > CF-complaint files that present software will not be able to properly read. > Which will mean either a lot of incompatible files or possibly a lot of work > for the authors of the present software that are the backbone of > CF-compliance. I agree that the quoted sentence is ambiguous and inconsistent with other text. I'd prefer it went away; or at least be expressed as "If the CRS cannot be fully represented using the grid mapping parameters, the additional crs_wkt attribute can be used to augment the representation (while noting that support for reading and using the crs_wkt attribute in CF software remains entirely optional)." Still, there are oodles of CF-compliant data files that present software can't "properly" read, because they have various optional augmentations in them not understood by all software. The fact this particular optional augmentation is mentioned explicitly does not mean everyone, or even anyone, has to support it. It also does not mean that any testing or conformance software *has to* support or test WKT, any more than allowing multiple conventions in the convention attribute means you have to support and test all of the conventions that might be referenced by that attribute. > We would have to revise (or consider revising) CF whenever the definition of > WKT was amended. I'm not sure why. The only thing the WKT content can affect is another CF tool that reads WKT. All the existing tools that ignore WKT should not be impacted, they'll ignore WKT no matter what its definition is. Now, the tools that use WKT in CF might have to decide how to deal with WKT versions, but they could do that without ever having to require changes to the CF specification. -- 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-573382592 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].
