5,838
edits
Reports folder: Difference between revisions
m
Minor resequencing of page
m (Minor resequencing of page) |
|||
|
{{Version badge Mx}}{{Version badge 1}}This page applies to both flavours. It has been updated to cover all releases up to 3.12.0.
[[Category:Cumulus Files]][[Category:MX txt Files]]
=The Reports folder=
All flavours of Cumulus software include in their release distribution, a sub-folder called '''Reports'''. Please note that it starts with a capital letter, whilst (for Cumulus 1 and 2, all; for MX, most) other folders have totally lower case names.
When you first install Cumulus this folder is empty (for technical readers, MX releases do have one hidden file in the folder, '''.gitignore'''), it is just created in case you decide to use report functionality.
=Optional functionality=
|-
| Switch this functionality on by selecting '''NOAA Settings''' in the ''Settings'' menu.
(In image "month specification" is abbreviated to "MS")
| [[File:Cumulus_Configuration_Menu.png]]
|}
==NOAA Report Settings==
The various settings are listed [[Cumulus.ini#Optional_Report_Settings|here for MX]] and [[Cumulus.ini_(Cumulus_1)#Section:_NOAA|here for the legacy software]]. You will get the maximum understanding from reading both those links.
Basically, some settings determine text to appear in the reports, and others specify thresholds used for various calculations. There is a mixture of settings that have a default, and settings that are initially blank.
There are defaults for the file names, and the next section will explain that although you can change these, such changes will stop you using any scripts provided for viewing these reports on your web site, so think about your technical skills and whether you can write your own scripts, or modify supplied scripts.
City and State are American terminology. The actual content of the first might be village, town, district, or city. The actual content of the second might be a region, area name, or county.
Looking at the other initially blank settings, most of these are for monthly figures. You decide where to get the figures from, your local meteorological service might publish climate figures based on 10-year or 30-year averages as required by World Meteorological Office, your tourist authority may have some figures for your area, or there might be another weather station not far away that you can ask.
= NOAA style Report Naming =
|}
=A brief history of these reports =▼
The reports were first added to Cumulus 2 after someone asked, in enhancement request 44 (the enhancement register is no longer available), if Cumulus software could copy what a rival weather software package ('''Weatherlink''') did, and output some climatological reports for both Monthly and Yearly periods.▼
The idea was to present the weather data that Cumulus software processed, with analysis against various thresholds, and comparison against climate normals; these are figures based on averaging ten to thirty year past periods, i.e. periods as defined by World Meteorological Organisation (WMO).▼
Steve Loft did some investigation, and found that Ken True had implemented the Weatherlink reports in his Saratoga suite, so Steve Loft took that as his starting point (see [https://cumulus.hosiene.co.uk/viewtopic.php?f=20&t=5689 Steve's post on the Cumulus Support Forum] for more details). ▼
These Saratoga reports were based on climatological reports ([https://forecast.weather.gov/product.php?site=CRH&product=CLA&issuedby=AST annnual report] and [https://forecast.weather.gov/product.php?site=CRH&product=CLM&issuedby=AST monthly report]), issued by The US National Oceanic and Atmospheric Administration's National Weather Service (hence why Steve Loft decided to use NOAA in the naming of the reports). ▼
Steve Loft was developing Cumulus 2 at the time, so NOAA reports were implemented in that. Subsequently, Steve Loft abandoned Cumulus 2, and his NOAA report design was subsequently added to version 1.9.2 (build 1004) released in July 2011. Steve Loft did not include this report functionality in his [[Cumulus 3 (MX) beta documentation|Cumulus 3 (MX) beta]].▼
Mark Crossley added these reports to MX at release 3.1.0, using the same layout and same report naming as the legacy, but he had to reinvent the calculations.▼
▲=Daily report update=
▲In the end-of-day process, Cumulus output the monthly and yearly reports for the day that has just ended. This means when a new month, or new year, starts, the report is only available from the second day.
All reports are generated by processing data that Cumulus has already stored somewhere, see subsequent subsections as it varies by flavour.
For all flavours of Cumulus, the summary at the base of the monthly report is calculated as follows:▼
* the arithmetic average is calculated, and shown, for Mean Temp column and Wind Speed column▼
* the total is calculated, and shown, for the Rain column▼
* the highest figure in column above is found, and shown, for all columns headed High or Low▼
** the number in time columns represents the day number where the High/Low figure shown was reported▼
* There are 4 thresholds for temperature, and the number of days below or above that threshold is counted▼
* For each rain threshold, a count is made of days with rainfall above that figure▼
The average wind speed used for NOAA reports was, by a bug, based on midnight to midnight days regardless of rollover time in use, for any reports produced from when the report functionality was first added to Cumulus 1, up to 1.9.4 build 1085 only:
*From 1.9.4 build 1086, the calculation is correctly based on the rollover time being used.
▲=A brief history of these reports =
▲The reports were first added to Cumulus 2 after someone asked, in enhancement request 44 (the enhancement register is no longer available), if Cumulus software could copy what a rival weather software package ('''Weatherlink''') did, and output some climatological reports for both Monthly and Yearly periods.
▲The idea was to present the weather data that Cumulus software processed, with analysis against various thresholds, and comparison against climate normals; these are figures based on averaging ten to thirty year past periods, i.e. periods as defined by World Meteorological Organisation (WMO).
▲Steve Loft did some investigation, and found that Ken True had implemented the Weatherlink reports in his Saratoga suite, so Steve Loft took that as his starting point (see [https://cumulus.hosiene.co.uk/viewtopic.php?f=20&t=5689 Steve's post on the Cumulus Support Forum] for more details).
▲These Saratoga reports were based on climatological reports ([https://forecast.weather.gov/product.php?site=CRH&product=CLA&issuedby=AST annnual report] and [https://forecast.weather.gov/product.php?site=CRH&product=CLM&issuedby=AST monthly report]), issued by The US National Oceanic and Atmospheric Administration's National Weather Service (hence why Steve Loft decided to use NOAA in the naming of the reports).
▲Steve Loft was developing Cumulus 2 at the time, so NOAA reports were implemented in that. Subsequently, Steve Loft abandoned Cumulus 2, and his NOAA report design was subsequently added to version 1.9.2 (build 1004) released in July 2011. Steve Loft did not include this report functionality in his [[Cumulus 3 (MX) beta documentation|Cumulus 3 (MX) beta]].
▲Mark Crossley added these reports to MX at release 3.1.0, using the same layout and same report naming as the legacy, but he had to reinvent the calculations.
=Monthly report=
▲For all flavours of Cumulus, the summary at the base of the monthly report is calculated as follows:
▲* the arithmetic average is calculated, and shown, for Mean Temp column and Wind Speed column
▲* the total is calculated, and shown, for the Rain column
▲* the highest figure in column above is found, and shown, for all columns headed High or Low
▲** the number in time columns represents the day number where the High/Low figure shown was reported
▲* There are 4 thresholds for temperature, and the number of days below or above that threshold is counted
▲* For each rain threshold, a count is made of days with rainfall above that figure
=Annual Report=
=Format of reports=
All reports are pure text files.
All reports are pure text files. However, they contain more than just A to Z, 0 to 9, and punctuation. The additional symbol characters included in the report mean that it is important that the report and whatever is being used to view it are set to use the same set of character codes, the way that binary representations of characters are made depends on encoding.▼
▲
== Encoding ==
The last line shown there is critical, it indicates that the web page uses "utf-8" encoding.
You will find that all standard web templates included with MX start as shown above.
For Cumulus 1, from build 1094 up the various builds defined for final release, the above code is used.
However for earlier builds of Cumulus 1, the standard web pages start as follows:
<pre><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta content="text/html; charset=iso-8859-1" http-equiv="Content-Type" /></pre>
The last line there shows how the original web templates (designed by Beth Loft) used the ISO 8859-1 character set.
As Cumulus 1 does not contain any web page to display NOAA reports, legacy Cumulus users were forced to install third-party scripts to display the reports. Unfortunately there was potential for inconsistency between the encoding selecting for the web page that included a place to display the report, the encoding the package expected Cumulus to use, and the encoding selected in the script that found the report and read it into the web page. Thus you can find in the support forum lots of posts from people who saw unexpected characters, or other errors in the reports when they used these third-party packages, due to encoding issues.
===TECHNICAL BIT===
'''With that introduction, you can now choose whether to read the rest of this section which uses more technical terminology.'''
''Let me explain that technical term, essentially encoding refers to the character set used by any file''.
A computer uses binary, binary can only be in state 0 or state 1, so a combination of 0 and 1 states needs to be defined for every character you want to represent
What you can include in that character set depends to some extent on how many binary bits are used to be mapped to individual characters. A single computer byte has 8 bits, but some installations might use 7 bits for characters and the last bit for parity or some other controlling use.
If you use 7 bits, you have 127 combinations, enough for standard 26 letters in both capitals, and lower case, plus 10 digits (0 to 9), some punctuation, and some control characters (like new line, end of file, and so on).
If you use 8 bits, a whole byte, you have 254 combinations, and you can start coping with accented letters, with alphabets that don't have 26 letters, and even add some symbols.
You can have more than 8 bits, if you allow multiple bytes to specify a single character. However, this brings in extra complications for the encoding, as you need to define how many bytes are being used, and the order in which the bits within the multiple bytes are used, for example some encodings will work forward through bits within bytes, but backwards through the individual bytes.
Obviously, once you start using more than one byte, you can have 16, 32, 64, or even more bits to use and can include lots more characters and the bigger character sets start including lots of symbols and the biggest add smilies or emotion icons.
With any fixed number of bits available, there will be a limit to how many characters can be defined, and different organisations might select different characters to include.
This is what leads to multiple encoding standards. Is a particular arrangement of bits to be used to represent the degree symbol, to represent an envelope symbol, to represent a flow chart segment, to represent a smiling face, or do you need several currency symbols? The general problem is that unless you match the encoding used initially, any retrieval cannot know what character to display for certain combinations of bits.
This means that when you read a file you probably find the letters A to Z where you expect them, but whether you see correct case cannot be guaranteed. Some encodings put capital letters at lower binary values than lower case letters, and some put capitals at higher binary values. ▼
▲
| |||