Jump to content

Template talk:Weather box/Archive 9

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 5←Archive 7Archive 8Archive 9Archive 10

Sub templates

@Johnuniq:, there are quite a few sub-pages of this template that seem to be unused such as Template:Weather box/line/date, Template:Weather box/inchtometric, Template:Weather box/metrictoinch, Template:Weather box/samples, Template:Weather box/colt and Template:Weather box/colpastel (there are more). Can you please check if they are redundant now with your code changes and nominate them for deletion if they are? Thanks! --Gonnym (talk) 23:15, 8 March 2019 (UTC)

Yes, there are lots. I've got a couple of errors to fix up so it will be a while before I look at the unused pages but I'll get to it, thanks. Johnuniq (talk) 23:20, 8 March 2019 (UTC)
Here are some preliminary thoughts. I need a break from weather boxes for a while and will think about this later.
Johnuniq (talk) 06:44, 9 March 2019 (UTC)

Requested move 3 March 2019

The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review after discussing it on the closer's talk page. No further edits should be made to this section.

Moved. Going ahead with the close, because this appears in the Malformed requests section of WP:RM. Kudos to editors for your input, and Happy Publishing! (nac by page mover) Paine Ellsworth, ed.  put'r there  10:25, 8 March 2019 (UTC)

– Organization: Module and template should have the same name, and the colors module is used almost exclusively by the main module and therefore should be a subpage of it. {{3x|p}}ery (talk) 22:12, 3 March 2019 (UTC)

  • The proposal would be in line with style. I rather like simple one-word names but when I was editing the module in recent months I thought a rename would be inevitable. Johnuniq (talk) 23:15, 3 March 2019 (UTC)
    I wouldn't oppose the counter-move of Template:Weather box to Template:WeatherBox, but my convention for these requests is to follow the template name, since templates are generally better-watched and predate the modules they used. {{3x|p}}ery (talk) 23:17, 3 March 2019 (UTC)
    I'm slowly remembering what this is all about (I did a lot of work on the module two months ago). It would be more accurate to call this Module:Weather box/row because it only outputs a single row of the box. I started working on (and nearly finished) Module:Weather_box which would replace the logic of the template, but then I got distracted and never uploaded it. Johnuniq (talk) 10:13, 5 March 2019 (UTC)
  • Support the first, neutral on the second, as that module has zero documentation so I have no idea if it really meant to be used a sub-module of this or not. --Gonnym (talk) 08:42, 5 March 2019 (UTC)
  • I wonder if "weatherbox" is a term of art that should be tolerated. At any rate, there are over 210 templates with "weatherbox" in the title search, for example, Template:Delhi weatherbox. Johnuniq (talk) 09:37, 6 March 2019 (UTC)
  • @Pppery + Gonnym: Please reconsider the above in light of the fact that this module only outputs one row of a weather box. See the proposal below where I am suggesting using a new module to implement the template, and renaming this module to Weather_box/row. Can this move request be put on hold because more time is needed to evaluate whether the new module is desirable. At any rate, the move request should not proceed as the result would be misleading. Johnuniq (talk) 23:03, 7 March 2019 (UTC)
    No, this request cannot be "put on hold". Module:WeatherBox is no less misleading a name than Module:Weather box, and Module:Weather box/row cannot exist as a module name until Module:Weather box is created (per G8). To me, this move request is a minor technical correction independent of any grand schemes; if this module gets moved to Module:Weather box/row later, that's OK as there's no limit to the number of times a page can be moved. {{3x|p}}ery (talk) 23:07, 7 March 2019 (UTC)
    Moving these modules (and fixing the require statements and moving the associated pages), and then moving them again (with more fixes) would be unnecessary bureaucracy. See "Concrete proposal" below. Johnuniq (talk) 06:34, 8 March 2019 (UTC)

Proposal ready for testing

Sorry to disrupt this requested move but now that I have remembered the background I have implemented the following as a proposal for a different approach.

I'll do some more thinking and explain details if needed. The last two modules are copies and if this plan proceeds, the sandbox pages would be deleted so the originals can be moved. I wrote the new module two months ago but never got around to uploading it. It is an experiment to see if a Lua table could be used to implement the complex logic in the old template. The result works well but more testing would be needed. The old template and module have slightly different assumptions that could generate bugs. One is illustrated at User:Johnuniq/sandbox2 which shows a label with mm but values in cm. Editing that page and adding /sandbox to the template shows a consistent result. Johnuniq (talk) 09:31, 6 March 2019 (UTC)

I had the idea that it would be more efficient and understandable to parse all the arguments beginning in a month and create a table like { humidity = { January_value, February_value, ... }, ... } (or now that I think about it, { humidity = { cm = { ... }, inch = { ... } }, ... }. Then there's less concatenation of various months, stats, and units, and iteration through the arguments. But I reverted my edits because Module:Weather box/row/sandbox would have to be fairly dramatically rewritten; it would need a "frame" function that in turn calls the function that takes the above-mentioned table. — Preceding unsigned comment added by Erutuon (talk • contribs) 00:24, 6 March 2019 (UTC)
I haven't examined your edits but I agree that improvements would be possible by merging parts of the main and row modules. Johnuniq (talk) 05:38, 7 March 2019 (UTC)

Concrete proposal

There is some difficulty in getting my above proposal considered so I have implemented it. Yes, that's very bold, but please can we focus on whether the changes are desirable rather than what the rules say. I checked a dozen pages before-and-after the change and there was no difference.

Pings: Pppery + Gonnym who commented in above RM; Erutuon who edits the modules; Runningonbrains + Soap who commented in the previous section about the now-implemented trace request. Comments please. Johnuniq (talk) 06:30, 8 March 2019 (UTC)

  • I haven't really gave this a deep look, but I have no issue with this implementation. My comment in the RM above was regarding the name, which this fixes and sub-pages seem logical. Nice work. --Gonnym (talk) 08:48, 8 March 2019 (UTC)

To do

Johnuniq (talk) 06:38, 8 March 2019 (UTC)

The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page or in a move review. No further edits should be made to this section.

Post-move information

I added a sentence to the doc subpage to note the "trace" amount compatibility. – The Grid (talk) 13:22, 8 March 2019 (UTC)

Thanks. Johnuniq (talk) 01:29, 9 March 2019 (UTC)

Please delete Module:Weather box/row/sandbox per WP:G7 (author request). The above plan has been implemented and I need to move the old sandbox to the target location to preserve its history. Thanks. Johnuniq (talk) 01:29, 9 March 2019 (UTC)

 Done — xaosflux Talk 03:17, 9 March 2019 (UTC)
@Xaosflux: Thanks. Would you also please look at Special:PrefixIndex/Module:WeatherBox which shows two /doc subpages from the old module (before the above move). One page has been tagged for speedy deletion and the other should suffer the same fate. As there are no incoming links I guess they should be deleted? More cleanup, what about Special:PrefixIndex/Module talk:WeatherBox? Johnuniq (talk) 04:00, 9 March 2019 (UTC)
@Johnuniq: all done. — xaosflux Talk 12:49, 9 March 2019 (UTC)

@Johnuniq: Thank you for your work on this, and I'm sorry I forgot to get back to you (I'm not as active on Wikipedia as I once was). The changes are good. It is unfortunate as you noted that there's no way to restrict the "trace" option to only precipitation fields, but then again, there's nothing to stop users from using the template incorrectly in other ways, so I don't think it's a big deal. Thanks again! -RunningOnBrains(talk) 00:19, 12 March 2019 (UTC)

Please help

Hi folks. So I'm attempting to add a line for UV Index in the sandbox, but it's just not working. Would someone mind taking a look at Module:Weather box/sandbox (diff) and Module:Weather box/colors/sandbox (diff), and tell me what I've messed up? Lua is like an alien language to me. — Huntster (t @ c) 05:55, 12 March 2019 (UTC)

@Huntster: Do you have a test? I would like a sandbox using {{weather box/sandbox}} and some sample data. Johnuniq (talk) 07:01, 12 March 2019 (UTC)
Now I see Template:Nashville, Tennessee weatherbox/sandbox. I'll look at that soonish. Johnuniq (talk) 07:02, 12 March 2019 (UTC)

@Huntster: I fixed an oversight in Module:Weather box/colors/sandbox and the above template seems to be working well! Johnuniq (talk) 10:35, 12 March 2019 (UTC)

Johnuniq, I was so close to not being a complete idiot about this, and then *that*. Thanks bud, I appreciate it greatly! If you see no other issues, I'll push to live later and get the docs updated. — Huntster (t @ c) 12:32, 12 March 2019 (UTC)

I checked the three sandbox modules and they are ready to be copied to the main modules except /sandbox has to be removed from the first two. I'm a bit nervous about the trick which inserts a space before the weather box because that will break any articles where {{weather box}} does not start on a new line. However, the current situation (see #Spacing just above) is not satisfactory because Scribunto cleverly inserts an extra newline before the weather box, so we may as well go with it. Links to the modules follow.

Johnuniq (talk) 03:03, 13 March 2019 (UTC)

I'm only going to copy over the edits directly pertaining to my effort, and leave the spacing issue to folks more knowledgeable. I wouldn't be comfortable making things I truly don't understand live. Thanks again, John. — Huntster (t @ c) 04:04, 13 March 2019 (UTC)
See Module:Weather box/sandbox comparison and Module:Weather box/colors/sandbox comparison for what material remains uncommitted. — Huntster (t @ c) 04:25, 13 March 2019 (UTC)
Thanks. I updated the main module with the other minor changes (including Erutuon's #Spacing fix) from the sandbox. It's best if the edits to the module are done within a short period to reduce the number of cache flushes that occur, so I did not wait before editing. Johnuniq (talk) 06:01, 13 March 2019 (UTC)

Spacing

I've noticed that the recent switch to the Lua module has left a rather large line break/space before the template in articles. Can this be fixed? SounderBruce 19:11, 11 March 2019 (UTC)

Example articles where this problem can be observed? I clicked on a few random ones, and Amsterdam#Climate looks OK, while Athens#Environment looks like it might have some extra white space. The latter has two line breaks before the template, however; I suspect it looked the same with the old version. – Jonesey95 (talk) 19:51, 11 March 2019 (UTC)
@Jonesey95: I've noticed it at Darrington, Washington and Arlington, Washington in particular, the latter of which was written well before the conversion. SounderBruce 21:00, 11 March 2019 (UTC)
That is strange. I did some before-and-after checks when switching to the new module and I'm sure I would have noticed a change to the spacing because I switch between two adjacent tabs in my browser, one showing the old page, and the other showing the page after purging when the new module was implemented. However, something is inserting an extra blank line as shown by an experiment at my sandbox (permalink). I can't see how {{Weather box}} or Module:Weather box could be responsible for that. I'll think about it some more but I think I'll have to ask for help at WP:VPT. Johnuniq (talk) 22:48, 11 March 2019 (UTC)
When I place {{weather box}} directly after a word without any intervening newline, it inserts a newline. It doesn't look like the table begins with a newline in the module, so probably a newline is being inserted sometime after the function returns, maybe in the Scribunto extension. If I recall right, I found out that a newline is inserted when a module returns a string that begins with list markers (:, ;, #, *), so maybe a newline is also inserted before syntax that could be introducing a table ({|). — Eru·tuon 23:05, 11 March 2019 (UTC)
Thanks, I'm sure that is the answer (although I don't know why I didn't notice the change). Lots of modules generate tables so someone must have noticed this. I will as at VPT later if someone doesn't beat me there. Johnuniq (talk) 23:14, 11 March 2019 (UTC)

In the sandbox, I tried inserting a space before the table. I thought that might break the wikitext but it seems to work providing the line before the table ends with a newline. A demonstration using {{Weather box/sandbox}} follows. This wikitext has a newline but no blank line following.

Climate data for Darrington, Washington
Month Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Year
Average precipitation days 17 14 16 13 12 11 6 7 9 13 16 17 151
Source: Later

The result is an ugly mess if the line before the weather box does not end with a newline. Johnuniq (talk) 03:11, 12 March 2019 (UTC)

I recall working on Module:Navbox and I don't think there were any problems like this. I just looked at the module and the reason there are no problems is that it outputs HTML, not a Wikitext table. That is a possible solution. Groan. Johnuniq (talk) 04:25, 12 March 2019 (UTC)
I think enclosing the table in a div tag (otherwise pointless) would both prevent a newline from being added and ensure that the table syntax is interpreted correctly: "<div>\n{|\n...\n|}\n</div>". But it's sort of a hack. — Eru·tuon 03:29, 13 March 2019 (UTC)
Thanks, I tried that and it works. I put it in the sandbox which Huntster is going to use to update the main module soon. Johnuniq (talk) 04:16, 13 March 2019 (UTC)
The extra space is due to a parser bug (see T18700). Another workaround is to add a <nowiki/> statement before the invoke statement in the template (e.g. see {{automatic taxobox}} template).   Jts1882 | talk  08:43, 2 April 2019 (UTC)
Thanks, that's a better solution although the cleanest might be to change the module to output an HTML table rather than wikitext. Later... Johnuniq (talk) 09:09, 2 April 2019 (UTC)

Average (means) being represented differently per metric?

I noticed that a feature of the weather box template is to automatically calculate averages based on the monthly data fed into the template. However, the average is not being consistently applied with the row heading.

For example, in Copiapó we see that the average (mean) high is reflected accordingly, as an average temperature calculated from the 12 months of the year (data/number of data points). However, average (mean) sun is not - it calculates the sum total sun instead of the average of the months, generating a result of 2,920.5 instead of 243.375 (using the simple average of sum / count). Another example would be in the mean daily sunshine - the mean calculated is an average, not a sum. To play devil's advocate, the sum total of averages is also represented in precipitation.

Would it be appropriate to add a label indicating that this is a sum total of averages, or to refactor the calculation in the template to perform an average instead of a sum? I appreciate the fact that it represents a yearly average, but I feel it could be better positioned within the template to clearly delineate the fact that it represents a yearly, not monthly, average.

137.150.38.230 (talk) 22:44, 17 April 2019 (UTC)

That does look odd. It might be considered helpful because the Year column shows the "total" number of sunshine hours (where total means the sum of the monthly averages). I'm not sure what should be done. It's easy to change it to average. If anyone wants to contemplate other cases, I extracted the following from the module to show the comment used, an abbreviated label, and the method used to calculate the Year value.
First-second line avg monthly maximum temperatures  Mean maximum °C (°F)                                                max
Second line maximum humidex                         [[Humidex]]                                                         max
Second line record high temperatures                Record high °F                                                      max

First-second line avg monthly minimum temperatures  Mean minimum °C (°F)                                                min
First line record low temperatures                  Record low °C (°F)                                                  min
First line minimum wind chill                       Record low [[wind chill]]                                           min
Second line record low temperatures                 Record low °F                                                       min
Second line minimum wind chill                      [[Wind chill]]                                                      min

First line average high temperatures                Average high °C (°F)                                                avg
First line daily mean temperatures                  Daily mean °C (°F)                                                  avg
First line average low temperatures                 Average low °C (°F)                                                 avg
Second line average high temperatures               Average high °F                                                     avg
Second line daily mean temperatures                 Daily mean °F                                                       avg
Second line average low temperatures                Average low °F                                                      avg
Percent relative humidity                           Average [[relative humidity]] (%) (at T) (daily average)            avg
Afternoon percent relative humidity                 Average afternoon [[relative humidity]] (%) (at T) (daily average)  avg
Daily sunshine hours                                Mean daily [[Sunshine duration|sunshine hours]]                     avg
Daily daylight hours                                Mean daily [[Daytime|daylight hours]]                               avg
Percent sunshine                                    Percent [[Sunshine duration|possible sunshine]]                     avg
Ultraviolet index                                   Average [[ultraviolet index]]                                       avg

First line total precipitation                      Average [[precipitation]]                                           sum
First line rainfall                                 Average rainfall                                                    sum
First line snowfall                                 Average snowfall                                                    sum
Second line total precipitation                     Average [[precipitation]]                                           sum
Second line rainfall                                Average rainfall                                                    sum
Second line snowfall                                Average snowfall                                                    sum
Precipitation days                                  Average precipitation days                                          sum
Rainy days                                          Average rainy days                                                  sum
Snowy days                                          Average snowy days                                                  sum
Monthly sunshine hours                              Mean monthly [[Sunshine duration|sunshine hours]]                   sum
Johnuniq (talk) 02:40, 18 April 2019 (UTC)

Parameter time day

I noticed that some New Zealand articles include weather boxes using the |time day = parameter. However, it seems not to work properly (i.e. check Auckland). Is there a particular format to write the time?--Carnby (talk) 23:39, 24 April 2019 (UTC)

Auckland#Climate has "|time day = 9am" which was added on 12 December 2015. The weather box template does not support specifying a time of day and I recommend removing that line. Johnuniq (talk) 00:19, 25 April 2019 (UTC)

Could snow depth be added?

For the Nordic countries, snow is measured in how deep it is, so a function for that would be highly appreciated. Is there someone good with templates who could fix that for me in some way?

Lommaren (talk) 12:31, 4 April 2019 (UTC)

I see "IMPORTANT: Do NOT use snow depth information in the snowfall area! These are 2 different kinds of data!" in the samples in the template documention so someone has thought about that. I understand the module but not the topic—is this related to "precipitation"? There would need to be an example of an article where this would be used and proposed wikitext for the input. What reliable source provides the information? @Huntster: Do you want to look at this? Johnuniq (talk) 22:28, 4 April 2019 (UTC)
The Swedish Meteorological and Hydrological Institute (SMHI) use it in their monthly and daily data for Swedish weather stations for certain stations (example in footnote).[1] Environment Canada also publishes it within monthly statistics for many stations.[2] So for example for one of those stations, let's just say Luleå. My suggestion would be: Jan snowdepth cm = Feb snowdepth cm = and so forth, with a possibility to colour it green if there is a preference for it. I would appreciate having it as a possible variable, not that it would be very frequently used since snow depth isn't measured everywhere. That being said, variables like afternoon relative humidity and humidex that are also very geographically limited in where those are measured are included in the template. Lommaren (talk) 10:30, 5 April 2019 (UTC)

References

  1. ^ "Monthly Data March 2018" (PDF).
  2. ^ "Monthly Statistics for Gander March 2018".

I would like an explanation of the significance of the "IMPORTANT" comment I mentioned above. Does the fact that snow depth was mentioned mean it has been considered and rejected in the past?

What would be displayed at Luleå#Climate? That is, what wikitext would go in the first column and where would the row appear?

Suitable color values need to be established. Following is an extract from function uv_color in Module:Weather box/colors: 

if val <= 3 then
    background = "008000"
elseif val > 3 and val < 6 then
    background = "FFCC00"
elseif val >= 6 and val < 8 then
    background = "F95900"
elseif val >= 8 and val < 11 then
    background = "D90000"
else
    background = "6C49CC"
end
if val <= 3 then
    text_color = "FFFFFF"
elseif val > 3 and val < 8 then
    text_color = "000000"
else
    text_color = "FFFFFF"
end

In the above, val is the value entered for a particular month (in this case, for the UV index such as "Jan uv=3.5"). The code determines the text_color and background color for each cell in the UV row. Value 3.5 would give text_color 000000 and background FFCC00. The equivalent for snow depth would be needed (the syntax is not important, just the values and colors). Johnuniq (talk) 01:16, 6 April 2019 (UTC)

I didn't find any discussions on "snow depth" in the archives of this talk page discussing whether it should be added. I read the comments as saying no more than "Don't confuse snowfall and snow depth because they're different!", not "snow depth should never be included", but Ssbbplayer is the one who added the comments, in this edit. — Eru·tuon 04:24, 6 April 2019 (UTC)
I am open to adding in snow depth if other users wish to do so. I agree that it is commonly measured in these countries. I did added the comment regarding not putting snow depth into the snowfall field previously since there were a large amount of climate tables (mostly in Russia) that had snow depth information erroneously added into the snowfall field even though these 2 sets of data are different. I only removed some of it only because it's wrong to put incorrect information and wanted to stress the "IMPORTANT" in the comment to ensure readers understand why snow depth should not be added into the snowfall field. Ssbbplayer (talk) 14:15, 6 April 2019 (UTC)
Thanks, I just wanted reassurance that there wasn't a consensus against snow depth in general. If someone can sort out what colors should be used I could add a "Jan snowdepth cm" row. Where should it be inserted in the table? Johnuniq (talk) 23:14, 6 April 2019 (UTC)
I would prefer the same as the rain/precipitation/snow, with navy blue being the basic and then FFFFFF text, with green background as an option. Then to make sure that the automatic default is the highest individual month, rather than adding the months together, which would of course be inaccurate since snow cover and snowfall are not the same things. Those two things being accounted for under "snowdepth cm" would be great! Lommaren (talk) 10:57, 7 April 2019 (UTC)
Thinking about it, "Jan snow depth cm" might be more grammatically correct? Lommaren (talk) 18:16, 7 April 2019 (UTC)

Following are the current parameters for January ("Jand sun" is January days sun; not a typo). 

Jan humidity
Jan afthumidity
Jan maximum humidex
Jan chill
Jan light
Jan avg record high C
Jan avg record high F
Jan avg record low C
Jan avg record low F
Jan high C
Jan high F
Jan low C
Jan low F
Jan mean C
Jan mean F
Jan record high C
Jan record high F
Jan record low C
Jan record low F
Jan precipitation days
Jan precipitation cm
Jan precipitation inch
Jan precipitation mm
Jan rain days
Jan rain cm
Jan rain inch
Jan rain mm
Jan snow days
Jan snow cm
Jan snow inch
Jan snow mm
Jan percentsun
Jan sun
Jand sun
Jan uv

It appears that "snowfall" (one word) is correct (and that is what the template uses), while "snow depth" (two words) is correct for the new option. That is a bit unfortunate because it will cause confusion but sticking with correct English usage might be best so it should be Jan snow depth cm. I'll think about the other units (mm + inch) but they will probably work with no particular effort so will be included as well.

  • Is the label Average snow depth (cm) correct? Or just "Snow depth (cm)"?
  • I suppose "automatic default is the highest individual month" means the default for the last column (Year)? The rows which use the max option have labels like "Maximum humidex" and "Record high °C (°F)". That may look a little odd with the Year actually being the maximum of the averages. Probably not a problem.

Johnuniq (talk) 05:44, 8 April 2019 (UTC)

Snow depth is usually reported at its peak level in monthly and annual reports, having said that, they could also be reported from day to day, so maybe including both would be a good idea? "Jan max snow depth cm"/"Jan max snow depth inch" and "Jan avg snow depth cm"/"Jan avg snow depth inch" even though the latter hardly will be used? The first one "max snow depth cm" is a lot more important to add either way, since that is what weather agencies report in monthly and yearly summaries. With regards to the overall value, your assumption is correct. The default value should be whichever month records the highest snow cover. I hope that makes it a bit clearer :)

Lommaren (talk) 10:04, 9 April 2019 (UTC)

Take a look at 1981 to 2010 Canadian Climate Normals station data for Cambridge Bay. This is the reference used in most Canadian articles. There are four different types of snow depth listed there. "Average Snow Depth (cm)", "Median Snow Depth (cm)", "Snow Depth at Month-end (cm)" and "Extreme Snow Depth (cm)". By the way if you scroll down a bit more there is also "Days with Snow Depth". CambridgeBayWeather, Uqaqtuq (talk), Sunasuttuq 12:28, 11 April 2019 (UTC)
Thanks but it only seems productive to add features which someone plans to use in a specific article. Everything added bloats the module and should be tested. Johnuniq (talk) 05:14, 12 April 2019 (UTC)
Sorry for a late response. I would definitely plan to be using it in some northerly and near-Atlantic Swedish articles such as Riksgränsen, Storlien and Gäddede, where snow depth is a very important aspect of the climates. I would suggest "Jan max snow depth cm"/"Jan max snow depth inch" to be the best inclusion, since that is what I would use and is easily accessible on the SMHI data charts. I would be really glad to get it done very shortly and appreciative of any help. Lommaren (talk) 11:50, 15 May 2019 (UTC)

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)

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)

"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)

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)

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)

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)
  • 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)

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)
Soap. When you say "choice of colors should be open to preference" you mean your personal preference rather than mine. That colour was stable from August 2018 until your change. I don't mind the change of the precipitation days to blue. However, you have caused the snow to blend in with the precipitation days line by making it blue as well. By the way I'm not sure that people associate snow with blue I would say they associate it with white. CambridgeBayWeather, Uqaqtuq (talk), Sunasuttuq 09:11, 2 July 2020 (UTC)
This post might be a bit babblesome, .... I just moved recently and am not quite all in place yet. I went to revert those edits in the course of investigating the vandal referenced above, and at the time, I thought the green snow edits were his, as he has been on both sides of the debate and has recently edited those pages. When I realized they were yours, I went ahead with my edits on the rationale that an edit is good or bad depending on its content, not its author.
Currently using green for precipitation days produces output barely distinct from white .... I imagine the module is coded such that it reads the days value as a precipitation measurement, and since it can never be more than 31 "millimeters", I think it is better to use blue here unless we decide to change the code of the module. We both agree that blue for precip days works well. Regarding the blending thing .... I dont think making the snow green solves that problem since it just puts green on top of green .... the snow will blend in with the rain instead of with the precip days. We could retool the module so that precip days shows up as a proper green (not near-white) but then turns blue again for days with snow. The pattern thus would be: green rain, blue snow.
I still want to emphasize though that we should have a choice for each individual use of the weather-box template, because if we go one-size-fits-all, we will have in one case or another a use case where the template colors are a poor fit. I would support your idea of green precip but blue precip-days for a tropical climate, where snow does not exist and a casual user is unlikely to mistake the blue row for a snow row. But in a climate where both rain and snow are present in large amounts, I think it makes more sense to go with green for rain and blue for snow, as is the common convention on traditional weather maps. —Soap— 13:51, 2 July 2020 (UTC)
Soap I have no intention of making precip days green. I recently got a different monitor and the green (and in some cases the blue) looks almost white. So I'm fine with blue precip days on every article. As for tropical climates I doubt that there is any in the deep south of Canada and I rarely edit places outside of the country. I still think that in places like Sachs the snow should be the same colour as the rain and precipitation. Yes it may blend a bit with them but better than blending with the precip days as snow is a type of precipitation and different from the precip days. CambridgeBayWeather, Uqaqtuq (talk), Sunasuttuq 21:14, 6 July 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 also support the idea, but I prefer with the parameter (on/off or yes/no). Subtropical-man (✉ | en-2) 14:43, 10 July 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)

Russia seems to be one nation that does not use the US definition, as looking at climate charts for places like Krasnoyarsk#Climate and others shows that the mean temperature is not just the average of the highs and lows. Some other Russian stations that do show this pattern may turn out to have been compiled by NOAA or sources that rely on NOAA. —Soap— 01:14, 10 July 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.

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:

Notes

  1. ^ (Contrast Ratio - 1) * 1,000
  2. ^ (Contrast Ratio - 1) * 1,000

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)

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)

As I wrote just above, Im getting self-conscious of just how many times my name is splattered across this page, but ... as I also wrote above, I will continue to post here if I have something useful to add, and in this case I think I do. I am pretty sure I understood Jack's proposal and, even though it isn't my favorite idea, I will help carry this through if a consensus forms in favor of the change. I believe the intent here is to change the code of the module itself to use the new color gradations, making an even swap of one list of hex codes for another, which would incur no additional processor load (as far as I know) because the code would be the same length either way. We wouldn't have two sets of colors, just one: the new one. —Soap— 15:02, 2 July 2020 (UTC)

I dont think hes coming back, guys. So that means it's up to me ... can we maybe give this a try for a month or so, and then revert it if we get negative feedback? —Soap— 22:42, 4 August 2020 (UTC)

Please do. The sudden change to white backround text even when the increase is from 199.99 mm to 200.00 mm (in a 30-day month), corresponding to a 6.666666... mm /day threshold, is quite sub-optimal. CaradhrasAiguo (leave language) 23:24, 4 August 2020 (UTC)
just to be clear, when I said "it's up to me", I wasnt volunteering to do this any time soon .... I've become lazy and I admit it. That doesnt mean I'll do nothing at all, ... I think we should try this out for a month, like I said, and if people come here asking why we did it, we'll know it might have been a bad idea. Anyway what I meant by "up to me" was just to revive the discussion. Apologies for my laziness, —Soap— 14:32, 5 August 2020 (UTC)

In fact I think I need a break from climate related editing. In the meantime I invite someone else here to take up this task and spend hours upon hours getting the template code to work just right, so I can come back and say "actually I dont like this idea anymore so ... no thanks". —Soap— 17:52, 5 August 2020 (UTC)

Retrieved from "https://en.wikipedia.org/w/index.php?title=Template_talk:Weather_box/Archive_9&oldid=1091975828"