Yet Another Dayfile Reader (PHP)

[beteljuice]

May I gently remind you all that in the very first post ...

Anyone can 'play', but the beteljuice will NOT be answering any 'general' enquiries along the lines of "How do I ..." and "I want ...".

... and my 'quota' of good guy helpfulness is pretty much stretched out at the moment.

Is it possible to add a column row and have the year totals as well

... most things are possible (although that seem seems a little bit overkill IMHO), If you remember whilst we were messing with modifying the code, that's what it did.)

If / when I do a redistribution, PM me and if I'm in a good mood / compos mentis I'll give you a 'patch' so you can have year averages AND totals (although totals might break the cell widths)

So spake the beteljuice

Any more want the year rain alternative option ???

[berwickw]

+1 for the new rainfall option

[beteljuice]

@Sutne ...

All the beteljuices cogs weren't engaged when you enquired ..

Is it possible to add a column and have the year totals as well

There simply isn't room for another column in the existing layout, especially one that could contain a large number - doable, but sorry, you're on your own with that way.

The way the table is constructed the 'year' column value has been declared long before any maths are performed, so not easy to even create a 'mouse-over' year total value without a recode.

Getting the values is no great hardship - if you <view-source> http://beteljuice.co.uk/daytest/abasic7 ... a=rainfall you'll see ...

Code: Select all

<div id="tableData">
<!-- 2019 rainfall TOTAL > 469.8 -->
<!-- 2018 rainfall TOTAL > 829.2 -->
<!-- 2017 rainfall TOTAL > 747.4 -->
<!-- 2016 rainfall TOTAL > 714.2 -->
<!-- 2015 rainfall TOTAL > 664.4 -->
<!-- 2014 rainfall TOTAL > 749.2 -->
<!-- 2013 rainfall TOTAL > 972.8 -->
<!-- 2012 rainfall TOTAL > 689.2 -->
<!-- 2011 rainfall TOTAL > 943.4 -->
<!-- 2010 rainfall TOTAL > 717.8 -->
<!-- 2009 rainfall TOTAL > 829 -->
<!-- 2008 rainfall TOTAL > 218.2 -->
    <div id="table_container">

It's putting it somewhere 'useful' that is the problem

[billy]

I share with Phil the same desires for monthly rainfall totals in the year averages table and an indifference to daily averages. I had been contemplating doing something about if for a while and hadn't got around to it until a few days ago. I started modifying the dayfile reader and then when I got into some difficulty (with colouring cells) thought I had better check the forum .

So, in short, beteljuice, I support the request - hoping this might be like chucking a dog a bone . I will throw in a couple of other thoughts.

First, a running total for the current year immediately below the monthly totals in the daily summaries table would be really useful. There are two reasons for this: (a) here in southwest Western Australia we get most of our rain in winter (Perth has the wettest winter and the driest summer of any Australian capital city) and we seem to be at or near the forefront of climate change with respect to a reduction in annual rainfall (already down about 30% on the long term average) so there is a lot of focus on "how is our rainfall going this year?" A running total would make this easy to follow - at least for the current year. And (b) if it was also available in the seasonal table it would solve the "total column" issue. It would be too messy interleaved into the year average table.

Second, the averages in the year averages table include months with incomplete data sets. I was planning to exclude these - if I figured out the code!

[beteljuice]

Second, the averages in the year averages table include months with incomplete data sets. I was planning to exclude these

That would only make the year average figures more inaccurate.

They are actual averages ie. over the number of days where records exist rather than days in month.

[mcrossley]

I was revisiting this and playing with doing a complete rewrite using SQL queries rather than making the SQL emulate a dayfile! But it raised a question... Are the seasonal figures correct?

Shouldn't 1st December 2018 be the start of Winter 2018, not 2019?
Winter 2018 being Dec 2018 -> Feb 2019.

If so all the Decembers in the seasonal table are associated with the wrong year? Indeed the whole winters are!

[PaulMy]

Good point Mark,
For winter 2019 season temperature could be fine from December through February 2019-2020. However, from a snowfall perspective winter season 2019 December-2020 February would miss out November snow fall and also the occasional October and also March and April BUT then snowfall is not data that is included the the script... http://www.komokaweather.com/weather/be ... maryCU.php and click to Seasonal

This is likely not official: http://www.calendarpedia.com/when-is/winter.html

For other script examples:
http://www.komokaweather.com/komokaweat ... freeze.php
http://www.komokaweather.com/komokaweat ... detail.php and click on Seasonal summary
http://www.komokaweather.com/komokaweat ... windex.php

Enjoy,
Paul

[beteljuice]

Shouldn't 1st December 2018 be the start of Winter 2018, not 2019?
Winter 2018 being Dec 2018 -> Feb 2019.

If so all the Decembers in the seasonal table are associated with the wrong year? Indeed the whole winters are!

http://www.calendarpedia.com/when-is/winter.html

B*GGER

I really don't think I'm upto a rewrite at the moment - silly it's taken so long to be picked up ...

[drat]

Hi,

Just wanted to say "thank you" to Beteljuice, Mark and any others who developed this script. It's really helped me to find and fix some pretty severe errors in my dayfile. Thanks again!

Paul


http://weather.pmhahn.com

[beteljuice]

Dear all ...

As you can see from the previous posts the seasonal page has been WRONG for the last five years !

Actually the Dec / Jan / Feb data was correct, just technically associated with the wrong year
In other words eg. (Northern) Winter 2018 was really Winter 2017

This will mean a change to the layout to help with readability / logic, but may initially be confusing because the 'year' starts with March.

To see what this means compare WRONG against CORRECT

Perhaps I should make (header) Jan, Feb colour red or blue rather than light gray ? (Let me know)

So as I've got to do a new release I'll change the 'year' rainfall and evt Month 'daily' averages to totals, with the overall (totals) month averages at the bottom LIKE THIS

Anybody unhappy with the changes - let me know ASAP

the beteljuice

[PaulMy]

The testers

Looking good on that LIKE THIS link.

Enjoy,
Paul

[beteljuice]

Dear Enjoy Paul ..

The Users

Your Jan 1st EVT figure is actually a large negative value (discussed elsewhere) and is screwing up the averages / totals

[PaulMy]

Hopefully fixed.

Enjoy,
Paul

[Mapantz]

Incredible - That's the sort of thing even I would pick up on...

Despite the problem, it's nice to see older scripts being worked on with minor adjustments etc.

[billy]

That would only make the year average figures more inaccurate.

They are actual averages ie. over the number of days where records exist rather than days in month.

Thanks for pointing that out - mine doesn't do that so I have introduced a glitch somewhere
When using monthly totals in the yearly summary table (rather than daily averages), I guess a monthly value with some missing days could be weighted by the proportion of days missing.

I modified my code to display running averages in the monthly summary table. It turned out to be quite simple to implement - once I understood the code a little better. I am happy to post the few steps involved but suspect I am the only person who is interested in this. The cell colouring needs tidying up, which I will do if my understanding of the code gets to the next level

Annotation 2019-07-29 095945.png