Template talk:Weather box

Update

Just to be clear, Im not proposing any action on either point here .... Im not going to do anything myself, because ...it's a volunteer project, the weatherbox template is a whole lot of work already, and these issues havent been big issues before. But nonetheless:

1) the 1991-2020 climate data was released almost immediately after the beginning of the new year, to the surprise of many who were expecting a months-long delay. In theory we could start replacing 1981-2010 climate data with 1991-2020 climate data. I certainly wont stop anyone who wants to, but as above, we got along just fine with slightly older data throughout the entire last decade, and climate doesnt really change that much even with global warming ramping up, so I'm just dropping this here as a reminder.

2) The notorious WeatherBase has been down for a few days now, and there's a possibility it won't come back. If it does come back, there's a good possibility that they're just revamping the site and it will come back with a UI that is great for casual users but which breaks literally every single link we have. I certainly dont expect anyone to show up and volunteer to fix 4000 links to a site that would just as likely change its UI yet again a few years later, but again, I'm just letting you all know.

Personally, I wouldn't mind if Weatherbase never came back. They're so notorious for being wrong that I'd seriously entertained asking them to be put on the blacklist, but held back because I figured a lot of people, even longstanding Wikipedia users, would not know the difference between a reliable source of climate data and an unreliable one that happens to be right some of the time.

I put in a lot of work over the past year or so, but I've grown tired of this, and as such I have to repeat yet again that I don't expect anyone else to hop to work and start editing hundreds to thousands of climate data charts. But let me know if anyone has questions.

Best regards,

—Soap— 19:41, 18 January 2021 (UTC)

Snow depth in the Weatherbox

Hello, can anyone help me introducing "max snow depth cm" and "max snow depth inch" in these weatherbox templates so that it is editable? That is usually how snow is measured in the Nordic countries, contrasted with the totals preferred in North America, hence most Nordic locations lack snowfall data at all in the weatherboxes. I would greatly appreciate help with this. Glottran (talk) 11:10, 7 February 2021 (UTC)

Can you clarify a bit. Are you saying that Nordic countries do not separate snow and rain and just measure precipitation? Now for maximum snow depth do you mean "Extreme Snow Depth", "Extreme Daily Snowfall", "Snow Depth at Month-end" or possibly "Median Snow Depth" or "Average Snow Depth". I don't know where to search for them on a Nordic location (and possibly a European location as I see London does not separate the snow) so if you look at this and click on the "Normals Data" and scroll down you can see what I mean. CambridgeBayWeather, Uqaqtuq (talk), Huliva 10:18, 9 February 2021 (UTC)

@CambridgeBayWeather:

Yes, they just measure precipitation and snow depth. Here is a Swedish-language example. In the upper right column you will see "largest snow depth cm" (Template:Lang-sv). Meanwhile, there is nothing in there about the snowfall, just the depth and the overall precipitation. That is why I think it would be great to have these as options. As for what I desire for this box I mean "Extreme Snow Depth cm/inch" since that is usually what it measured in the Nordic countries and those averages best describe how the snow sticks around, not just how much of it falls. I would be very grateful if this was added to the possible charts with the same colour codes as snow so that Nordic locations also could get some snow data in weatherboxes.

Glottran (talk) 22:20, 9 February 2021 (UTC)

OK. Unfortunately the days when I could edit the template are long gone. It will require someone else to do it but I think it a good idea. CambridgeBayWeather, Uqaqtuq (talk), Huliva 09:34, 10 February 2021 (UTC)

References

@CambridgeBayWeather:

Is there anyone in particular you can think of who can edit the template and I can ask on their talk page whether they could assist in this task? Glottran (talk) 15:03, 10 February 2021 (UTC)

Not really. Soap above did but they got tired of it. You could look through the history of the page and see. CambridgeBayWeather, Uqaqtuq (talk), Huliva 13:02, 11 February 2021 (UTC)

@CambridgeBayWeather: I tried to edit the sandbox but it just came back as "unknown parameter" when I tried to add "max snow depth inch/cm" for the respective columns. What did I do wrong which made it not work as far as you know? I'd like to be able to fix it myself, but the site throws me serious hurdles by the looks of it! Glottran (talk) 13:53, 14 February 2021 (UTC)

You can't edit it here any longer. It has to be edited at Module:Weather box. You could ask Johnuniq, Huntster, Hike395 or Jonesey95. CambridgeBayWeather, Uqaqtuq (talk), Huliva 10:38, 15 February 2021 (UTC)

Glottran, would the year end figure be a sum or average of the monthly figures? I can try to make this work, but module code makes my head spin, lol. — Huntster (t @ c) 15:36, 15 February 2021 (UTC)

Huntster, the default would be the highest monthly tally. In effect, if February has 67 cm and no other month surpasses it: then it's 67 cm for the whole year. Then obviously as with avg record high/low the annual tally can be higher than this because different months may record higher snow depths in various years. For example, if January or March have deeper snow covers in two years of a series when it usually is February: the average snow depth in a year will increase somewhat. Either way, think of it as a record high column. I really hope it can be made to work out and cheers for making the effort. Good luck!Glottran (talk) 16:37, 15 February 2021 (UTC)

Glottran, so the basic code is now in the sandbox as seen below, but I honestly cannot figure out why the colours are responding the way they are. Johnuniq, would you mind terribly looking at what I did wrong? Note that I did intentionally use the humidity colour scheme as a test rather than make something entirely new, since they have a somewhat similar number range, but the way it is displaying below makes no sense to me. — Huntster (t @ c) 19:35, 15 February 2021 (UTC)

Climate data for Test
Month	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec	Year
Average extreme snow depth cm (inches)	0 (0)	10 (3.9)	20 (7.9)	30 (12)	40 (16)	50 (20)	60 (24)	70 (28)	80 (31)	90 (35)	100 (39)	110 (43)	110 (43)
Source: Test as of 2021-02-16 13:37Z

It seems that it's multiplying the measurements by ten. Or maybe we're dividing the humidity measurements by ten and we just didn't notice. I played around with previews, and it seems that e.g. 5 cm is equivalent to a humidity measurement of 50%, 10cm is equivalent to 100%, 14cm is equivalent to 140% humidity, and so on .... and yes, our humidity scale runs up to 140%.... perhaps we decided we just didnt want to have the darkest blues surface in real-world measurements so we intentionally undershot the limit when we set it up. That'd be my guess, anyway .... lurking somewhere in the code is a multiplier that just isn't in the place where we're looking for it, and if we can find it, we can get it to work properly for the snow depth too. or, just change "scale factor" maybe. —Soap— 19:49, 15 February 2021 (UTC)

Huntster, Soap Wouldn't it be possible to use the exact measurement scales for the snowfall proper? Considering it is "same, same, but different" in that a frozen climate receiving x amounts of snowfall will likely have a similar snow depth, at least for the first few weeks. It might be hard to fix but definitely a possible solution from my point of view. Glottran (talk) 21:19, 15 February 2021 (UTC)

Oh, yes, I imagine that copying and customising the regular snowfall colours would work better. I just have no idea how to change the colour scaling to work with this depth range (which, btw, is a good question: what would be considered an appropriate upper bounds?). The above mockup just uses humidity as a placeholder since I thought it would use a similar scale. Perhaps I over-emphasised the humidity-as-colour issue, that wasn't my intent. — Huntster (t @ c) 21:29, 15 February 2021 (UTC)

Huntster it definitely needs to be a bit higher than the current colours for sure. Right now my location has about 20 cm of snow on the ground and it is by no means extreme. Shouldn't it be possible to basically just copy and paste the snow codes without changing anything? Life is rarely that simple though... Glottran (talk) 21:53, 15 February 2021 (UTC)

This is now with snow. Slightly better, but still no dice. — Huntster (t @ c) 00:13, 16 February 2021 (UTC)

It looks like it's lined up with the way the snow normally behaves .... e.g. at Sapporo#Climate you can see the same colors for the same values .... but the way it was earlier suggests we can scale it down without changing the values. Would the scale_factor variable work for us here? Maybe to half or a quarter of what the numbers would normally merit? —Soap— 00:18, 16 February 2021 (UTC)

Soap, you're so smart. Set scale to 0.4, and you can see result above. Glottran, what would you suggest would be the most realistic maximum value the colour should account for? — Huntster (t @ c) 00:33, 16 February 2021 (UTC)

Is the sandbox now working as wanted? I'll have a look but my initial check has hit a wall due to #Proposal: make "single line" default above. As noted there, I made a lot of changes for that and I would want to know if it is wanted and what I should do about those changes. Johnuniq (talk) 03:00, 16 February 2021 (UTC)

Johnuniq, I fully intended to revert to your last version of the sandbox once this particular change was finished. As for 'single line', I honestly don't know anything about the issue, but it seems logical for the vast majority use case to be the default behaviour? — Huntster (t @ c) 03:23, 16 February 2021 (UTC)

@Huntster: Are the above results (produced by {{Weather box/sandbox}}) correct? That is, is anything further wanted? I'm lost wondering about side issues, for example "multiplying the measurements by ten" above. The module multiplies by ten to get the color for a cm value (but does not multiply by ten for a mm value). Actually, I would need to study the code more to be confident about what I'm saying due to long-time-no-see, but the factor of ten is related to cm/mm. That got me wondering what happens if some values are cm and some are mm—a quick test shows the result is very confused, groan. If snow depth is working as wanted, I would like to take a couple of days to remind myself whether the single-line issue was finished and if the code looks good. In that case, we could release both the new snow depth and default-single-line at the same time. Do people want the default to be single line? Johnuniq (talk) 04:26, 16 February 2021 (UTC)

Johnuniq, I'm just waiting for feedback to see what the upper bounds should realistically be so I can tweak the scale appropriately. The "multiplying measurements" thing came from a misunderstanding that I was wanting to actually use the humidity colours for the final product, when that was just a placeholder. I'm satisfied that snow gets us where we want, I just need to dial in the colour values now. If you wanted to merge in the snow depth code with your previous version of the sandbox, that's a-okay by me. Single-line default has my !vote, for what it's worth. — Huntster (t @ c) 04:46, 16 February 2021 (UTC)

Huntster In March 2020, Katterjåkk in Riksgränsen, Swedish Lapland had a snow depth of 229 cm. As far as I understand it though it is just going to be the darkest shade from a certain point and that is what the question is about? If so, I'd suggest 100 cm. If the question instead is for how much snow depth is possible as a max value in the weatherbox proper, I'd go with 400-500 cm to account for some variability from the 229 cm Katterjåkk measurement. Hopefully I've sufficiently answered the question and I'm very grateful for your efforts! Glottran (talk) 07:43, 16 February 2021 (UTC)

References

Glottran, I was thinking more about what average numbers might be, rather than absolute maximums. I fear if we used 200, then there would be hardly any colour variability in most typical scenarios. Hmm.

Addendum, above test is with a scale of 0.2. I think it looks pretty reasonable. Thoughts? — Huntster (t @ c) 14:13, 16 February 2021 (UTC)

Huntster I do understand your point. I really like the example you have made above and am fine with it though. We can go with a number beneath 200 it is fine by me, considering those locations are fundamentally outliers. For example, here we have -2°C means in winter and I'd say the peak snow cover is about 20 cm on average so the scale above may well be appropriate for most locations so it has my seal of approval. Glottran (talk) 17:10, 16 February 2021 (UTC)

Johnuniq, I suppose that answers the question :) We're ready to deploy whenever you are. Thank you Glottran. — Huntster (t @ c) 23:41, 16 February 2021 (UTC)

