NOAA Reports

[mcrossley]

It seems Cumulus MX has always generated the NOAA reports without the latitude and longitude degrees, minutes, seconds symbols. C1 had them, and as far as I can see WeatherLink includes them.

So do I change MX to match C1 and WeatherLink or leave it as is?

[HansR]

Nice, you can correct your vote

EDIT: Actually, what do the official NOAA reports show? That seems a legitimate question. Maybe Steve intended the symbols to disappear?

[sfws]

I have voted yes, because at the moment you see a series of numbers without units, that is a bit stupid when units shown for everything else.

An alternative is to use decimal degrees to give same level of resolution, but you don't have to show a series of numbers separated by spaces; in that case you might not need the units because people might guess it was degrees, however for locales where radians or other units are preferred....

[sfws]

EDIT: Actually, what do the official NOAA reports show? That seems a legitimate question.

The US National Weather Service (NOAA is part of that) have a different design (see https://w2.weather.gov/climate/getclimate.php?wfo=riw]), but despite the name he gave to his reports, Steve never actually attempted to implement the NWS design. In this topic viewtopic.php?f=20&t=5689 he reveals he copied what Weatherlink had done to get the layout, and then modified it to something he could implement.

If you are interested....here is all I can tell you. Someone (I'm not going to search for who) asked for this feature in enhancement request 44. Steve first implemented it I think as part of his Cumulus 2 development. Subsequently, items (like these reports) were added to Cumulus 1 after 2 was abandoned. Steve was quite clear that his starting point was Ken True's implementation of the Weatherlink reports in the Saragota suite. To sum up, Weatherlink introduced the report first, and that is the style that first Ken copied and later Steve.

Maybe Steve intended the symbols to disappear?

My guess is that Steve just never got around to adding the symbols. To put it in context, if I recall correctly April 2014 was when Steve introduced the choice in Cumulus 1 of either ISO-8859-1 encoding or UTF-8, and in those early MX days he probably was unsure what encoding to set as default in MX, and that affects those extra symbols.

[HansR]

The US National Weather Service (NOAA is part of that) have a different design (see https://w2.weather.gov/climate/getclimate.php?wfo=riw]), but despite the name he gave to his reports, Steve never actually attempted to implement the NWS design. I

You could have given the link to the text based report, that's what we're talking about.

And for the rest: thanks for the info. I can imagine Steve took his own route. That NOAA site is pretty obfuscated and so are the reports.

[mcrossley]

I think these reports originally took their inspiration from the the Climatological reports (second half), annual, and monthly.

[laulau]

The Cumulus reports look like those from Weatherlink !

[PaulMy]

The Cumulus reports look like those from Weatherlink !

Yes that was Steve's intention when he added it to v.1.9.2 build 1004 in July 2011.

Enjoy,
Paul

[Buford T. Justice]

JMO, but I hate degrees, minutes, and seconds for GPS coordinates. Decimal is extremely accurate and you don't need N, S, E , and W. On my current NOAA report, it has:

Code: Select all

Lat: N 38� 37' 50"   Lon: W 089� 26' 58"

This could be something much more simple like:

Code: Select all

GPS: 38.631029, -89.449659

Definitely agree that the ° symbol needs to be there for temperature at the top of the report.

[mcrossley]

Well, I've changed MX to be the same as C1 and WeatherLink - it now has the symbols back.

[BCJKiwi]

Have a problem with MX NOAA Reports and editor

For May, there are no daily entries.

If I go to the UI
Reports
NOAA Monthly Report
and click on
(Re)Generate Report
It still does not create any records

If I load April's report and re-generate that, it loses all the records.
Also the degree symbols do not display in the UI monthly report editor

The UI Year report does show a record for May with data
I'm not sure about the numbers

NOAAYR2020.zip

File is ANSI Windows(CR/LF)

Fortunately I have C1 running at the moment and was able to pull the reports from there.
Have not changed any NOAA settings
Monthly filename format
'NOAA'MMyy'.txt'
Yearly filename format
'NOAAYR'yyyy'.txt'
No tick - Use UTF8 encoding
Tick - Auto save after daily reset
Tick - Auto FTP after auto save
FTP directory is correct. The file arrives but has no daily records as there are no daily records in MX Reports NOAAMO0520.txt.

[sfws]

I think you were wrong to post your problem in this voting topic, but as you did, I am replying here.

File is ANSI Windows(CR/LF)

As Mark Crossley has already told you, this is not the encoding that MX uses for NOAA reports when UTF-8 is not ticked. MX uses ISO-8859-1 encoding (see line 49 in https://github.com/cumulusmx/CumulusMX/ ... Reports.cs, that is different to ANSI. Yes, on Windows it does use CR LF as terminator, because Windows inserts that (as Microsoft by design hoped its files would not to be read by other operating systems), it is not a question of MX coding differently because it is Windows. You can see the line-by-line code in https://github.com/cumulusmx/CumulusMX/ ... MX/NOAA.cs.


It is very simple, as I explained before, I previously had a web page using ISO-8859-1 encoding to successfully display my NOAA reports when previously I had those in ISO-8859-1 encoding. In other words stick to same encoding for all components, I am sure that is what most people would do, keep it simple, and it works.

You however in your implementation seem determined to mix encodings without apparently actually understanding the meaning of the technical terms you quote, so it is no wonder by introducing complexity you experience difficulty. As I explained in detail before in your earlier UI topic your UI viewer uses UTF-8 encoding for the web page, but expects report to be ANSI encoding (which it can never be) and it then does 2 character replacements (replacing space and replacing degree symbol, both result in new degree symbols) that mess up the encoding. Sorry if that sounds harsh/blunt, but it is a true summary of your approach.

For May, there are no daily entries

On my implementation in the admin interface, the May NOAA report:
*has entries for each day
*has all the correct symbols

When I use my report viewer on my web server, the above is also true. As I said before, I have abandoned use, in your UI package, of the equivalent web page (because of the encoding mess you created).

If I load April's report and re-generate that, it loses all the records.
Also the degree symbols do not display in the UI monthly report editor

On my implementation in the admin interface there is no problem with April report either:
*has entries for each day
*has all the correct symbols

When I use my report viewer on my web server, the April report has all the lines, but although the degree symbol is there for temperature, the symbols introduced in 3.6.0 are not there as the April report has not been uploaded again since when it was generated by an earlier MX version (3.5.4). Simply uploading the local April file to my web server, gives me the correct symbols without needing to click regenerate. So it is now okay on my web server too.

My February report generated by Cumulus 1 does have all days and all symbols correctly shown. The March report was affected by my transition from C1 to MX. It had the full symbols, but lost them when regenerated by MX 3.4.6. Simply uploading the local March file to my web server, gives me the correct symbols without needing to click regenerate.

No tick - Use UTF8 encoding
Tick - Auto save after daily reset
Tick - Auto FTP after auto save

My settings differ only in that I have UTF8 encoding ticked, to be consistent with encoding for all my web pages and therefore the encoding used by my report viewer.

Just in case the MX admin interface did as you describe, I changed my settings to match yours, I regenerated the May report and again found for me all rows are generated correctly and I conclude your problems in the admin interface are therefore not linked with how MX works, but specific to your implementation.

[BCJKiwi]

@sfws
Instead of re-iterating your preference ( yes, preference ) of file format and somehow implying that my use of the same format I have used since the beginning in C1 (which Mark Crossley indicated IS equivalent to the C1 default ISO 8859-1), you may instead have actually read what I wrote and realised that the file format had nothing to do with the problem I faced.

Instead, recognising (with your great wealth of knowledge of all things Cumulus) that the NOAA files are generated from the dayfile, you could have suggested I might like to check my dayfile.

I had not considered the dayfile as it was not causing problems for anything else, but I belatedly realised this may be the cause of the issue and found it was.
So now everything is working again with NO change to the NOAA file format I use.

You may also consider that in another post on this topic elsewhere you found it unreasonable to expect someone to change their historical files to a new format, yet if I were to follow your preference I would have to do exactly that.

END of discussion.