Template talk:Medical cases chart/Archive 2
This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 | Archive 2 |
Changetype idea and UK style without new style
To calcule number of cases in % and + rise, I want to propose Alexiscoutinho to a new changetype of pa, and it rows me p only.
Like this:
And % rise like UK style:
Look at
References
- ^ "Coronavirus (COVID-19) cases in the UK (about)". coronavirus.data.gov.uk.
- ^ "Number of coronavirus (COVID-19) cases and risk in the UK". GOV.UK.
- ^ "Coronavirus: UK deaths rise by more than 100 in a day". BBC News. Retrieved 27 March 2020.
and
. 190.246.118.103 (talk) 17:58, 15 September 2020 (UTC)
- @190.246.118.103: In the past, I have been against allowing the display of two change types on one column since it looks messy and ugly. However, since the community keeps asking for and does it anyways, I think your suggestion is valid. The chart width isn't always an issue now and the + sign does seem unnecessary. Yet, I think a better solution would be to implement both cumulative and new daily bars on the same chart. Switching between chart types would involve a custom button which would be feasible if my enhancement request at Phabricator passes. If that doesn't work out, then your suggestion is welcome (although the new options would still not be recommended...). Alexiscoutinho (talk) 03:08, 18 September 2020 (UTC)
- @190.246.118.103: There has already been such an option, but it was removed due to oversized chart width outcome (or similar, I dug a bit into the codes history recently). It used the letter b, and as the changetype is currently implemented, only the first letter is evaluated. So p, pa or po are all the same.
- I personally would find other kinds of change/other info column types useful as well, e.g. c(onatgious) for active cases, w(eek) for 7-days-incidence or f(ortnight) for 14-days-incidence. -- Kohraa Mondel (talk) 11:07, 21 December 2020 (UTC)
- I think your first suggestion requires chosing active cases as the classification to be detailed (which I think isn't currently automatable) instead of # of cases. In the other two suggestions, do you mean "rolling averages"? If yes, that could be a nice feature. Alexiscoutinho (talk) 04:00, 22 December 2020 (UTC)
- @Alexiscoutinho: I rather thought of keeping the total number of cases, but instead of displaying its own change in absolute or percentual figures, show the change of the active cases (be it absolute or percentual), see sandbox2 and test case. With the first figure I like a number that corresponds to the bars total length, but in parentheses I personally would prefer a metrics that depicts the desease's spread dynamics best. And there percentual change of active cases seems to me much preferable to absolute or percentual change of cumulated cases.
Sandbox2 implements right now absolute change of active cases, but I want to adjust it to percentual soonis percentual now. -- Kohraa Mondel (talk) 11:54, 22 December 2020 (UTC)- @Kohraa Mondel: I'm still skeptical about mixing value and change of different classifications (also because of formatting). I think that when the cumulative and daily new charts are "split", the dynamics will become much clearer, even with just generic case statistics. For example, there will be a daily new cases "value" and percent change attributed to it, be it simple or rolling... I think that's what the big media mostly does. I know active cases is better in that regard and I wouldn't be against a whole column dedicated for it, but I think it's not good enough to justify mixing things up, yet. Alexiscoutinho (talk) 14:15, 22 December 2020 (UTC)
- @Alexiscoutinho: I can see your point with mixing up cumulated and active cases, but thought of it as a compromise due to limited space. I'm not quite familiar with plans and concepts to "split" the charts, is it about switching between different columns by a toggle button, similar to the time interval toggling? Is there any schedule for implementation or any open tasks to be done? Anyways, what about an additional classification like right1data=a where the respective column would be calculated by data3 - data2 - data1? It's little effort to implement, only the conditions where it applies trouble me a bit, e.g. reclbl=xxx, altlbl1=yyy or recoveries=n might indicate, that data3 and data2 do not contain cases and recoveries, as expected. Any suggestions?. -- Kohraa Mondel (talk) 09:31, 23 December 2020 (UTC)
- @Kohraa Mondel: The Cumulative toggle would look like this and would switch all numbers (not headings) in the columns between cumulative and new (which is basically absolute change), thus all actual changes would be percent, by default. I plan to do it "soon", but after the important year toggles. I would support something like
right1data=a
. We should assume that those labels are the default. The editor is the one who decides if he wants data3 - data2 - data1 or not. Thealttot
s andrecoveries=n
indeed may need to be taken into account. Alexiscoutinho (talk) 14:21, 23 December 2020 (UTC)
- @Kohraa Mondel: The Cumulative toggle would look like this and would switch all numbers (not headings) in the columns between cumulative and new (which is basically absolute change), thus all actual changes would be percent, by default. I plan to do it "soon", but after the important year toggles. I would support something like
- @Alexiscoutinho: I can see your point with mixing up cumulated and active cases, but thought of it as a compromise due to limited space. I'm not quite familiar with plans and concepts to "split" the charts, is it about switching between different columns by a toggle button, similar to the time interval toggling? Is there any schedule for implementation or any open tasks to be done? Anyways, what about an additional classification like right1data=a where the respective column would be calculated by data3 - data2 - data1? It's little effort to implement, only the conditions where it applies trouble me a bit, e.g. reclbl=xxx, altlbl1=yyy or recoveries=n might indicate, that data3 and data2 do not contain cases and recoveries, as expected. Any suggestions?. -- Kohraa Mondel (talk) 09:31, 23 December 2020 (UTC)
- @Kohraa Mondel: I'm still skeptical about mixing value and change of different classifications (also because of formatting). I think that when the cumulative and daily new charts are "split", the dynamics will become much clearer, even with just generic case statistics. For example, there will be a daily new cases "value" and percent change attributed to it, be it simple or rolling... I think that's what the big media mostly does. I know active cases is better in that regard and I wouldn't be against a whole column dedicated for it, but I think it's not good enough to justify mixing things up, yet. Alexiscoutinho (talk) 14:15, 22 December 2020 (UTC)
- @Alexiscoutinho: I rather thought of keeping the total number of cases, but instead of displaying its own change in absolute or percentual figures, show the change of the active cases (be it absolute or percentual), see sandbox2 and test case. With the first figure I like a number that corresponds to the bars total length, but in parentheses I personally would prefer a metrics that depicts the desease's spread dynamics best. And there percentual change of active cases seems to me much preferable to absolute or percentual change of cumulated cases.
- I think your first suggestion requires chosing active cases as the classification to be detailed (which I think isn't currently automatable) instead of # of cases. In the other two suggestions, do you mean "rolling averages"? If yes, that could be a nice feature. Alexiscoutinho (talk) 04:00, 22 December 2020 (UTC)
- As for "rolling averages", the incidence metrics currently in use by several state health authorities are a closely related measure, but not the same: E.g. a 7-days incidence sums up the last 7 days new cases, but does not divide by seven, and then again divides by total population (usually in units of 100,000), thus producing xxx new cases per 7 days per 100,000 inhabitants. But I do not see much additional work in implementing both instead of only incidences. Most work will be to determine the respective intervals diff. So once we know what we want, I think it could be done all in one. -- Kohraa Mondel (talk) 11:54, 22 December 2020 (UTC)
- The way you describe it, I kinda dislike incidence metrics as it just feels like a weekly change and with unnecessarily large numbers, which should be avoided in this, generally, wide template. Furthermore, I haven't heard that rolling averages are, by default, "per 100000". I would be skeptical about such division unless the whole column is "per 100000". Alexiscoutinho (talk) 14:15, 22 December 2020 (UTC)
- The incidence metrics is also not my personal favorite, but published by several national health authorities like Spain (14-days and 7-days), Ireland (7-days), Germany (7-days) or Ukraine (14-days) and as a result also often is cited in the media of these countries. But the values are quite handy 2-3 digit figures, maybe that's why they're preferred over rolling averages. And all these countries relate incidence (and not, of cause, rolling averages) per 100,000 inhabitants. In implementation it's practically no difference in adding rolling average, 7-days-incidence, 14-days incidence or all three of them. So what about just adding changetype=r for rolling as well as w and f? -- Kohraa Mondel (talk) 09:31, 23 December 2020 (UTC)
- Then, incidence is OK. We just have to make sure that the value subcolumn is also per 100,000, probably using an optional
population
field in the main parameter area. Per year population could be added in the future. What would bew
andf
though? Alexiscoutinho (talk) 14:21, 23 December 2020 (UTC)- @Alexiscoutinho: w(eek) for 7-days-incidence or f(ortnight) for 14-days-incidence. Without the population count there is of cause no getting to the incedences, so sth like
population
is mandatory with changetypes w and f. I'll implement at least an example for the changetype in the last test case. Btw, anything against a second testcase page? Things started to blow up (inclusion size?) before I reduced the example data from about 8 weeks to about 4. -- Kohraa Mondel (talk) 15:07, 23 December 2020 (UTC)- @Kohraa Mondel: I don't see why population should be mandatory. I think rolling averages without dividing by population are completely fine. I think the interface should be like: first letter for change type (
a
,p
,r
andi
) and second, optional, letter for change interval (w
andf
), for example,rw
. Ifpopulation
is given, then everything would be per 100,000. If all the current testcases are relevant and short/compact and yet still there are issues, then I wouldn't be against it. Alexiscoutinho (talk) 16:34, 23 December 2020 (UTC)
- @Kohraa Mondel: I don't see why population should be mandatory. I think rolling averages without dividing by population are completely fine. I think the interface should be like: first letter for change type (
- @Alexiscoutinho: w(eek) for 7-days-incidence or f(ortnight) for 14-days-incidence. Without the population count there is of cause no getting to the incedences, so sth like
- Then, incidence is OK. We just have to make sure that the value subcolumn is also per 100,000, probably using an optional
- The incidence metrics is also not my personal favorite, but published by several national health authorities like Spain (14-days and 7-days), Ireland (7-days), Germany (7-days) or Ukraine (14-days) and as a result also often is cited in the media of these countries. But the values are quite handy 2-3 digit figures, maybe that's why they're preferred over rolling averages. And all these countries relate incidence (and not, of cause, rolling averages) per 100,000 inhabitants. In implementation it's practically no difference in adding rolling average, 7-days-incidence, 14-days incidence or all three of them. So what about just adding changetype=r for rolling as well as w and f? -- Kohraa Mondel (talk) 09:31, 23 December 2020 (UTC)
- The way you describe it, I kinda dislike incidence metrics as it just feels like a weekly change and with unnecessarily large numbers, which should be avoided in this, generally, wide template. Furthermore, I haven't heard that rolling averages are, by default, "per 100000". I would be skeptical about such division unless the whole column is "per 100000". Alexiscoutinho (talk) 14:15, 22 December 2020 (UTC)
- As for "rolling averages", the incidence metrics currently in use by several state health authorities are a closely related measure, but not the same: E.g. a 7-days incidence sums up the last 7 days new cases, but does not divide by seven, and then again divides by total population (usually in units of 100,000), thus producing xxx new cases per 7 days per 100,000 inhabitants. But I do not see much additional work in implementing both instead of only incidences. Most work will be to determine the respective intervals diff. So once we know what we want, I think it could be done all in one. -- Kohraa Mondel (talk) 11:54, 22 December 2020 (UTC)
@Alexiscoutinho: I agree with your idea but see some problems. Before implementing the whole thing, I'd like to get requirements clear, especially for the parameter options, because they go over the whole code. e.g. changetype is cut down to the first letter in the beginning and then checked against a single letter in several places. Of cause this can be addressed, but it's some work and the code structure is not ideal. Many more variants can be thought of there and then this could soon end up in a hell of changes. So in the first place I would like to implement 7-day rolling average for r and 7-day incidence for w if population is present (otherwise error out). There we'd have some examples to play with, the calculation bases would be ready and proven in use, and then we can think about useful flexibility and also a comprehensible parameter structure. If I use this template and add the population parameter, I might be surprised to get completely different figures, just for one example. Also I want to check some conditions for generated columns data to avoid unexpected inconsistency, like not allowing explicit data in one column, and generated in the next. That goes ok absolute differences or plain percentage, but with the more complex calculations it can get messy for module users and implementers to sort out unexpected behaviour. I'll do these shorthand changes in sandbox2 and then we can have look and decide on further proceeding. With the test cases only my last chapter has some more data, and that can't be avoided if you want to test 14-days incidence including some tricky stuff like no data on holidays or weekends. All the rest entertains quiet spartanic sample data, so I'd open a second testcases page. -- Kohraa Mondel (talk) 20:56, 23 December 2020 (UTC)
- Forget about the current handling of changetype. I personally always disliked the "first letter" limitation. But it might be a good idea to use the current interface just to test the new change types. I don't see why editors would be surprised in getting completely different numbers if they add
population
. What else would they be expecting? Ideally, all data should be generated, including using the undocumented datapage scraper thing. I think manual data column input should only be allowed until the module handles all situations perfectly. If you feel there is no need anymore for manual input, then we could start deprecating those parameters. Otherwise we do have to handle manual and generated columns being together. You also brought up an important point of the hassle of dealing with missing data and date jumps. Maybe the implementation of this feature will require a solution to #17 of the To Do list. Alexiscoutinho (talk) 03:39, 24 December 2020 (UTC)- @Alexiscoutinho:There's now a prototypic implementation of 7-days rolling average and 7-days incidence per 100,000 population, see sandbox2 and testcases2. Where appropriate time is available I set a unix time stamp for each data row as barargs.nDate (see lines
216ff252ff) and then for changetype 'r' loop back to find a data row with a 7-days difference in258fffunction _findIntervalRow at 31ff. Maybe that approach also helps solving #17 in To Do List?? I tried to also implement _findIntervalRow to solve the assumed problem behind #17, so if it doesn't fit, could you give more details on the topic? -- Kohraa Mondel (talk) 12:23, 26 December 2020 (UTC)- @Kohraa Mondel: Firstly sorry to leave you waiting like that. I haven't looked at the code yet, but from looking at the testcase and trying the calculations myself, I suggest that the description of the change should be in the header to decrease repetition, width and to make the chart cleaner/easier to read and understand; and that the = signs be substituted to n.a. or something else since these changes can be different within a date jump (it's only equal (by the way, = means 0, so what should have been written is actually a repetition of the previous change. Maybe it will be better to substitute = to 0 in the template to be clearer) in this case because the date jumps are perfectly periodic and the amount of 0s in each sum of changes is preserved). Alexiscoutinho (talk) 22:59, 26 December 2020 (UTC)
- @Alexiscoutinho: Nothing to apologise for ... hope you had some pleasant holidays. About description: I also thought it would be placed in the header best, but how would we deal then with a custom column header (right1|2)? There's a parameter handling decision to be done: do not allow right1|2 with w/r/... options or append some description in parentheses or just leave it to the editor to find some appropriate text if he decides to set right1|2, with or without the mouse-over text for each line as in my example. Regarding the size of the mouse-over there seems to be some tweak with css that at least would reduce the additional per line output to a span with a class only or one might do some client side script if that is possible with mediawiki, but even if: that might be a bad idea for maintenance reason. About the insufficient data situation: I already set n.a. for all of these situations and think it's the only appropriate value to set there, if you don't want to leave it blank. Only for the no date case it gets overrruled later in the code (local function changeArg), and just for the example I didn't want to do changes in too many places that also apply to other changetype options. The example actually has an aperiodic change on Dec 8th (some funny spanish holiday shifted from 6th if it happens to be a sunday, but don't ask me for details), and I already had Dec 15th yield n.a respectively. But just now it unexpected yields a figure there,
I'll need to check on that...fixed.- @Kohraa Mondel: I think a change description in parentheses in the header would be best/clearest. I don't see why editors would want to mess around with an alternative change type, also in
right1
/2
. I don't think the mouse-over text is necessary for these columns. I also noticed that other missing date (with different change) xD. By the way, I'll use sandbox(1), so don't change it yet. Alexiscoutinho (talk) 12:33, 27 December 2020 (UTC)- @Alexiscoutinho: With a different case classification like
right1data=4
some column header describing that classification likeright1=# hospitalised
can only be supplied by the editor. In that case it might be best to automatically append the changetype description to the column header, or is it that what you meant, anyway? I'm already using sandbox(1) as it provides me with the back-to-back tests in testcases(1), what is important where you change code structure. But I can keep the results locally on my computer without checking them in to sandbox(1). But at some point I would of cause like to merge it there. -- Kohraa Mondel (talk) 14:12, 27 December 2020 (UTC)- Yes, that's what I meant. I think code reordering should have less priority now, unless it is blocking progress. The first claims the sandbox and the second gets to use his own sandbox or create sandbox3 xD. Oh, furthermore, you can extract Unix time with
mw.getLanguage():formatDate('U', barargs[1])
if that's what you wanted. Alexiscoutinho (talk) 17:14, 27 December 2020 (UTC)- @Alexiscoutinho: Implemented metrics explanation for w and r in column header by post-fixing. About "blocking the progress", a bad structure never actually blocks the progress, it only slows everything down, and often an existing fragmentation yields the next. Anyways, now there's sandbox3 and testcases3, so for sometime we can edit in parallel. The unix "formatting" is more or less what I was looking for, only that it returns a string, so tonumber is required to do proper math with it. While for implementation it saves some lines, another question would be if we want to support such a wide variety of date string formattings, that only in us-en context are more or less unambiguous, while yyyy-mm-dd will yield with virtually any language context. Kohraa Mondel (talk) 14:06, 28 December 2020 (UTC)
- Yes, that's what I meant. I think code reordering should have less priority now, unless it is blocking progress. The first claims the sandbox and the second gets to use his own sandbox or create sandbox3 xD. Oh, furthermore, you can extract Unix time with
- @Alexiscoutinho: With a different case classification like
- @Kohraa Mondel: I think a change description in parentheses in the header would be best/clearest. I don't see why editors would want to mess around with an alternative change type, also in
- @Alexiscoutinho: Nothing to apologise for ... hope you had some pleasant holidays. About description: I also thought it would be placed in the header best, but how would we deal then with a custom column header (right1|2)? There's a parameter handling decision to be done: do not allow right1|2 with w/r/... options or append some description in parentheses or just leave it to the editor to find some appropriate text if he decides to set right1|2, with or without the mouse-over text for each line as in my example. Regarding the size of the mouse-over there seems to be some tweak with css that at least would reduce the additional per line output to a span with a class only or one might do some client side script if that is possible with mediawiki, but even if: that might be a bad idea for maintenance reason. About the insufficient data situation: I already set n.a. for all of these situations and think it's the only appropriate value to set there, if you don't want to leave it blank. Only for the no date case it gets overrruled later in the code (local function changeArg), and just for the example I didn't want to do changes in too many places that also apply to other changetype options. The example actually has an aperiodic change on Dec 8th (some funny spanish holiday shifted from 6th if it happens to be a sunday, but don't ask me for details), and I already had Dec 15th yield n.a respectively. But just now it unexpected yields a figure there,
- @Kohraa Mondel: Firstly sorry to leave you waiting like that. I haven't looked at the code yet, but from looking at the testcase and trying the calculations myself, I suggest that the description of the change should be in the header to decrease repetition, width and to make the chart cleaner/easier to read and understand; and that the = signs be substituted to n.a. or something else since these changes can be different within a date jump (it's only equal (by the way, = means 0, so what should have been written is actually a repetition of the previous change. Maybe it will be better to substitute = to 0 in the template to be clearer) in this case because the date jumps are perfectly periodic and the amount of 0s in each sum of changes is preserved). Alexiscoutinho (talk) 22:59, 26 December 2020 (UTC)
- @Alexiscoutinho:There's now a prototypic implementation of 7-days rolling average and 7-days incidence per 100,000 population, see sandbox2 and testcases2. Where appropriate time is available I set a unix time stamp for each data row as barargs.nDate (see lines
- Once we have some new parameter sets along with some handling specified, I think some overhaul of the implementation might be a good idea, as currently parameter handling is spread rather randomly over the code (a bit in the function passed to getArgs, a lot in p._chart, and still very much in places where output is produced). My idea would be sth like a dedicated function for chart level parameters that does all individual checks and defaults first, and then checks for inappropriate combinations and defaults derived from other parameters. Then a dedicated function to do the same for data rows, also in two passes where the first deals with each line individually and collects metrics, and the second does the automatic stuff. Doing such stuff for the existing parameter handling in the main sandbox first, to have all the back-to-back tests in testcases to check the results, might also be a good idea. But I don't know if the current test cases are sufficient to do such an operation. I read something about scripted comparisons of pages using the module/template in old and new version. You know details about it? -- Kohraa Mondel (talk) 10:54, 27 December 2020 (UTC)
- @Kohraa Mondel: That's great, but I urge you to not change (not that you did) the large scale structure/flow of the code (_chart, _buildBars, _row and _customBarStacked). I mean, preserve their names and purpose. _chart should deal with everything not related to bars and also non-repetitive bars stuff. _buildBars should only collect and process data from other rows (which isn't possible in normal templates). _row should handle individual data and stuff and most, if not all, handling that could be done with templates. _customBarStacked should deal with HTML and other formatting which isn't related with real disease data and numbers. Besides, I think the
is
function can be dropped in almost all cases. Alexiscoutinho (talk) 03:45, 29 December 2020 (UTC)- @Alexiscoutinho: Actually I think that the large scale structure/flow of the module is far from ideal, mostly due to it's past as a set of templates calling each other and different editors implementing features on top of each other over time rather than integrating. But don't worry, I have no intention to go that deep with structural changes as such thing would be a lot of work and not much fun. What I would like to do and already started in sandbox3 is to control the large scale data flow in p.chart calling respective functions to do the details before passing the results to p._buildBars and finally to barBox._box. This leaves two blocks of code to be handled from p._chart, the top level toggles implementation that might deserve its dedicated function, and about 50 lines of html generation that, as you said yourself, do not really belong there and might be integrated to the new toggles function as it all is about the title head of the whole chart. Kohraa Mondel (talk) 08:27, 30 December 2020 (UTC)
- @Kohraa Mondel: The reason for not wanting to change that large scale structure is exactly to keep a little bit of the origins I have some personal attachment to. I think a lot can be improved while still using that backbone, making the result at least good enough. I also think that it would be nice to create a
_buildHeader
function to clean up_chart
and increase code symmetry with_buildBars
.fillCols
should be outside_buildBars
and definetely outside thatfor
loop. Alexiscoutinho (talk) 12:50, 30 December 2020 (UTC)
- @Kohraa Mondel: The reason for not wanting to change that large scale structure is exactly to keep a little bit of the origins I have some personal attachment to. I think a lot can be improved while still using that backbone, making the result at least good enough. I also think that it would be nice to create a
- @Alexiscoutinho: Actually I think that the large scale structure/flow of the module is far from ideal, mostly due to it's past as a set of templates calling each other and different editors implementing features on top of each other over time rather than integrating. But don't worry, I have no intention to go that deep with structural changes as such thing would be a lot of work and not much fun. What I would like to do and already started in sandbox3 is to control the large scale data flow in p.chart calling respective functions to do the details before passing the results to p._buildBars and finally to barBox._box. This leaves two blocks of code to be handled from p._chart, the top level toggles implementation that might deserve its dedicated function, and about 50 lines of html generation that, as you said yourself, do not really belong there and might be integrated to the new toggles function as it all is about the title head of the whole chart. Kohraa Mondel (talk) 08:27, 30 December 2020 (UTC)
- @Kohraa Mondel: That's great, but I urge you to not change (not that you did) the large scale structure/flow of the code (_chart, _buildBars, _row and _customBarStacked). I mean, preserve their names and purpose. _chart should deal with everything not related to bars and also non-repetitive bars stuff. _buildBars should only collect and process data from other rows (which isn't possible in normal templates). _row should handle individual data and stuff and most, if not all, handling that could be done with templates. _customBarStacked should deal with HTML and other formatting which isn't related with real disease data and numbers. Besides, I think the
- Once we have some new parameter sets along with some handling specified, I think some overhaul of the implementation might be a good idea, as currently parameter handling is spread rather randomly over the code (a bit in the function passed to getArgs, a lot in p._chart, and still very much in places where output is produced). My idea would be sth like a dedicated function for chart level parameters that does all individual checks and defaults first, and then checks for inappropriate combinations and defaults derived from other parameters. Then a dedicated function to do the same for data rows, also in two passes where the first deals with each line individually and collects metrics, and the second does the automatic stuff. Doing such stuff for the existing parameter handling in the main sandbox first, to have all the back-to-back tests in testcases to check the results, might also be a good idea. But I don't know if the current test cases are sufficient to do such an operation. I read something about scripted comparisons of pages using the module/template in old and new version. You know details about it? -- Kohraa Mondel (talk) 10:54, 27 December 2020 (UTC)
Different behavior
Template ignores all parameters after "3rd classification (total or altlbl1)" at rows with no date or displays them wrong.
2020-07-01;188;13845;22308;;;;489 ;188;14207;41065;;;41,065;18757 ... 2020-08-01;988;60825;90367;;;90367;1289;988;195 ;1024+30;61839;91593+5181;;;1024+30;30;91593+5100;5100
Remove recoveries
If that possible to force not display "recoveries"? 185.66.252.38 (talk) 08:02, 23 October 2020 (UTC)
- ... or use log-scale? 185.66.252.38 (talk) 16:27, 25 October 2020 (UTC)
- @185.66.252.38: Log-scale is not supported. Other line charts would be more appropriate for that I think. Besides, when "smart zoom-in" is implemented, this problem will be mitigated. Alexiscoutinho (talk) 15:31, 3 December 2020 (UTC)
- @185.66.252.38: Add this line
|recoveries=n
to the template and omit numbers in the appropriate data "column". Alexiscoutinho (talk) 15:31, 3 December 2020 (UTC)
To Do list
- Implement wrapper to automatically pass repetitive parameters to {{Medical cases chart/Row}}; Done here
- Implement automatic
divisor
calculation; Done here - Convert nested templates to module functions; Done here and here
- Minimize chart wikitext length; Mostly done here and here
- Support varied update periods; Not done
- Implement year and decade toggles; Partly done here
- Revamp (month) toggles with JavaSript to solve intersections of sets mess; Waiting approval at phab:T269400
- Add "Cumulative" button to toggle between cumulative and new counts; Not done
- Implement automatic
numwidth
determination; Not done - Implement automatic absolute and relative change calculation; Done here
- Implement automatic number formatting and, consequently, add
note0
,note1
andnote2
parameters; Automatic number formatting done here,note0
/note1
/note2
done here - Implement rolling average and incidence change types; Partly done
- Implement per 100,000 inhabitants metrics; Partly done
- Implement "# of active cases" data column; Partly done
- Implement custom bar ordering and display; Not done
- Implement smart bar divisor/"zoom in" based on the active time period toggles and visible bars; Table width, but not zoom, will dynamically change based on toggles if
barwidth=auto
(implemented here) - Implement automatic date jump handling/formatting; Done here and here
- Tweak makeCollapsible.js to work with unique ids. Not done
Notes in columns
I implemented the note1
and note2
parameters in the sandbox and added a respective test case. Pls check if this is what was intended. -- Kohraa Mondel (talk) 15:24, 21 December 2020 (UTC)
- @Kohraa Mondel: Yes, that's it! Alexiscoutinho (talk) 03:39, 22 December 2020 (UTC)
- @Alexiscoutinho: Ok, moved it to the active module. Additionally I thought of a note
prepost-fixed to the date where the whole date is concerned rather than the data shown in col1 or col2, see sandbox and test case -- Kohraa Mondel (talk) 11:22, 22 December 2020 (UTC)- @Kohraa Mondel: I think
note
ornote0
would be better, more symmetrical names. Alexiscoutinho (talk) 13:20, 22 December 2020 (UTC)- @Alexiscoutinho: Ok, changed it to
note0
as no column index likenote
with other parameters means appllciation to both columns. I'd move it from sandbox to the active module whenever you counterchecked it. -- Kohraa Mondel (talk) 13:34, 22 December 2020 (UTC)- @Kohraa Mondel: Looks good. Put the combined diff in the To Do list. Alexiscoutinho (talk) 13:46, 22 December 2020 (UTC)
- @Alexiscoutinho: Ok, changed it to
- @Kohraa Mondel: I think
- @Alexiscoutinho: Ok, moved it to the active module. Additionally I thought of a note
Bug
Hey people. I have discovered a bug that is becoming a going to become a problem on all of the COVID-related charts now that they are exceeding a year of data. Take the Illinois chart below as an example. When selecting January 2021, it also selects January 2020 and vice versa—you are unable to select just one or the other. I assume this will happen with all months as well. I know it's not a huge issue, but it is an issue. Thanks, EDG 543 (message me) 01:29, 12 January 2021 (UTC)
References
- ^ "IDPH News". Illinois Department of Public Health. March 18, 2020. Retrieved March 18, 2020.
- ^ "Coronavirus Disease 2019 (COVID-19) in Illinois Test Results". Illinois Department of Public Health. Archived from the original on 14 March 2020. Retrieved 16 March 2020.
- It doesn't happen on Template:COVID-19 pandemic data/Mainland China medical cases chart when I select December. I looked at the source and it uses {{Medical cases chart/Month toggle button|jan}} to create the month buttons for 2020 but December 2019 is made with span tags. I can't see where the template for the United States makes the month buttons. Are they added by #invoke at the beginning of the template? I also noticed when I looked at the HTML source that many tr tags have the same id (such as mw-customcollapsible-jan). I don't think HTML allows more than one element to have the same id. They should probably be converted into classes. Nine hundred ninety-nine (talk) 00:04, 13 January 2021 (UTC)
- Looks like this is also fixed on the Italian Wikipedia. Looks like they've added to make the filter buttons both year- and month-aware. They also adjusted the filter button layout. Someone likely need to port that change over to this and the other wikipedia language sites. I'd take a stab at it, but I am not skilled with the particular programming language used. -- Tom N talk/contrib 03:45, 15 January 2021 (UTC)
@EDG 543, Nine hundred ninety-nine, and Tcncv: It's resolved now. Alexiscoutinho (talk) 22:57, 16 January 2021 (UTC)
- @Alexiscoutinho: That's perfect. Well done! Thanks, EDG 543 (message me) 18:02, 17 January 2021 (UTC)
New feature ideas
Now that this code is being worked on, here is a list of feature requests and/or ideas:
- Option to suppress the (=) when the delta is zero.
- Use +/- for absolute changes, Unicode up and down triangles for percent changes. This would be particularly useful when both change types are displayed together.
- Dynamically switch between absolute and percent deltas. I propose using absolute when the current count is under a thousand - there aren't enough significant digits to calculate a good percent delta when counts are small. Also use absolute when the delta is less significant than 0.01%.
- The current implementation allows math in classifications. I believe this happens intrinsically because of how Lua handles variables. Please don't break it. I use this to record confirmed and probable numbers even though the reader will only ever see the total. A future data scientist may like having the breakdown.
- Currently, bars are aligned with the left edge of the 1st classification. It could be useful to align at a later classification, for example, the left edge of active cases. This would create a tree that grows to both sides, allowing the reader to visually track changes in two values. This is similar to how gender and age can be shown in the same census chart.
- Collapse suppressed months into a bar of single pixel tall bars showing each day's data. Clicking on this bar expands it out into the current fat bars with text. Clicking in the fat bars collapses them. This obviates the need for month buttons.
And finally, a potential test case: I've been logging asymptomatic counts in comments in the Idaho chart. The current code has no clean way to show them - they are a subset of recoveries. EphemeralErrata (talk) 10:19, 16 January 2021 (UTC)
Pages and templates being put into script error categories
Something in this template/module is making articles and templates appear in Category:Pages with script errors. I don't see any red error messages that usually appear to help with diagnosis.
I have made a simplified example in my sandbox. When I remove the month toggle coding, the script error category goes away. – Jonesey95 (talk) 00:32, 18 January 2021 (UTC)
- I was just looking at that. See Template:Medical cases chart/Month toggle button ("Script error: The function "monthToggleButton" does not exist.") and Module:Medical cases chart which has
_monthToggleButton
(with underscore). Also see the history of that module—there is some excitement. However, previewing with the underscore shows other problems. Perhaps Alexiscoutinho can work out what the problem is. Johnuniq (talk) 23:13, 18 January 2021 (UTC)- The problem is that
function p.monthToggleButton(frame)
was removed in a massive restructure: 21:55, 16 January 2021. However, {{Medical cases chart/Month toggle button}} uses{{#invoke:Medical cases chart|monthToggleButton}}
. That is, it is calling the removed function. Restoring the function does not work because of the other refactoring. I don't know what would happen if the previous revision were restored while we wait for a proper fix. @Alexiscoutinho: Don't worry about the problems; we're not trying to hassle you as we understand that working on complex setups like this will occasionally break. Johnuniq (talk) 04:34, 19 January 2021 (UTC)- @Jonesey95: Thanks for the insight Johnuniq. I think it's mostly fixed now. Alexiscoutinho (talk) 18:44, 19 January 2021 (UTC)
- Thanks for the fixes, the error category is now clear. Johnuniq (talk) 22:27, 19 January 2021 (UTC)
- @Jonesey95: Thanks for the insight Johnuniq. I think it's mostly fixed now. Alexiscoutinho (talk) 18:44, 19 January 2021 (UTC)
- The problem is that
Suppressing the VTE links
How do we suppress the VTE links (for example in this chart)? We don't want to send editors to a non-existing page. Thanks! Plastikspork ―Œ(talk) 14:41, 19 May 2021 (UTC)
- The chart is supposed to be in a separate template; I've moved Suriname's to Template:COVID-19 pandemic data/Suriname medical cases chart. User:GKFXtalk 20:04, 20 May 2021 (UTC)
Extended-confirmed-protected edit request on 29 May 2021
This edit request to Module:Medical cases chart has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
Lua error in Module:Medical_cases_chart at line 346: invalid date "2021-05-38". Date should be 2021/05/28. Lannertcito (talk) 13:17, 29 May 2021 (UTC)
- Lua error in Module:Medical_cases_chart at line 346: invalid date "2021-05-38". Please change 2021/05/38 to 2021/05/28. Lannertcito (talk) 13:20, 29 May 2021 (UTC)
- Note: Not found Run n Fly (talk) 15:03, 30 May 2021 (UTC)
TfD outcome
@Pppery: From what I understood, you were the only one against GKFX's propositions. Frankly speaking, your arguments were well countered by GKFX and indirectly by my recent (many) conversions. I think the outcome was more like "barely no consensus", however, since I'm not talking about a delete, only a redirect, I don't think we strictly need a consensus to move forward, if you still stand by your first comment. Alexiscoutinho (talk) 18:56, 22 June 2021 (UTC)
- The outcome was "no consensus". That does not mean "implement the proposal anyway", and that decision should not be ignored. What you've done is an inappropriate fait accompli. It might have been okay originally to proceed without any discussion, but now that there has been a discussion, its result should not be ignored. * Pppery * it has begun... 19:22, 22 June 2021 (UTC)
- @Pppery: Do I have to open a new TfD entry then? By the way, I agree my action on those ~127 articles might not have been nice, but, in the end of the day, I think they were just numbers, not an argument or evidence. It's not like they explicitly decided/preferred to use the template version (except 1 I think). In other words, even if I didn't make those many conversions, that 127 articles sentence would still be almost meaningless in my view. Alexiscoutinho (talk) 19:41, 22 June 2021 (UTC)
- The actual number was irrelevant, and trying to justify a new TfD based on fait accompli actions is even worse. I would likely have !voted keep regardless of the number. My point at the TfD was more than I failed to see a good reason for deliberately breaking things or making large numbers of edits that accomplished nothing, and the problem that the original proposal was attempting to solve should have been solved in a different way. If you believe the closure incorrectly reflected the consensus of the discussion, then you should follow the proper procedures for challenging closures, not try to subvert it just because you disagree. * Pppery * it has begun... 19:48, 22 June 2021 (UTC)
- Personally I think the closure was dubious. There were three votes to stop transcluding the template (me, Alexiscoutinho, Izno), one (possibly non-voting) suggestion on how to stop transcluding the template (67.70), one oppose (Pppery), and one "wow". That makes 3 and a bit to one by my count, albeit with no consensus on how to go about not transcluding it. I personally don't feel like going through DRV but if @Alexiscoutinho wants to they should go ahead. User:GKFXtalk 20:06, 22 June 2021 (UTC)
- The actual number was irrelevant, and trying to justify a new TfD based on fait accompli actions is even worse. I would likely have !voted keep regardless of the number. My point at the TfD was more than I failed to see a good reason for deliberately breaking things or making large numbers of edits that accomplished nothing, and the problem that the original proposal was attempting to solve should have been solved in a different way. If you believe the closure incorrectly reflected the consensus of the discussion, then you should follow the proper procedures for challenging closures, not try to subvert it just because you disagree. * Pppery * it has begun... 19:48, 22 June 2021 (UTC)
- @Pppery: Do I have to open a new TfD entry then? By the way, I agree my action on those ~127 articles might not have been nice, but, in the end of the day, I think they were just numbers, not an argument or evidence. It's not like they explicitly decided/preferred to use the template version (except 1 I think). In other words, even if I didn't make those many conversions, that 127 articles sentence would still be almost meaningless in my view. Alexiscoutinho (talk) 19:41, 22 June 2021 (UTC)
- I didn't say I justified a new TfD based on those many conversions. That was just a side note after my question. Furthermore, all my previous actions were in good faith and I never deliberately tried subverting anything. Alexiscoutinho (talk) 20:17, 22 June 2021 (UTC)
@Pppery and GKFX: I have a new idea: simply deprecate (add a message) the template, but otherwise keep its (tiny) content for transclusions. All current pages would still need to be migrated to #invoke... but old page versions would not break badly. Should I open a new TfD entry for it, accepting the latest one? Alexiscoutinho (talk) 14:48, 27 June 2021 (UTC)
- This template is already completely gone from everywhere except userspace and its own pages, so there's no point leaving it in the current state where the documentation and talk page are in the wrong place. Officially you should wait another month to WP:RENOM a no-consensus closure, but WP:DRV can be done whenever. As the template was mostly used within other templates, there should be little effect on viewing old revisions of articles if this template were deleted/broken altogether. User:GKFXtalk 15:22, 27 June 2021 (UTC)
- The documentation and talk would be moved of course. By the way, when I said "old page versions" I mostly thought of templates. I think I'll wait then. Alexiscoutinho (talk) 16:16, 27 June 2021 (UTC)