@Huntster: Please go ahead and deploy your code now (don't wait for me). There are "only" 20,000 transclusions of weather_box so there is no strong reason to wait. I found my notes from June 2020 and the situation is a bit of a mess. I think my changes are good but then I started investigating what articles actually contain and what the effect of a change would be. That is pretty unclear and I'll take more time thinking about it. FWIW I looked at your changes and they seem good! Johnuniq (talk) 03:06, 17 February 2021 (UTC)

 Done Changes deployed, sandbox reset. Thanks everyone! :) — Huntster (t @ c) 16:18, 17 February 2021 (UTC)

@Huntster: Massive thank you for your efforts! I can't find any star among symbols, but otherwise you'd gotten five of them! One crucial thing though: could you please do me a favour and maybe change the weatherbox title from the current one to "Average extreme snow depth"? This is because just as it is worded right now is a bit too ambigious. Might be an idea to keep it ambigious on purpose, but the reader might misunderstand it... also the text could easily be a bit too long if we change it so might be best to keep it as it is? Glottran (talk) 17:25, 17 February 2021 (UTC)

 Done, Glottran. It's a little on the long side, but not unreasonably so. The words will wrap if needed, so no problem. — Huntster (t @ c) 19:19, 17 February 2021 (UTC)

Huntster, thanks again! I think "extreme" could in theory be "peak" also since we're talking about how high it gets, which would save three letters but granted that's not much. In the end it's basically less than one word shorter than the afternoon humidity text for example so it's not all that bad. Once again, great job and much appreciated! Glottran (talk) 21:49, 17 February 2021 (UTC)

Template-protected edit request on 12 April 2021

Please apply the following changes to the module diff. These changes make sure that the latest version of collapsible content is used and the JS is loaded automatically, instead of asynchronously after page load, which is more efficient. —TheDJ (talk • contribs) 12:57, 12 April 2021 (UTC)

To editor TheDJ:  done, and thank you very much! P.I. Ellsworth  ed. ^put'r there 18:49, 12 April 2021 (UTC)

Check/update documentation

I updated the template documentation. I changed the first example to use default settings, the |collapsed=yes and |open=yes settings are confusing if not contrary. I added a second example to demonstrate two of the most dramatic parameters. I updated the documentation about |width=. My guess is there are other updates needed. I do not have the knowledge or inclination to do them. PS: I think |width=auto should be the default simply to make a weather box more like wikitable. User-duck (talk) 12:57, 20 May 2021 (UTC)

Edit request: Sorting of rows

Currently metric and imperial units are clubbed together. That causes confusion, esp with colour coding. So respective rows of imperial and metric can be clubbed. That will make colours match of adjacent rows, and will look similar to "single line = Yes" parameter, but without brackets and with separate rows. Currently in Attigundi article, the order is high C, low C, rainfall mm and then high F, low F and rainfall inches. Instead this order will become high C, high F, low C, low F, rainfall mm, rainfall inches after the edit (Compared to single line version). That will make colours of adjacent rows match, and will become easy to read too. Crashed greek (talk) 07:44, 25 August 2021 (UTC)

Colours will match like it is already there in "Average dew point °F" and "Average dew point °C" rows of the existing template. Crashed greek (talk) 07:50, 25 August 2021 (UTC)

I disabled the edit request because it is only for use with precise instructions regarding exactly what changes are required, and should only be used after a discussion has established that the change has consensus. The current design is that you can either have imperial/metric units together in the one row, or you can have all imperial units in one section and all metric units in another. The proposal is that imperial and metric rows are interleaved. I haven't seen that idea before. Let's see if it has any support. Johnuniq (talk) 09:38, 25 August 2021 (UTC)

Could you explain how the current setup is confusing? —Soap— 19:47, 25 August 2021 (UTC)

Crashed greek I removed the hidden comment bit. But I see no point having separate lines for C and F. CambridgeBayWeather, Uqaqtuq (talk), Huliva 00:05, 28 August 2021 (UTC)

I didn't get what you removed. Colours get jumbled up and and look confusing if the rows are clubbed for data unit instead of data type. Crashed greek (talk) 04:52, 30 August 2021 (UTC)

Some variables that might be missing

Just writing this because I believe that the Weather Box is lacking some important variables. All of these values are used both by the Portuguese and the Spanish Meteorological Institutes. I do not know for certain if other Meteorological Agencies use them, if they don't then I guess it wouldn't make much sense to use them in the first place.

• Record daily precipitation: Very important when distinguishing torrential from continuous rain. A great indicator of flash flood intensity/occurrence. Ex: Phoenix, Arizona has a higher daily precipitation record than a lot of other places in Europe which have 4x the annual average precipitation of Phoenix.

• Wind speed: This might not be as much as important as it depends largely on the placement of the station (agricultural field vs city centre), but I find it rather important for apparent temperature (similarly to humidity). It also takes out space if one decides to make a table just for wind speed. And might I add highest wind speed (wind gust record)

• Days of thunderstorm: May be related to record daily precipitation but nevertheless useful. Ex: While the Mediterranean bordering Barcelona has around 20 days per year of thunderstorms (with most of them occurring in the summertime), Lisbon, bordering the Atlantic, has only 8 (with most of them occurring in the wintertime)

Other variables IPMA and AEMET use include:

• Foggy days: Places located next to cool water masses tend to have a higher occurrence of fogs. (Look up San Francisco fog)

• Days of frost

• Days of graupel

Interested in hearing your thoughts on what is essential and what is not. Average Portuguese Joe (talk) 19:27, 11 September 2021 (UTC)

Alright this is going to sound more negative than I intend it to .... please understand that I'm just in a bit of a rush but I would rather say something, even if it comes off a bit rough-sounding, rather than saying nothing at all.

Wind speed tends not to vary a whole lot month to month, and as you said, it also varies a lot from place to place even within a very small area. We have it on Cabo da Roca because that is a place known for its exceptionally high wind speeds, but even there it doesn't change much from one month to the next. I think it's best to keep it as a separate table; it may also help us, if we can find stations that record it, to add the mean wind direction to the table.

Record daily precipitation and record wind gust are great ideas, but I still wouldnt put them into the weather box as they are not month-to-month variables, so there would be no clear place to put them.

Days of thunderstorm is another variable that wouldnt really fit in the weatherbox, unless there are stations that track that month-to-month .... in the US I've only seen it as a yearly variable.

Days of fog .... I dont know ... how do we define that? Is it fog at any time of the day, or fog that lasts through noon, or fog that lasts the entire day? I would want to make sure we are all graphing the same thing before we add that.

Frost is tracked in the USA inasmuch as we can say that's equivalent to days below 32°F .... we could add that, I suppose. I wonder if graupel is simply more common in Europe than anywhere else and that's why you track it but the USA does not.

Thanks for your input, and again Im sorry I just basically say "no, no, no, no, maybe, no" ... I'm not the one doing the coding, so I'm not going to stand up and get in your way if we as a community decide to implement your ideas. —Soap— 20:19, 11 September 2021 (UTC)

I do get your point. And you might just have changed some of my initial thoughts. I was still rooting for "thunderstorm days"; though, on further analysis, I am not 100% secure if this variable is trustable. Some of these values change a lot even through different stations of a city (2 stations in Porto differ from 4.2 days to 18.7 days in 6 km (3.7 mi)...), even if correct it can't really define the whole city. On another note: "Days of fog", as it is labelled, is most probably "Entire days with fog" which is much different than what I initially thought. Well, thank you for your response and your time, much appreciated. Average Portuguese Joe (talk) 22:11, 11 September 2021 (UTC)

Desert Research Institute

