Template talk:Weather box

UV index

For the UV index = 0 the color couldbe blue as standard and not green. See: 1. It would provide greater variability and would not tend some boxes for the green band only. — Preceding unsigned comment added by Kubaski (talk • contribs) 18:47, 27 June 2019 (UTC)

@Kubaski: Please link to a page where the issue ("green band only") can be seen. That will help test any change.

@Huntster: You added uv index. The proposal is (I think) to change _uv_color in Module:Weather box/colors so the background color is 000080 instead of 008000 for small values. Thoughts? Johnuniq (talk) 07:35, 28 June 2019 (UTC)

Johnuniq: I don't know why this would be desirable. The concept behind the colour scheme is green for lower, safer levels, up through purple for extreme levels. The values can be adjusted, but green-yellow-orange-red(-purple) tends to be a fairly worldwide scale, whereas blue tends to be a colour associated with cold. I based the numbers and colours on our own ultraviolet index article, which was at the time based on the WHO-approved scale. (This has, actually, changed slightly, so I've adjusted to match the current WHO recommendation. See https://www.who.int/uv/publications/en/UVIGuide.pdf, supported by https://www.epa.gov/sunsafety/uv-index-scale-0.) — Huntster (t @ c) 12:10, 28 June 2019 (UTC)

That makes sense, thanks. I'm happy with green = safe. Johnuniq (talk) 23:57, 28 June 2019 (UTC)

Yellownife is a good example: 1. Each equal value is repeated twice. Blue is not always used because most use the index from 1 which comprises the average annual minimum of populated areas. Kubaski (talk) 13:33, 29 June 2019 (UTC)

Kubaski, so you want zero to be blue? I kind of understand, but again, as I wrote above, this scale is following the international standard approved by the World Health Organisation. 14:28, 29 June 2019 (UTC)

OkayKubaski (talk) 16:50, 29 June 2019 (UTC)

Record high UV index

Would be a good idea to add a record high UV index row? Similar a max/min for temperature, but just the maximum UV index value recorded. From some weather stations I have seen that the average for a month might be 6, but the maximum recorded could be up to 15.n, which is an interesting data point. Roqz (talk) 18:57, 29 August 2019 (UTC)

Bug: {{{time day}}} parameter not working

Some lines need to be changed as below:

From:

_if('time day', ' <span style="font-size:90%;" class="nowrap">(at {{{time day}}})</span>') ..

To:

_if('time day', ' <span style="font-size:90%;" class="nowrap">(at ' .. _ifset('time day', '') .. ')</span>') ..

--ted (talk) 02:04, 13 September 2019 (UTC)

@ted: Thanks! I added your fix. That bug has always been in the module, meaning that {{{time day}}} has not worked since March 2019 when the template was switched to use the module. Strange that the problem was not reported. I checked the rest of the module looking for similar cases but I think this is the only one. Johnuniq (talk) 05:17, 13 September 2019 (UTC)

Thank you :)! --ted (talk) 05:30, 13 September 2019 (UTC)

Request to add: Average Wind Speed, Wind Gust and Atmospheric Pressure

Citing one example, it is best that we add these measurements for certain locations that have wind speed as an important measurement rather than snowfall like tropical countries where tropical storms and cyclones pass through. --Exec8 (talk) 15:21, 17 November 2019 (UTC)

Can climate-table class be added to table element alongside wikitable class?

I believe the `climate-table` existing on the table for climate data or a similar template output. I have a few editor tools for importing climate data to other wikis which rely on this class to be present to distinguish it from other templates in the page. Can it be added? Jdlrobson (talk) 00:15, 11 January 2020 (UTC)

Suggestion to add sea temperatures

Many articles, like New York City, Culebra, Puerto Rico, Tromsø, and many others display average sea temperatures. Many pages have used formatting to display a Weather box-like table, while others have used normal tables or even existing weather box parameters. Adding the sea temperature to the weather box template would be useful in many places, and many free services such as seatemperature.org have data on it.CrazyBoy826 (talk) 02:46, 26 March 2020 (UTC)

I actually am not sure about this one. Buoys are usually at least slightly out to sea. I like your other ideas on this page, but by definition the sea temperature cannot be measured at the same spot the land temperatures are, so to be absolutely thoroughly accurate we need to keep them separate. —Soap— 18:52, 9 June 2020 (UTC)

Mass changes of blue/green for precipitation

I'm trying to understand the situation about the default color for precipitation. It defaults to blue, but there is a "suggestion" in the docs that green should be used. Some people have been making mass changes and reversions, apparently without discussion or consensus.

The documentation currently states:

• By default it is suggested to use for precipitation and rainfall the color green (associated with healthy vegetation) for distance from snowfall and other parameters. Enter green for |precipitation colour= and |rain colour=.

This was added in this edit of 12 November 2018: [1], and the colors changed in the template example, by user Kubaski. I don't see that there was any discussion or consensus about this, was there? There was an RFC in 2013: Template talk:Weather box/Archive 6 started by CambridgeBayWeather. I don't see that there was a consensus to change from blue to green. The last discussion I can see is in December 2013: Template talk:Weather box/Archive 7#"For precipitation/rain colour - there is no consensus".

In 2018 Kubaski went on to change the color to green in a large number of articles, as well as in customized templates like template:London weatherbox: [2]. Many of these changes were reverted, a lot by Subtropical-man, who left comments at User talk:Kubaski#Climate. There seems to have been ongoing back-and-forth edit warring in various articles and templates since then, like in the London and Moscow weatherboxes, without any talk page discussion, also by EJM00 and recently by CrazyBoy826. New custom weather box templates have been created with the precipitation color set to green, like template:Berlin weatherbox.

One example of problems that this has caused is in the Climate of Russia article. There are many generic weatherbox templates there, with the default blue color. Some custom templates were made with green, like template:Yakutsk weatherbox, while others were recently changed to green, like the Moscow one. They are mismatched with the others. When Weneedwikipedia tried in good faith to change the custom templates to match the default ones, they were slapped with a "disruptive editing" warning for not getting consensus. Others have expressed concern, like Meters. This is not a good situation...

If in fact there is a consensus or general practice to use green, shouldn't the template default to that, without editors needing to add it manually to override the current default blue? And if there is not, then shouldn't the "suggestion" be removed from the documentation, and people stop making mass optional style changes and reverts without discussion or consensus? See MOS:STYLEVAR. --IamNotU (talk) 20:53, 1 May 2020 (UTC)

The reason why people "changed" the standard precipitation from blue to green was exactly what it said on the documentation page — for distance from snow and temperature. Many people like green better because of that, while other people, like the IPs mentioned before, say "it gives me an eyesore". There should be a new discussion about the color of the template, and after the result, the template should be changed to only accept one colour to prevent further mass edits. CrazyBoy826 (talk) 20:58, 1 May 2020 (UTC)

I don't have a strong opinion about what colour should be used, but I have also noticed far too much churn on this, and I don't have all that many articles with weather boxes on my watchlist. I agree that it is odd to recommend green but have the default be blue..

Let's just settle this and move on. Incorporate green (or whatever) as the new default, or stick with blue and remove the contradictory recommendation. My preference would be to have something (anything) other than a wall of solid blue. Meters (talk) 03:27, 2 May 2020 (UTC)

Green is better than blue to avoid the solid wall of blue, but I also don't think green for snow ever makes sense. Green is a warmer color than blue, and snow of course is cold. There can also be cases where blue makes sense, probably. Some places tend to have warm rains; others tend to have cold rains, etc.

Also, there are serious issues with the gradients of the green color scales. For green precip, everything from about 100 mm to 170 mm looks almost identical, and then 170, 180, 190 etc are very visually distinct from each other. For the green scales for precip days, humidity, etc, even when the highest possible values are entered, it still appears as a very faint light green. I'm working on improved gradients to resolve this issue and I'm going to post a proposal on this talk page soon. I definitely don't think the blue option should be removed while the green scales still have this problem. CJK09 (talk) 03:57, 2 May 2020 (UTC)

The problem is that there is no consensus for standard colours. Does not exist and never existed any consensus for green. Blue almost reached consensus (in my opinion even a consensus was reached) and also automatically stays on the principle of Wikipedia:Stable version. Any massive changes of colors to green is trolling or even vandalism. Problems with user:Kubaski are onerous, and this is not one case. I think it's time to get consensus definitively and end the disputes. Subtropical-man (✉ | en-2) 12:48, 2 May 2020 (UTC)

I like having both options open, for beauty's sake. As above, if a weather box already has a lot of blue its good to highlight the rain in green. But we dont need to make it green all the time, either; green is the traditional color for rain on weather maps but most lay people probably form a closer association between water and the color blue. —Soap— 00:55, 6 May 2020 (UTC)

I agree. I think weatherboxes that don't have any snow data and have warmer temperatures (such as those found in tropical areas) can use blue for rain as the color won't interfere with the cold temps and snow color, but otherwise green is preferred in order to prevent too much blue. ɴᴋᴏɴ21 ❯❯❯ talk 06:36, 9 May 2020 (UTC)

If we keep optional both green and blue colors, is there any suggestion about the problem with inconsistency I described above with Climate of Russia for example? Within one article some custom weather boxes have one color scheme, and the others another. This has resulted in an inconsistent use throughout the article, and disagreements between people trying to edit the various custom templates to make them consistent, which then affected other articles. The Manual of Style says that where there are optional styles, either can be used as long as they are consistent within an article, and they shouldn't be arbitrarily changed back and forth (MOS:STYLEVAR). This is only a problem with these custom templates, like template:Moscow weatherbox. The generic weatherbox can be customized for each article, but the custom templates are fixed. Is there a possibility to also have optional green or blue per article for the custom templates? Otherwise having optional customizable colors in the generic template at the same time as having optional but fixed colors in custom templates that are used in multiple articles seems to make following MOS:STYLEVAR impossible. --IamNotU (talk) 18:03, 9 May 2020 (UTC)

I started using green because of things like this when presented in blue. That sort of thing is not easy to read. I made the snow green as well because rain and snow are both types of precipitation and they should be consistent. At the time of the last discussion I think I went with blue for the precipitation types but later changed my mind. Has anybody checked Wikipedia:Manual of Style/Accessibility#Color to ensure that they comply? Also anything agreed to here is just a local consensus and will require a wider input. See Wikipedia:Consensus#Levels of consensus. CambridgeBayWeather, Uqaqtuq (talk), Sunasuttuq 00:18, 13 May 2020 (UTC)

Comment I've been looking into Wikipedia:Long-term_abuse/24.68.2.110, but I notice that i'm reverting CambridgeBayWeather's old edits as often as the vandal's. I will respect whatever consensus we can come to here, including a consensus that all options are valid. My own opinion is still the same ... I think the choice of colors should be open to preference, and that the edit warring is really just the fault of one person who is now mostly under control.

But if we cant behave ourselves, and must agree on just one pattern, my preference is for green rain, blue snow. —Soap— 13:54, 29 June 2020 (UTC)

It's become clear to me that there won't be any consensus for one particular color scheme here, or in the RFC below, due to the WP:BIKESHED syndrome. I would support that "the choice of colors should be open to preference", except that's only true with the generic weatherbox. The custom templates as I've mentioned are a problem because they're fixed with one of several optional colors, and can't be changed per-article. If they could be made to be open to preference, that would solve one of the main problems that has led to some of the repeated changes. So far I haven't heard any definitive answer about whether that's possible or not. --IamNotU (talk) 15:02, 29 June 2020 (UTC)

Proposal: make "single line" default

The single line parameter is used on over 99% of transclusions. I don't see why separate-line should be the default behavior when it's almos t entirely unused. As is, it's just yet another parameter to remember in a template that already has tons of parameters. CJK09 (talk) 20:04, 13 May 2020 (UTC)

I support this. One odd behavior seems to be that it's trinary .... we can set it to Y, to N, or omit it altogether, and that produces three different results rather than two. So if we make Y the default, we either have to make a third value explicit, or just merge the two. Since few pages seem to use the third value, though, I support making Y the default as above. —Soap— 17:35, 9 June 2020 (UTC)

@Soap: Y or N or anything non-blank should be regarded as true for single line (that unexpected situation is compatible with how many templates, including the old weather box template, work). If omitted or blank, the result should be false. That is, it's binary. What makes you think it's trinary? I wrote most of the current module but that was some time ago and I've forgotten the details, but have just looked at this. Johnuniq (talk) 03:13, 10 June 2020 (UTC)

Hmm, I see what you mean about trinary. I put a test at User:Johnuniq/sandbox2 (permalink). That happens due to the way rows are selected. Needs thought. Johnuniq (talk) 04:08, 10 June 2020 (UTC)

I have put an enormous refactor of the modules in the sandbox with a couple of things on my to-do list and with a new single line default of true. My sandbox now shows consistent binary results. Testing would be good. Johnuniq (talk) 11:08, 10 June 2020 (UTC)

"Average precipitation", "Average rainfall", and "Average snowfall" are unclear

Does it mean average per day, or average over the whole month? When reading this, there are convincing arguments in my head for both.

It's per-month:

• Most of the other stats all refer to the whole month, and the table appears to explicitly refer to climate data for the month

It's per-day:

• While averages will make sense over a whole month, an average of historic totals are affected by the length of the month, so shorter months would appear to have misleadingly lower totals
• These numbers seem small

It's unclear:

• Many of these stats are maximums and minimums, so the duration of the period isn't necessarily something to push the reader either way
• There are separate stats for "Mean daily sunshine hours" and "Mean monthly sunshine hours", why not at least be explicit with these, too?

I feel pretty strongly that this needs to be clarified. I think I'd recommend just adding the word "monthly" or "daily", as appropriate, after the word "Average".

146.90.146.52 (talk) 11:52, 14 May 2020 (UTC)

It's always per month. I don't think measuring precipitation in terms of average per day would be meaningful to most people because there are few if any inhabited places where it rains every day, and even in the rainiest climates on Earth the rainfall tends to come in pulses of varying lengths, which are more clear when averaged over a longer period of time. This also helps for gardening, where again, even in rainy climates, plants are adapted to make it through a few dry days here and there but cannot make it through an entire month with no rain. —Soap— 17:28, 9 June 2020 (UTC)

More than 2 sources?

I noticed this infobox on the page for Gaborone is messed up, and I attempted to fix it by putting the third source inside the infobox (rather than dangling outside of it), but it seems like the template only supports the use of two sources. Can we modify it to support an arbitrary number of sources, or at the very least, a fixed number larger than two? Waidawut (talk) 01:46, 16 May 2020 (UTC)

It already does. Look at something like Yellowknife#Climate or Edmonton#Climate. CambridgeBayWeather, Uqaqtuq (talk), Sunasuttuq 23:04, 18 May 2020 (UTC)

Great, thank you! Waidawut (talk) 00:55, 26 May 2020 (UTC)

Template-protected edit request on 3 June 2020

Per the comment above, |single line= is used in over 99% of transclusions, so it needs to be default. It's just an unnecessary parameter to remember. CrazyBoy826 20:50, 3 June 2020 (UTC)

 Not done: please make your requested changes to the template's sandbox first; see WP:TESTCASES. – Jonesey95 (talk) 22:37, 3 June 2020 (UTC)

I might want to help here, but before I dive in, I want to make sure that if I edit Module:Weather box/sandbox, nothing happens, right? The documentation implies that even the sandbox code is somehow used on 7300 pages, versus 18000 for the live code. Is it picking up some kind of trivial usage like being merely linked to instead of being used? This may seem like a remarkably stupid question but for me to just edit the page and then make a mistake would be far more stupid. Im 99% sure it is safe but I just want to know what's going on. —Soap— 19:02, 9 June 2020 (UTC)

The documentation is shared between the live template and the sandbox. The best way to get transclusion counts is to click "What links here" in the left sidebar. Go ahead and edit the sandbox. – Jonesey95 (talk) 20:56, 9 June 2020 (UTC)

Thanks, but it seems that this is above my skill level. I have intermediate programming experience, but have never touched Lua, and I wasn't able to get the template to really do anything visibly different at all with my edits. I wish there were an even "sandboxier" place I could go to work with this but I dont know what the customs are about creating whole new templates like a hypothetical Module:WeatherBox/SoapWeatherSandbox so I could go make fifty edits if I need to just to make sure it's really right. The only alternative I have is to ask you to spoonfeed me the precise lines of code I need and that seems rude. What should I do? Thanks, —Soap— 22:11, 9 June 2020 (UTC)

The sandbox {{weather box/sandbox}} now has the changed default. See User:Johnuniq/sandbox2. I made some large changes to the modules and will need a couple of days to check it before taking it live. Please test and make sure this new default is really wanted! Johnuniq (talk) 11:15, 10 June 2020 (UTC)

Thank you. I think this is what everyone who's posted here had in mind, but certainly it wouldn't hurt to wait for more comments. If I'm reading it right, this new code might also save processing time, which is an added benefit. —Soap— 12:38, 10 June 2020 (UTC)

RfC - precipitation colour

Currently, this template has parameters that allow blue and green precipitation. This allows different choices, but it has also led to massive content disputes. In one case, a user switched between eight IP addresses to change precipitation to blue on over 50 pages. I (and some other users) propose that there should be only one color choice to prevent future content disputes. CrazyBoy826 20:57, 3 June 2020 (UTC)

• Oppose - to me, green implies warm rain and blue implies cold rain, so I think it makes sense to retain blue for locales that get lots of cold rain that aren't so cold as to suffer from the wall-of-blue effect if blue is used. When you have a widely used template that features tons of bright, attention grabbing colors, it's best to retain various options so that in any given use case the editor can choose the best options to minimize/avoid in-your-face color clash and/or giant walls of one color.
  However, if consensus forms to settle on one color option, I prefer green over blue. Although, even in that case, the green color option has a problem with the scale, where the entire range from 100mm to 160mm per month all looks identical to the human eye. The green scale would need to be fixed first to remedy this. The solution is basically to scale along HSV instead of RGB so that the changes in lightness/darkness are more in tune with perception through the human eye. −−− Cactus Jack 🌵 07:56, 5 June 2020 (UTC)

• As long as the precipitation, rain and snow are all green then fine. However, blue snow blends into the blue precipitation days. CambridgeBayWeather, Uqaqtuq (talk), Sunasuttuq 13:04, 8 June 2020 (UTC)

• Snow should never be green IMO - green implies warmth for precipitation in a way that blue doesn't. And unlike rain, snow isn't associated with plant growth (I'm sure there are some narrow exceptions, I'm not a biologist, this is a general point). Also, the green scales for humidity and precip/rain/snow days are currently broken - the former caps at the 100m/month color and the latter caps at the 31mm/month color, so only very narrow color ranges are used and especially for the latter scales everything appears very faint. −−− Cactus Jack 🌵 03:27, 19 June 2020 (UTC)

• Oppose per my comment in the section above. There definitely should be a choice. Lay users tend to think of rain as blue, not green, so they will notice that first. But rain is green on most weather maps and people, especially in colder climates, may automatically associate blue with snow and green with rain. So a city that has both should put the snow in blue and the water-equivalent precip measurements in green. Since water-equivalent is the same thing as rain in a tropical climate, this necessitates us leaving open the option for a color choice on each individual weather box. If people edit war over that, then we can handle it case by case, but I wouldnt expect someone to carry on such a battle for very long. Remember also that the weather box can be external to an article, and transcluded by template, as on Concord, New Hampshire. That way if there really is a major edit war, we can semiprotect just that particular transcluded instance of the template, and thus avoid the hassle of trying to piece out what's changed from the midst of all the other edits to an article. —Soap— 20:13, 8 June 2020 (UTC)

However, these content disputes are very hard to manage due to sockpuppetry and most boxes are not in templates. CrazyBoy826 17:19, 12 June 2020 (UTC)

• Support unless custom templates can be made to be customizable per-article. Consistency within articles is very important, as seen as a principle in many parts of the Manual of Style. But if one template is fixed green and another blue, you can't mix them in the same article. If you try to change one, then it causes a clash in some other article, and around it goes... You get WP:COLORWARs in the custom templates because someone wants a particular article to look one way, and someone else wants a different article to be the other way. See the comments about Climate of Russia above.

I don't really care what the colors are, though I would support using a different color than blue to differentiate precipitation from temperature. Green would be easiest, as there are already about 8,000 articles that use "precipitation colour=green". I wouldn't think too long about the metaphorical questions about what color people think rain or snow are, I think it's fine if they're the same color. Also having blue-orange as the air temperature range, and blue-green as the precipitation temperature range could be confusing. If a cell is saturated green, does that mean really warm rain or a lot of rain?

In any case we should be aware of the WP:BIKESHED problem, and realize that accepting (if not agreeing on) something and moving on is more important than what that something is. I've been on committees that get into this and I always ask that we just delegate it to someone with graphic design experience and accept their choice. Or flip a coin. --IamNotU (talk) 21:47, 12 June 2020 (UTC)

auto-calculating mean temperature from mean highs and lows

Was it once possible to automatically populate the mean temperature field by just entering in the mean highs and lows? Was this turned off deliberately? I notice sometimes the mean temperature of a given place is not the same as the average of its highs and lows. Technically this makes sense ... but I believe this may be another area where there is more than one standard to compare ... e.g. the United States seems to consider the definition of mean temperature to just be the average of all the highs and lows, whereas perhaps in some areas they put all of the hourly measurements together instead, giving a more refined measurement that may not match up with American notation. This is all just speculation .... it's possible that the areas in which the mean temperature isn't halfway between the highs and lows are just erroneous transcriptions. Can anyone provide more information? thanks, —Soap— 20:09, 8 June 2020 (UTC)

Yearly mean temperatures appear to be calculated from the monthly means if a yearly mean is not provided; see this test case. If you change the year mean C value to 99 and preview the template, you will see that your provided value overrides the calculated value. Is there an article where something appears to be broken? – Jonesey95 (talk) 22:12, 8 June 2020 (UTC)

Right, I know that the annual column is filled in automatically. But that's not what I want .... I want the template to calculate the average temperature row for each month without us having to manually add the values in, which is prone to user error. But now, if I don't manually enter the average temperature values in, the average temperature row disappears from the rendering of the template. I thought that there was a time when we could have the average temperatures also be calculated automatically from the highs and lows. Is this still possible, or was it ever? If it's not possible, I think it should be (re-)enabled unless we know for sure that some nations have a different definition of average temperature than others and therefore that the calculation cannot always be used.

As for articles, yes... there's plenty, e.g. Template:Portland,_Maine_weatherbox and a great many others. I made a sort of sandbox at User_talk:Soap/Climate_data_essay#Portland earlier where I confirmed that the values have to be entered manually, unless there is a binary variable that Im not aware of. —Soap— 01:39, 9 June 2020 (UTC)

I think I see what you mean. Do you have a source to cite that demonstrates the validity of averaging a monthly high and a monthly low to get a valid monthly average? I find it difficult to imagine weather data collection working like that, although I checked a few pages and their sources, and that seems to be how the math works. Hmm. – Jonesey95 (talk) 04:48, 9 June 2020 (UTC)

The phrase "average temperature" is not listed at NOAA's glossary page, which is where I would expect to find information about the US weather service. The closest they have is a definition for mean, which is

The arithmetic average of a set of data (numbers), or the middle point between its two extremes.

That quote shows that they could be just using two data points for temperature, but doesn't confirm it. That's all I've got for now ... I don't remember ever reading a precise definition of average temperature in a textbook either .... I just noticed from studying US climate statistics (an early hobby of mine) that the average temperature, if given, was always halfway in between the highs and lows. As for why it is this way, it may date back to the times when we only took two temperature readings per day, or at least a minimum of two temperature readings per day, and therefore for some stations that was the only average they were able to come up with.

Sorry, Im up early .... I found one more definition that was right in front of me: Mean Daily Temperature: The average of the highest and lowest temperatures during a 24-hour period. I would take this as confirmation that NOAA is indeed just averaging the highs and lows, though it could be potentially confusing to explain because we have "mean monthly high temperature" and "mean monthly maximum temperature" which describe two different things and have been confused before. Basically, if the average temperature for each day (by NOAA's simple definition) in a month is itself averaged over the whole month, the result will be halfway in between the monthly average high and low, because those are also averages. Does that make sense? As I said I may have a difficult time explaining this but I definitely found what I was looking for. —Soap— 13:28, 9 June 2020 (UTC)

I know nothing about the weather but mathematically it would be extremely odd to calculate "average temperature" from half of max + min. Unless temperatures only ever go up and down symmetrically, such a calculation would be totally wrong. It would suit "middle point between its two extremes" but that would be a very unusual meaning of mean, although it might be standard procedure for some weather reports where hourly readings are not available Johnuniq (talk) 23:48, 9 June 2020 (UTC)

I agree it's mathematically suspect, but for a lot of stations, that's all we've got ... sure, there are a lot of automated stations today, but looking at climate data requires including older data where often there were only a few, or even just two, observations per day, using a traditional thermometer that was physically designed to record the highest and lowest temperatures of the day. It would appear that all weather stations within the scope of the US Weather Service use this definition of mean temperature, as can be confirmed by looking at NOAA's statistics. So I think that's what we should be doing too. It would appear that most other countries also follow the American lead in this regard. That said, there are exceptions, such as Malabo#Climate, where the mean daily temperature is clearly lower than the high/low average. This may be common in tropical rainforest climates, where the temperature peaks early and then rain dominates the rest of the day, bringing cooler temperatures along with it. —Soap— 00:56, 10 June 2020 (UTC)

I support this only if it has an on/off switch - something like a parameter which, when set, triggers autocalculation of the daily means; otherwise it does not do this. This template takes up a lot of screen real estate. When I add weather box templates to location articles I try to be mindful of that, and I include different numbers of rows depending on the article and context. −−− Cactus Jack 🌵 22:24, 9 June 2020 (UTC)

I agree with you that it should be optional ... I really just want to save people the trouble of hand-typing all those numbers, both because it's unnecessary work and because it's prone to error since they have to be calculated by hand. I entered a bunch of climate tables for Alaska, Maine, and a few other places back in 2018, but I only put in the highs and lows. I had thought that at the time, the mean temperatures were automatically filled in, but I may have a bad memory here. —Soap— 00:56, 10 June 2020 (UTC)

I just want to repeat, since I seem to have a habit of taking five paragraphs to express a thought when a single sentence would do: per above, the United States weather service explicitly defines average temperature as the midpoint between the high and low temperatures for any given period, whether daily, monthly, or annual. I support enabling an option that will allow us to automatically calculate those average temperatures for US stations and for any other country known to be using such a formula. —Soap— 21:24, 24 June 2020 (UTC)

Proposal: changes to the green precipitation colour scale

The ellipses (shown 10x larger than their actual size) are the loci of the colors which are "just noticeably" different from the color at the center of the ellipse. Note that the ellipses are largest in the green part of the color space. The human eye is particularly sensitive to the color green, so it "saturates" our vision more quickly than other colors, drowning out subtle differences between similar shades of green.

The RGB color space is not perceptually uniform. Because of the particulars of human color perception, the result of this is that shades of green with a given RGB distance between them (let's call this distance X) appear far more similar to the human eye than shades of red, blue, or any other color that differ by a distance of X. Here is a demonstration of this:

Hue	Color 1	Color 2	Example text	Contrast ratio
Blue	#8888FF	#0000FF	The quick brown fox jumped over the lazy dog.	2.87
Red	#FF8888	#FF0000	The quick brown fox jumped over the lazy dog.	1.74
Green	#88FF88	#00FF00	The quick brown fox jumped over the lazy dog.	1.09

Because of this effect, the green precipitation scale in this template includes a very wide range of colors which appear basically identical to the human eye. For equally distant input values, the contrast ratios vary massively across the color scale.

Input 1	Input 2	Output 1	Output 2	Contrast ratio	Effective contrast
0	10	#FFFFFF	#F0FFF0	1.036	36
10	20	#F0FFF0	#E1FFE1	1.034	34
20	30	#E1FFE1	#D2FFD2	1.033	33
30	40	#D2FFD2	#C3FFC3	1.031	31
40	50	#C3FFC3	#B4FFB4	1.028	28
50	60	#B4FFB4	#A5FFA5	1.026	26
60	70	#A5FFA5	#96FF96	1.024	24
70	80	#96FF96	#87FF87	1.021	21
80	90	#87FF87	#78FF78	1.019	19
90	100	#78FF78	#69FF69	1.016	16
100	110	#69FF69	#5BFF5B	1.013	13
110	120	#5BFF5B	#4CFF4C	1.012	12
120	230	#4CFF4C	#3DFF3D	1.009	9
130	140	#3DFF3D	#2EFF2E	1.007	7
140	150	#2EFF2E	#1FFF1F	1.005	5
150	160	#1FFF1F	#10FF10	1.003	3
160	170	#10FF10	#01FF01	1.002	2
170	180	#01FF01	#00F100	1.127	127
180	190	#00F100	#00E200	1.143	143
190	200	#00E200	#00D300	1.151	151
200	210	#00D300	#00C500	1.148	148
210	220	#00C500	#00B600	1.168	168
220	230	#00B600	#00A700	1.178	178
230	240	#00A700	#009800	1.189	189
240	250	#009800	#008900	1.199	199
250	260	#008900	#007A00	1.21	210
260	270	#007A00	#006B00	1.219	219
270	280	#006B00	#005C00	1.226	226
280	290	#005C00	#004D00	1.228	228
290	300	#004D00	#003E00	1.221	221
300	310	#003E00	#003000	1.187	187

I've used an online tool to produce this color scale. NOTE: This scale has 621 color points and will take a few moments to generate. It may crash slower computers. A lower-resolution version of the same scale, with only 32 color points, can be viewed here. The scale has a resolution of 0.5 millimeters per 31-day month. If you imagine the scale as a zero-indexed array, the color displayed for a 31-day month with n millimeters of precipitation per month is the color at index 2n of the array.

Here are the contrast ratios across my proposed scale:

Input 1	Input 2	Output 1	Output 2	Contrast ratio	Effective contrast
0	10	#FFFFFF	#F2FFEC	1.035	35
10	20	#F2FFEC	#E4FFDA	1.034	34
20	30	#E4FFDA	#D6FDC9	1.046	46
30	40	#D6FDC9	#C9FAB9	1.05	50
40	50	#C9FAB9	#BCF7A9	1.05	50
50	60	#BCF7A9	#AEF29B	1.065	65
60	70	#AEF29B	#A2ED8D	1.062	62
70	80	#A2ED8D	#95E77F	1.073	73
80	90	#95E77F	#88E173	1.073	73
90	100	#88E173	#7CDA67	1.081	81
100	110	#7CDA67	#71D25C	1.091	91
110	120	#71D25C	#66CA52	1.093	93
120	230	#66CA52	#5BC248	1.095	95
130	140	#5BC248	#51BA3F	1.096	96
140	150	#51BA3F	#47B137	1.109	109
150	160	#47B137	#3DA82F	1.113	113
160	170	#3DA82F	#349F28	1.115	115
170	180	#349F28	#2C9622	1.117	117
180	190	#2C9622	#248D1C	1.121	121
190	200	#248D1C	#1D8417	1.123	123
200	210	#1D8417	#167B12	1.126	126
210	220	#167B12	#10730E	1.114	114
220	230	#10730E	#0A6A0B	1.13	130
230	240	#0A6A0B	#056209	1.117	117
240	250	#056209	#025A07	1.117	117
250	260	#025A07	#005206	1.117	117
260	270	#005206	#004A05	1.115	115
270	280	#004A05	#004304	1.098	98
280	290	#004304	#003C03	1.095	95
290	300	#003C03	#003602	1.078	78
300	310	#003602	#003000	1.074	74

Notes

Any thoughts? If there's enough interest I'll take a stab at coding up a sandbox version. −−− Cactus Jack 🌵 06:54, 10 June 2020 (UTC)

The only reason I can see to oppose this change is that the current brighter colors look prettier. So any argument in favor of keeping it the way it is will be based on aesthetics alone and seem extremely weak. So I guess it's up to me to make the case for it .... I like the bright colors because they draw the user's attention, and the gloomy appearance of the proposed reform negates any benefit from having the mid-range colors be more distinct. Just sharing my opinion. Thanks, —Soap— 15:00, 23 June 2020 (UTC)

I'm not sure I understand the proposal. Is it that there would be many more gradations, each using better-chosen colors? If so, we won't know how effective it is until seeing a few examples and thinking about the overhead in the module (probably ok, but would need thought). Johnuniq (talk) 23:31, 23 June 2020 (UTC)

It's more about better-chosen colors than the number of gradations. I'll look into how it's currently done and investigate the effect of different techniques on performance overhead. I've never worked with Module space before; I assume I can just fork all the module files into Module:Weather box/cjtest and subpages, and edit them there? −−− Cactus Jack 🌵 00:16, 24 June 2020 (UTC)

I think the processor load would be the same as it is now, since all we're doing is swapping a list of hex codes for another list of hex codes. Im personally against the change, but my argument is weak and I admit that it's weak .... I held off on replying here for nearly two weeks because my response is about as close to a literal WP:IDONTLIKEIT as it can be. I think I have a valid point ... things should look attractive and people, broadly considered, like bright colors .... but I'm not going to fight hard for my position here. I note that i Have a tendency to type out long paragraphs when I could use a single sentence and that my name is on the screen in about fifteen places already as it is, but ... please dont hold it against me if I post in this section some more, ... I Will try to post only if I have something I consider helpful to add. —Soap— 01:13, 24 June 2020 (UTC)

@CactusJack: Rather than make another clone of the modules, you should use the existing sandbox code. I've got some pending code in there (to make "single line" the default) but you can edit as needed. The main change will be at Module:Weather box/colors/sandbox which you would test with {{Weather box/sandbox}}. I've forgotten exactly what is needed but the colors module will need a function with a simple if...elseif... chain which determines which range the value belongs to, and returns the appropriate color code. You will find an example in the sandbox history where a color theme was added. The following shows links to each module and their status. Johnuniq (talk) 05:31, 24 June 2020 (UTC)

• Module:Weather box • Module:Weather box/sandbox • different (diff)
• Module:Weather box/row • Module:Weather box/row/sandbox • same content
• Module:Weather box/colors • Module:Weather box/colors/sandbox • different (diff)

Hmm, maybe you are saying you want to replace the existing color schemes rather than add one? You can try that in the sandbox as above. Currently, the main and sandbox modules are identical for colors and the differences in the other modules have nothing to do with colors so you can change all the color codes in the sandbox as a trial. Johnuniq (talk) 05:34, 24 June 2020 (UTC)

If this is going to happen someone else will have to code it up. I'm done editing Wikipedia until/unless the deletionist cabal no longer controls the place. −−− Cactus Jack 🌵 06:41, 1 July 2020 (UTC)