[CF-metadata] downward_air_velocity

From: Ben Hetland <Ben.A.Hetland>
Date: Fri, 12 Sep 2014 08:50:56 +0000

Jonathan Gregory <j.m.gregory at reading.ac.uk> wrote on the issue of "downward" and "upward" as separate standard names vs indicated by an attribute:
> If it was a separate attribute, it could be omitted, and probably sometimes
> would be (even if that was an error).

I second that, and I have seen it happen with other attributes many times (or often "units" is just misspelled as "unit").


> I expect you, like me, have experienced frustrations with analysing
> datasets where the quantities are described but their sign conventions
> not stated. With CF standard_names this problem cannot arise.

I think one of the "roles" a standard may play is to make such choices "once and for all". So terms like "eastward_" and "downward_" as part of the semantic definition of what the meaning of the variables are is very good. This simplifies the task for anyone trying to implement a reader software for the data.


> 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.

Considering software costs related to implementation complexity or performance, I would guess the most relevant is the annoyance of possibly considering alternative inputs on the reader side, which again carries the slightly increased risk of introducing bugs. Performance-wise only the cost of flipping the sign of every value is imposed, and if we are unlucky both the "writer" and "reader" need to do that. However, I expect that to be a very cheap operation on most modern processors, so is probably negligible compared to the rest of the NetCDF-related processing. Observing that a reader generally has to do decompressions, scaling and type conversion, and probably unit conversions to whatever it wants internally, then the consequence of the "wrong" sign is already dealt with, and any FIXED choice imposed by the standard carries no extra cost at all. To be fair, if one really insists on one's own preferred sign convention... I suspect the sign could even be "flipped" by just introducing a "-1" into the "units"
 attribute, right?


Regards,

-+-Ben-+-
Received on Fri Sep 12 2014 - 02:50:56 BST