As the Desert Research Institute changes its website around, it's possible that thousands of links we have to their site in our climate boxes will irreparably break. Ive seen their new website, and as it stands right now, I am, to put it quite generously, not impressed. I'll let others who are interested take it upon themselves to see what got me upset, rather than drag it out here, but it's important because if their website remains the way it is at present it will simply not be possible for us to use them as a resource in the future, and the existing links will be forever broken. —Soap— 23:01, 26 October 2021 (UTC)

"Average" temperature rows description tooltips?

It would be nice if the averages would state that they are in fact averages of the corresponding daily temperatures on mouseover to resolve possible confusion w/o shifting the data columns. L29Ah (talk) 20:26, 8 November 2021 (UTC)

Template-protected edit request on 4 December 2021

Recommended change: "Mean monthly sunshine hours" to "Mean sunshine hours". Reason: In this example and in the sampling of transcluding articles I looked at, the data being given are, for the months, the monthly mean totals and, for the year, the annual mean total. This usage (monthly for months, annual for the year) is comparable to the usage of entries such as "Average snowfall" and "Average rainy days", and those entries lack the erroneous "monthly" in their titles. Largoplazo (talk) 23:40, 4 December 2021 (UTC)

Something like this needs discussion before an edit request. I have done some technical work implementing this template but have no opinion on whether this change would be desirable. I think we should allow a few days to pass for those who understand the topic to comment. Johnuniq (talk) 00:05, 5 December 2021 (UTC)

My concern would be the potential confusion this may cause. Countries either report sunshine hours as the total amounts of hours in a typical month which is the one the World Meteorological Organization prefers per https://library.wmo.int/doc_num.php?explnum_id=4166 (e.g. 230 hrs of sunshine in July) or a daily average (e.g. 7.8 hr of sunshine/day in July). Having the monthly ensures clarity that the data is being to referred as the total amount of hours of sunshine in a typical month (mean monthly sunshine hours, which is the official definition by WMO per https://library.wmo.int/doc_num.php?explnum_id=4166) and not erroneousely the daily sunshine hours. For example, the Austrlian Bureau of Meteorology uses "Mean daily sunshine hours" to indicate to readers that it is a daily average, not a total amount in a month so that editors don't erroneouely input daily amounts in the monthly field and vice versa. Ssbbplayer (talk) 02:09, 2 January 2022 (UTC)

Removing "monthly" is not the right way of going about this - how would you distinguish between the monthly and daily numbers? We should probably either change the behaviour of the Year column to show the average of all the months like it is for the "Mean daily sunshine hours" row or add some sort of tooltip/note with underline on the "Year" number to tell that it is the total. PS: I got here because I was looking at the Delhi article and thought that the value given for the Year column was an error and was looking for a way to fix it. -Ujwal.Xankill3r (talk) 04:27, 2 January 2022 (UTC)

Consistency of Weather Box parameters

Recently I've noticed some Weather Boxes have data that does not coincide with the actual parameter. The editor in question has been using the "mean minimum" and "mean maximum" parameters for the "record low/high MEAN DAILY TEMPERATURE recorded in the month" instead of the "average monthly absolute minimum/maximum temperature" as per definition. From what I've noticed, he did this in the Málaga and Seville articles. Still, after I warned him about it, he persists on keeping it. I mean, there should be some consistency with parameters, right? Average Portuguese Joe (talk) 00:04, 4 February 2022 (UTC)

Error with units of inches and January precipitation or rainfall of a trace

I came across an error when I tried to make a weather box with |Jan precipitation inch = trace. It is a Lua error that can be traced back to Module:Weather box. The same error happens when |Jan rain inch = trace, but not for snowfall. In the rare case this happens, it can be fixed by changing the january value to |Jan precipitation mm = trace or |Jan rain mm = trace. The weather box will appear the same to the viewer and the yearly totals are unchanged. Here is a permalink to some examples in my sandbox. [1]. The lines of code in the module are

203: prefer_cm = precision(_ifset('Jan precipitation inch', '0')) < 1,

214: prefer_cm = precision(_ifset('Jan rain inch', '0')) < 1,