Conversation
|
@simonmoulds We came to the point where the decision to name "hourly" discharge also |
|
That didn't take long ;) In #3 we agreed to follow the convention Perhaps I've misunderstood the problem... |
|
Yes, the problem is rather the consistency of the meaning of instantaneous variables across different fetchers. I mean here they make it very clear that hourly values are averaged and 0 is really instantaneous but for other countries we simply took e.g. 15 minute data as instantaneous even though we don't know if this is an 15min average or instant value. I haven't checked the interval of the 0 timeseries yet. |
|
OK, got it. I tried to look at some 0 data but it was too much for my train wifi... Anyway, regular or irregular we can apply a consistent logic to the Norwegian data, i.e. "discharge_daily_mean", "discharge_hourly_mean", "discharge_instantaneous" (#46). As far as the other fetchers are concerned, my first thought is that we can only try our best to work out whether it's an aggregation or instantaneous, and document any cases where we're unsure. We might need to go back and revise some cases where we've assumed hourly is instantaneous. It's not ideal but I can't think of anything better... |
|
Okay, cool. Updated the code and it now supports all temporal resolutions. The instantaneous data is also at hourly resolution but IIUC, it is the measurement at this exact time, while the hourly data is the average over the measurements during the time bucket. Not sure how many measurements are considered for the hourly mean. Also include Terms of Use for the API in the docs (or the link to the terms of use sections in their API) |
* Add fetcher for Norway * Declare more columns as numeric * Formatting * Add unit tests * Add Norwary fetcher to docs * Change class init to accept api_token. Helps fixing test. * Fix data loading in test * Added support for more variables * Add hourly/instant resolution * Formatting
2 participants
Fixes #27