Dear Ben > > It imposes a small cost by increasing the number of standard_names that > > have to be defined, but it's very easy to agree such pairs of > > standard_names, > > If I could have a say on this, I would prefer that the standard chooses just > one. Having the possibility of a dual set of names only serves the purpose of > complicating implementation of anything trying to parse the data. Flipping > the sign of a value is a trivial task, both for the writer and reader, so > doing that to satisfy a "simpler standard" is IMHO likely to be a cheaper > option than dealing with the increased namespace. This generally would not > cause any precision issues with the values being stored either.
That's a reasonable point of view which has been argued before. We have not done that because we don't see as the role of CF to prescribe what data should be stored, only to provide ways to describe it. If we tried to be prescriptive, it might either (a) prevent people from using CF, or (b) using it incorrectly, because it didn't quite fit their needs, but they didn't want to change how they did things. However, in practice most projects which generate CF data (like CMIP) have their own further conventions, which usually do prescribe more precisely what should be stored, in terms of standard names. So for any particular project your preference above is met, but it may differ from project to project. Best wishes Jonathan _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
