Open corviday opened 4 years ago
I'm not convinced that doing this, or at least all of what might be implied here, is the best idea. It seems like there might be 3 implications:
@jameshiebert also made the point elsewhere that unit equivalence (and conversions) are differ from variable class to variable class. For example, precipitation can be reported in kg m-2 d-1
or, equivalently for precipitation (as liquid water) mm d-1
. In general that is not a valid equivalence because it is only for liquid water. We have another case lurking about in the form of snowfall, which may be provided in units kg m-2 d-1
but is often wished to be displayed in mm yr-1
, and for which the conversion factor is 10 times that for liquid water.
So I think we need to careful at least in how we approach the second question if indeed it is being contemplated, and equally the third.
While datasets of each variable in active use have matching units, intervariable unit names vary:
1. Temperature 1177 datasets have the units
degrees_C
; 2056 havedegC
2. Precipitation 95 datasets have the units
mm d-1
; 141 have the unitsmm day-1
; 2319 datasets have the unitskg m-2 d-1
, which may not be automatically convertible.Currently, nothing in the front end explicitly requires that units from different variables be formatted similarly in order to compare them (see https://github.com/pacificclimate/climate-explorer-frontend/issues/107 - we had this requirement once, but changed it).
Still, there are several ways that providing canonically formatted units using a package like
udunits
might be helpful in the future, and is worth doing: