Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Support for all time monthly averages #69

Open
KasturiNagarWeather opened this issue Aug 16, 2022 · 14 comments
Open

Support for all time monthly averages #69

KasturiNagarWeather opened this issue Aug 16, 2022 · 14 comments
Assignees
@mKainzbauer
Labels
enhancement

Comments

@KasturiNagarWeather
Copy link

Great history page.

Can we have a last row after all years with average for all years month wise? Like Jan average across all years, Feb average across all years and so on? I know this is something that weewx doesnt support natively and we need to create xtypes for same.
@mKainzbauer
Copy link
Collaborator

There is already an extension for calculating such averages: https://github.com/gjr80/weewx-averages
I'll check if it can be utilized.

@swfrx
Copy link

swfrx commented Jan 26, 2023

Ideally this would be part of the table, not separate from it.

@mKainzbauer
Copy link
Collaborator

After releasing the next version, I will take care of this.

@mKainzbauer mKainzbauer self-assigned this Mar 7, 2023
@mKainzbauer
Copy link
Collaborator

I've still didn't have the time to take care about this and I am not sure how to present it on the page, it may overload it.

@Fux2
Copy link

Fux2 commented Dec 14, 2024

Would like that feature as well.
I think the arrangement how to integrate should be quite straight forward:
averageOverYears

@mKainzbauer
Copy link
Collaborator

Ok, then let's specify the desired behavior:

We want to have the possibility to show averages for calendar months and calendar years on the history page. For calculating monthly averages, every fully covered calendar month/year in the database will taken for calculation:
In the above example:

  • the average January is calculated using Jan 2016 through Jan 2024
  • the average August is calculated using Aug 2016 through Aug 2024
  • the average September is calculated using Sep 2015 through Sep 2024
  • the average December is calculated using Dec 2015 through Dec 2023
  • the average year is calculated using 2016 through 2023

A "fully covered" month/year is considered a month/year which has a directly preceding and a directly following period containing values, which, in the example above, are Sep 2015 trough Nov 2024 for the months, and 2016 through 2023 for the years.
It shall be possible to show/hide the row containing the overall averages by configuration, for each and every summary table.

Furthermore, it should be possible to show the min/max values in the same manner. In the example above, the minimum minTemp for Januarys is -17.6, the average minTemp -9.5, the maximum minTemp -3.1.

Any additions? Are there observation types where this is not possible? For windDir a min or max wouldn't make any sense, the average would be the dominating direction.

@swfrx
Copy link

swfrx commented Dec 14, 2024 via email

@mKainzbauer
Copy link
Collaborator

I was referring to #69 (comment) where @Fux2 posted the minTemp table, obviously a SC from my station: https://kainzbauer.net/weather/Rif/de/history.html

@swfrx
Copy link

swfrx commented Dec 14, 2024 via email

@Fux2
Copy link

Fux2 commented Dec 23, 2024

@mKainzbauer: Full acknowledge.
Thinkings about windDir are fine as well.

Yes, the posted picture was a mock-up - made from a screenshot with some additions (average values are not correct and just as an example).

Ok, then let's specify the desired behavior:

We want to have the possibility to show averages for calendar months and calendar years on the history page. For calculating monthly averages, every fully covered calendar month/year in the database will taken for calculation: In the above example:

* the average January is calculated using Jan 2016 through Jan 2024

* the average August is calculated using Aug 2016 through Aug 2024

* the average September is calculated using Sep 2015 through Sep 2024

* the average December is calculated using Dec 2015 through Dec 2023

* the average year is calculated using 2016 through 2023

A "fully covered" month/year is considered a month/year which has a directly preceding and a directly following period containing values, which, in the example above, are Sep 2015 trough Nov 2024 for the months, and 2016 through 2023 for the years. It shall be possible to show/hide the row containing the overall averages by configuration, for each and every summary table.

Furthermore, it should be possible to show the min/max values in the same manner. In the example above, the minimum minTemp for Januarys is -17.6, the average minTemp -9.5, the maximum minTemp -3.1.

Any additions? Are there observation types where this is not possible? For windDir a min or max wouldn't make any sense, the average would be the dominating direction.

@swfrx
Copy link

swfrx commented Jan 9, 2025 via email

@mKainzbauer
Copy link
Collaborator

What you propose is the average average/sum/high/low/... of values that where recorded in a calendar month with a specific name. That's not my understanding of what's desired. What's desired is the average average/sum/high/low/... of a calendar month with a specific name, which only makes sense when a month is fully covered, at least to a certain degree. For instance, around the 45° N an average first of April will have a significantly lower mean outTemp than an average 30th of April. Or worse, regarding discrete obs_types: when you have covered very wet July 29, 30 and 31, but not the rest of the month, the average rainfall for this month would be completely out of the ballpark.
I do agree there has to be a bit of a fuzzy definition of what "fully covered" means, because every once in a while even the most reliable of our stations will miss the one or the other archive interval.

@swfrx
Copy link

swfrx commented Jan 10, 2025 via email

@mKainzbauer
Copy link
Collaborator

No such thing at all. Because we will work with what we've got and we won't overcomplicate things:

  • we already have min/max/avg Tables and the values
  • we will assume, that every month, that has any data before/after it, is completely covered
  • we thus will take these already calculated values (except for two, the first and the last, most of the time) for further calculations
  • we will document how everything works

In cases, where there may be significant data gaps, we know: it's a data problem, and we won't invent any quirky algorithms, tweaks, or whatever else, to pretend a data accuracy that simply isn't there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@mKainzbauer mKainzbauer

Labels
enhancement
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@Fux2 @KasturiNagarWeather @swfrx @mKainzbauer