search

SciTools / cf-units

Units of measure as required by the Climate and Forecast (CF) Metadata Conventions
https://cf-units.readthedocs.io/en/latest/
BSD 3-Clause "New" or "Revised" License
64 stars 49 forks source link

Representing measurement conditions #78

Closed duncanwp closed 6 years ago

duncanwp commented 7 years ago

When considering many atmospheric measurements it is important to know if it was made in 'ambient conditions' or 'standard temperature and pressure' conditions.

I've seen many ways these might be represented in the units of a measurement, for example: 'per std cc' or 'cm-3 at stp'. I think I'm right in saying that the CF-conventions don't have anything to say on the matter, but I wonder if this is something that this library could help take care of?

Even if it's just in the form of a flag to indicate if the measurement represents ambient conditions or not. If you think it would be in the scope of cf_units I could try and propose something more concrete in a pull request.

pelson commented 6 years ago

Confession: I've spent about 30 seconds thinking about this, so do not consider these to be well rounded opinions...

If you think it would be in the scope of cf_units I could try and propose something more concrete in a pull request.

I probably prefer to see this integrated into udunits, if at all possible.

Alternatively, is this really about being able to reference other phenomena/surfaces e.g. "meters (above sea level)"? Do we really need to make this a higher level concept (i.e. in Iris)?

duncanwp commented 6 years ago

Yes, I think udunits might be a better place on reflection.

I realised that for a few phenomena this is actually included in the standard name (e.g. 'number_concentration_of_aerosol_particles_at_stp_in_air') but I think it should really be more general than that.

I'll raise it with udunits for now.

pp-mo commented 6 years ago

IMHO, Udunits has a very limited ambition regarding the useful definition of measurements. It is basically limited to arithmetic concepts, and really will not readily extend to "means of measurement" or "conditions of measurement" or "context of meaning" type parts.

For a notable instance, it does not distinguish between relative and absolute quantities (i.e. measures referred to a datum), hence the fraught nature of conversions between K and degC. (and calendars pose a similar problem).

We might well try to improve on this, especially for Iris, but being so tightly wedded to CF means we can really only make improvements that can be squeezed through that keyhole.

There are in fact much better Python attempts at this problem. I think astropy.units usually gets a mention : http://docs.astropy.org/en/stable/units/. But there are lots, actually rather too many and no great degree of consensus. See : https://conference.scipy.org/scipy2013/presentation_detail.php?id=174 -- N.B. shows multiple solutions, is good on the basics but now pretty old.