@graybeal I am also in favor of the "black box" approach to WKT. We should accept the work of the experts that develop WKT and define CRSs using it, and trust the registered WKT strings for different CRSs. Someone can always produce an incorrect WKT CRS string, but someone can also produce an incorrect grid mapping variable. The CF checker doesn't try to verify the exact contents of grid mapping variables, so I don't see why we should involve ourselves with verifying the exact contents of WKT CRS strings.
(Mild rant alert) The great majority of CF files don't contain grid mapping information. A number of those that do contain incorrect information — either improperly chosen attributes or incorrect values for the attributes. (Based on the small sample of datasets that I've QC'd, most of the producers who add grid mapping get it wrong.) Tools that are able to use grid mapping attributes and attempt to use any of these files will not produce "best" results, and will in some cases produce crazy results. I am therefore not overly swayed by the appeal to issues for existing software. Existing tools that use grid mapping variables do so because that was the mechanism which was provided. If we had provided WKT or Proj strings from the beginning, those are what existing software would be using. I confess that I haven't done the work to prove it, but I believe that the CF grid mapping attributes are insufficient to fully represent most CRSs, even the ones that we claim to support. They are sufficient if your spatial accuracy and precision is rougher than a kilometer or so, but if you are are concerned about meter-level (or better) accuracy in all three spatial dimensions, I don't think we support enough of the attributes needed to do so. I think we should be encouraging software tool developers to embrace WKT (and/or Proj) CRS declarations instead of viewing them as second-class citizens in CF-land. I'd love to see a day arrive when we decided to deprecate grid mapping attributes for new files. -- 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-573726528 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.
