You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 have degC
2. Precipitation
95 datasets have the units mm d-1; 141 have the units mm day-1; 2319 datasets have the units kg 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 pacificclimate/climate-explorer-frontend#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:
users directly accessing the API or exporting data from the front end could more easily compare data with their own tools and applications
possible future frontend development might want to compare variables directly
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:
Canonize units. That appears to be the main point here.
That does not seem unreasonable or too hard to do.
Convert units? In the sense of converting data values to different units?
I think it should be left to the client apps (PCEX, P2A, whatever else) to convert units as their interface requirements dictate. P2A already does this.
Convert units to user's request?? That is, add a units param to the API and convert to the specified units if valid. I am not sure that is implied here, but it could be read so.
@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 pacificclimate/climate-explorer-frontend#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:The text was updated successfully, but these errors were encountered: