> But, if the user wants to check the values for consistency, then when they > conflict, the user should assume the CF value is correct. This gives the data > writer a little extra incentive to try to get things right when converting > the WKT metadata to CF.
I think that if the values are not consistent, it does not make sense to default to CF or WKT as either one or both could be incorrect depending on your starting format of the CRS and how the conversion was done. In the proposal, it adds this clarification: > *If conflicts exist between the representations, you should inform the > provider so they can be addressed.* Reasoning for this wording mentioned in the proposal: > The CRS could originate from several different formats such as WKT, PROJ, or > SRS Authority Code. If there are errors in the conversion process to the CF > or WKT representation, only the provider would have the original CRS > representation. As such, if there are conflicts, the provider would be the > best source to go to in order to resolve the conflicts. -- 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-642734208 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.
