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
{{ message }}
This repository has been archived by the owner on Aug 28, 2023. It is now read-only.
#Because precipitation is measured in the raw data using obscure units of rate, kg/m^2/s, in our indicator response the values are also units of rate... we convert kg/m^2 to linear distance by using the density of water as 1000 kg/m^3, but keep the time denominator as return values such as in/day.
Currently there are only three precipitation indicators (Two after #162):
YearlyTotalPrecipitation
MonthlyTotalPrecipitation
DailyPrecipitation
Because precipitation is measured internally as average over the entire day, and each of these indicators are a total of varying levels of granularity (Total precipitation over a year, month, and day, respectively), I think it makes sense to use units that do not include a time component. Whether the user requests precipitation to be measured in mass or linear distance, the time component indicates the number as a rate, while the indicators suggest a total.
Rate would be desired for an indicator like HeaviestPrecipitation, which could be measured in in/hr, for instance, but the total precipitation over an aggregation period would be measured in kg/m^2, in or mm (For example in WeatherDB)
The text was updated successfully, but these errors were encountered:
#Because precipitation is measured in the raw data using obscure units of rate,
kg/m^2/s
, in our indicator response the values are also units of rate... we convertkg/m^2
to linear distance by using the density of water as1000 kg/m^3
, but keep the time denominator as return values such asin/day
.Currently there are only three precipitation indicators (Two after #162):
Because precipitation is measured internally as average over the entire day, and each of these indicators are a total of varying levels of granularity (Total precipitation over a year, month, and day, respectively), I think it makes sense to use units that do not include a time component. Whether the user requests precipitation to be measured in mass or linear distance, the time component indicates the number as a rate, while the indicators suggest a total.
Rate would be desired for an indicator like HeaviestPrecipitation, which could be measured in
in/hr
, for instance, but the total precipitation over an aggregation period would be measured inkg/m^2
,in
ormm
(For example in WeatherDB)The text was updated successfully, but these errors were encountered: