Snow Observation Recording

[HansR]

Well, that suggestion did not raise much applause so I'll have to do with the diary as is.

@Paul: your snowfall-log.pdf report has events and T registration on a day. What is an event and what does the T stand for (Trace of snow?). In case of a Trace, does it always count to 0.1 cm

[PaulMy]

Hi Hans,
Sorry, I missed fully reading your earlier post.

So my suggestion is a modification of the snow registration database.
Would that be an idea?

It would be nice to have more fields to better show the new and accumulated snow.

Currently the CMX input is identical to the CU1 except that CMX Snow Depth allows for any number of digits past the decimal point whereas CU1 is only in whole numbers.
I read the snow as at 8:00 am every morning during the snow season, at the same time as reading the precipitation for the CoCoRaHS reporting.
For CU1 and CMX I tick Snow lying if there is actual snow on the ground, whether new or old snow.
For CU1 and CMX I tick Snow falling if there has been any new snow in the previous 24 hours, including if I know that falling snow has melted.

For CU1 Snow depth I round to a whole number - i.e. for a trace enter 0, for 0.5 cm to 1.4 cm snow on the ground enter as 1 cm, etc.
For CMX Snow depth I round to nearest tenth mm - i.e. for 0.5 cm as 0.5 cm, for 1 cm as 1 cm, etc. If there is just a trace of snow on the ground I enter 0.1 just so that it is recorded but an actual amount is not measurable.

For CU1 and CMX I use the Comments section to enter the last 24 hours new snow, and the snow water equivalent as I have that from my CoCoRaHS reading and reporting.

@Paul: your snowfall-log.pdf report has events and T registration on a day. What is an event and what does the T stand for (Trace of snow?). In case of a Trace, does it always count to 0.1 cm

CoCoRaHS uses T for reporting of trace amounts of rain and snow in the reporting period which for me is 8:00 am.
For my own snow spreadsheet I use (T)race for snow less than 0.5 cm or actual of new snow in last 24 hours at 8:00 am, and the same for snow on the ground. As I noted above, for CMX I use 0.1 cm to indicate a trace of snow. CoCoRaHS asks for snow reporting in 0.1 cm but as far as my eyes are concerned is not possible to measure that fine as the flakes are usually larger than that.

The CoCoRaHS reporting for compression of snow is periodically measured by melting a snow core and then report the depth and water equivalent. I do this on Mondays during the snow season. This is useful for agriculture and storm water management for planning of spring thaw and river flows.

Hopefully this is helpful.
http://komokaweather.com/weather/snowindex.html
https://www.cocorahs.org/Admin/MyDataEn ... eport.aspx

Enjoy,
Paul

[PaulMy]

@Hans, and I should read more carefully ...

@Paul: your snowfall-log.pdf report has events and T registration on a day. What is an event and what does the T stand for (Trace of snow?). In case of a Trace, does it always count to 0.1 cm

@Paul wrote:
CoCoRaHS uses T for reporting of trace amounts of rain and snow in the reporting period which for me is 8:00 am.
For my own snow spreadsheet I use (T)race for snow less than 0.5 cm of new snow in last 24 hours at 8:00 am, and the same for snow on the ground. As I noted above, for CMX I use 0.1 cm to indicate a trace of snow. CoCoRaHS asks for snow reporting in 0.1 cm but as far as my eyes are concerned is not possible to measure that fine as the flakes are usually larger than that.

The Number of Events is on how many days (8:00 am to next 8:00 am) there has been new snow. For 2023-2024 season = 40 events (days) of new snowfall, = 49 days of snow on the ground. 2023-2024 was second lowest in 14 seasons.

In a sign of the times, I had contacted Environment Canada on the publishing of 1991 - 2020 Climate Normals for snowfall and their reply:

Hello Paul,
Unfortunately, average snowfall amounts are not calculated for any station in the 1991-2020 climate normals.
Manita

I am on my own to publish them now!

Enjoy,
Paul

[HansR]

Thanks @Paul, I understand now clearly what you are reporting and what you might expect from an automated report.

The problem - and hence my suggestion - is that the only number I have is the SnowDepth field in the database. The ticks are not very important and the free format field is used by you in a certain way but any other might use it in another way. Therefore the comment field cannot be used for snow reporting or charting.

Having the SnowDepth as the only numeric field, the distinction between the fresh snow, melt and compression disappears. Hence my suggestion to change the tick field to number fields (with mm accuracy). I think we would actually only need two numeric fields and a change to the DateTime:

1. The timestamp requires a time. Either default 8h00 or the actual recording time. Currently it is only a date (and time is 00h00). I can make it any time needed but that is not entered by the user. If that would make everybody happy I can do that of course.
2. SnowLying containing the snow depth of snow prior to the fresh snow
3. SnowFalling containing the fresh snow of the past 24 hrs

The sum of the above would be the current SnowDepth

If @Mark does not see that as viable within a short time I will make something but that will be limited and different compared to what you are doing now. There will definitely not be a Normal calculation.

[PaulMy]

Hi Hans,
I appreciate all your efforts in this.
The original CU1 Weather Diary's purpose was to enter some notes (1024 characters), and to record whether snow was falling and/or lying on that day, along with the depth of snow. The View tab also has the Snow Index which shows the EWSI, which is calculated from the snow depth.
From Steve in 2008:

It was invented by Philip Eden, a well-known UK meteorologist who posts to the uk.sci.weather newsgroup.
See under 'Snow Index' on our Weather FAQs site:
http://www.weatherfaqs.org.uk/node/60#SnowIndex
Steve

but that site is no longer available. I don't know of anyone or any agency here who actually uses that index but it got me interested in recording snow and trying to match that index in my logging so I still enter daily snow in CU1, and then also in CMX Weather Diary.

So starting from a new page:

Having the SnowDepth as the only numeric field, the distinction between the fresh snow, melt and compression disappears. Hence my suggestion to change the tick field to number fields (with mm accuracy). I think we would actually only need two numeric fields and a change to the DateTime:
The timestamp requires a time. Either default 8h00 or the actual recording time. Currently it is only a date (and time is 00h00). I can make it any time needed but that is not entered by the user. If that would make everybody happy I can do that of course.
SnowLying containing the snow depth of snow prior to the fresh snow
SnowFalling containing the fresh snow of the past 24 hrs
The sum of the above would be the current SnowDepth

I am trying to understand this, as sum of SnowLying from the previous reading and fresh SnowFalling is not always the current SnowDepth due to melting and compression. This can be clearly seen in my snow log spreadsheet. Or are you suggesting the SnowLying is entered new each day along with the new SnowFalling to match the SnowDepth?

Enjoy,
Paul

[HansR]

I am trying to understand this, as sum of SnowLying from the previous reading and fresh SnowFalling is not always the current SnowDepth due to melting and compression. This can be clearly seen in my snow log spreadsheet. Or are you suggesting the SnowLying is entered new each day along with the new SnowFalling to match the SnowDepth?

That would be my idea yes to register the snow - if any - as SnowFalling / SnowLying pairs which would sum up to SnowDepths that would give the melt/compression implicit in the SnowLying number.

A search on Google for "EWSI Snow Index" does not bring me closer to a snow index nor does a search for Philip Eden

[freddie]

Philip Eden is well known in UK amateur weather world. His snow index is used by UK amateur weather/climate observers. Unfortunately, following his illness from about 2013 to his death in 2018, a lot of his useful internet references are no longer maintained.

If you are interested in fact finding then I would install a news reader and do some searching of the uk.sci.weather newsgroup. There are probably references to his work on the Royal Met Society website and on the Climatological Observers Link website.

[HansR]

Philip Eden is well known in UK amateur weather world. His snow index is used by UK amateur weather/climate observers. Unfortunately, following his illness from about 2013 to his death in 2018, a lot of his useful internet references are no longer maintained.

If you are interested in fact finding then I would install a news reader and do some searching of the uk.sci.weather newsgroup. There are probably references to his work on the Royal Met Society website and on the Climatological Observers Link website.

Thanks, and yes I understand, see his wiki page. As snow indexes are currently mostly used for satellite snow coverage estimation (see google) I would only be interested in a page describing his index, I can't find that easily. I don't have the time - with all due respect - to browse through a newsgroup. Links would be useful.

[freddie]

Thanks, and yes I understand, see his wiki page. As snow indexes are currently mostly used for satellite snow coverage estimation (see google) I would only be interested in a page describing his index, I can't find that easily. I don't have the time - with all due respect - to browse through a newsgroup. Links would be useful.

That's fine. Time is indeed precious.

[mcrossley]

I'm happy to consider changes to the diary. However there needs to be consensus on what fields are required, and exactly how they are used. Backwards compatibility with the current schema would be nice too - we don't want yet another "converter" if we can help it.

[PaulMy]

Mark wrote:
I'm happy to consider changes to the diary. However there needs to be consensus on what fields are required, and exactly how they are used. Backwards compatibility with the current schema would be nice too - we don't want yet another "converter" if we can help it.

OK, my thoughts...
1. Current CU1/CMX field Comments - ok as is (this is also in CoCoRaHS as Observation notes)
2. Current CU1/CMX field Snow Falling - either blank or tick but no value. I have used this to record that it was snowing in past 24-hour period. Suggesting to rename as 24-Hour New Snow and allow a number entry to 1 decimal, or T for trace-not measurable.
3. Current CU1/CMX field Snow Lying - either blank or tick but no value. I have used this to record that there was any snow lying on the ground at the time of reading. This has no value if the Snow Depth is already entered.
4. Current CU1 and CMX field Snow Depth - enter a measurement to one decimal. I have used this to enter the total snow lying on the ground at the time of reading. I have been using the value of 0.1 to indicate that there was snow lying but very minimal - i.e. a trace. OK as is but allow for a non-numeric like Trace or T. Using this can then remove item 3 "Snow Lying".
5. Current CU1 and CMX has the Weather Diary entered on a selected date but no time entered. CMX has a setting in Station > Common > Advanced Options > Snow depth hour: which I have set at 8 because I do the snow reading at 8:00 am but not sure what this actually does. Suggesting to add a reading time field.

My interest is to indicate the days that it has snowed and the amount on those days (i.e. 19 days of snowing in January and a total of 53 cm new snow), and the days that had snow lying on the ground whether from new snow or previous days snowfall and taking in account of snow melting/compressing (i.e. January had 26 days of snow lying on the ground with a sum of 193.5 cm). It would be nice to have some charts that can present this in a graph.

Hope this is helpful.

Enjoy,
Paul

[HansR]

I'm happy to consider changes to the diary. However there needs to be consensus on what fields are required, and exactly how they are used. Backwards compatibility with the current schema would be nice too - we don't want yet another "converter" if we can help it.

OK, my thoughts, continued from Paul's thought and using my prior remarks.

1. Comments OK: of no use for charting or calculations, optional field
2. Snow Falling Suggesting to rename as 24-Hour New Snow and allow a number entry to 1 decimal. OK: but no T as value, only numeric allowed. Optional field. A trace value can be indicated as 0.1
3. Snow Lying OK: agree with Paul this field can be removed.
4. Snow Depth OK. Value 0.1 indicates a Trace, other value shows the total snow lying on the ground at the time of reading. Without fresh snow added this value would also indicate melt and/or compression. This is an obligatory field.
5. For the date I suggest to add automatically the Station > Common > Advanced Options > Snow depth hour (thank you @Paul, did not know it existed) which can be set as parameter by the user. The system default is 8h00. The date is an obligatory field.
   If the reading time field (suggestion by Paul agreed) is added and left empty the time is defaulted as above (field pre-filled?). If filled in by the user, that time overrules the default.
6. For the measurements, fields Unit indication of height (cm, in...) is required after the field consistent with the unit definition by the user.

My interest is to automate reporting on the monthly snow results (season) on a daily basis (per month) with the summary as suggested by Paul.
Charting of the snow ... I have to think it over. Paul and I may need to work out the snow depth, melt, compression thing.

On backwards compatibility:
Given what we want, I think backward compatibility will be difficult. The tick fields will become value fields with decimals. They are already value fields for integers. That is different. One field disappears (Snow Lying) and one field gets modified (DateTime).

But I may be wrong:
Comment -> no changes
Snow Falling -> change from integer to float, no character entry allowed
Snow Lying -> disappears but only in the form, no need to delete from the table.
Snow Depth-> no change.
Datetime may need a conversion for the value. I am not sure what the impact for a new release would be.

Hope this helps.

[mcrossley]

Noted - on a back burner for now though.

[HansR]

Noted - on a back burner for now though.

Ok. That's life

[mcrossley]

I have converted the database and diary editor, but have a question about time.

I do not really see the value in adding the time to the entries, these are daily records, so unless you want the ability to add multiple records per day, I don't really see the value in adding the time?

Adding it complicates things, the form needs to have time added, database queries now have to explicitly exclude the time or take it into account. There is code I added to MX that explicitly resets the time on records that have come from C1 to be 00:00 because they do have the time, but it also varies with summer time. Then do you record the date/time in local with UTC offset, or UTC, or "pseudo UTC".